🚨 CVE-2026-17631
IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information due to a server-side request forgery (SSRF) vulnerability.

🎖@cveNotify

🚨 CVE-2026-18073
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a local authenticated attacker to inject parameters into a CL command due to improper neutralization of special elements.

🎖@cveNotify

🚨 CVE-2026-18076
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to cause a denial of service due to a memory leak.

🎖@cveNotify

🚨 CVE-2026-18078
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to cause a denial of service due to an integer overflow.

🎖@cveNotify

🚨 CVE-2026-18175
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to manipulate database transactions due to improper authorization in the DDM target dispatcher.

🎖@cveNotify

🚨 CVE-2026-18221
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to gain unauthorized access due to improper validation of client-supplied authentication parameters.

🎖@cveNotify

🚨 CVE-2026-18341
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to corrupt memory due to an integer underflow.

🎖@cveNotify

🚨 CVE-2026-18486
IBM ContextForge MCP Gateway <= v1.0.7 MCP Context Forge could allow a remote authenticated attacker to obtain sensitive credentials and escalate privileges due to improper validation of jq filters.

🎖@cveNotify

🚨 CVE-2026-18489
IBM ContextForge MCP Gateway - Translate utility <= 1.0.8 MCP Context Forge could allow a remote attacker to obtain sensitive information from other sessions due to exposure of data elements to the wrong session.

🎖@cveNotify

🚨 CVE-2026-38961
Cross-Site Scripting (XSS) vulnerability in the RSS Widget of Netgate pfSense Plus (versions 26.03, 25.11.1) and pfSense CE (version 2.8.1) allows remote authenticated attackers to inject arbitrary JavaScript via malicious content in an RSS feed title. The injected script executes in the browser of any authenticated user who views the dashboard, due to insufficient sanitization of feed title data before rendering in the widget.

🎖@cveNotify

🚨 CVE-2026-75430
PowerJob Worker version 5.1.2 (and likely earlier versions) exposes the /worker/deployContainer HTTP endpoint without authentication on the default transport port. This allows a remote attacker to execute arbitrary code.

🎖@cveNotify

🚨 CVE-2026-78745
An issue in HiDPT/ Weyon HiDPTAndroid Hi3751V350 Hi3751V352E_DMO allows a remote attacker to execute arbitrary code via the Android Debug Bridge (ADB) daemon (adbd)

🎖@cveNotify

🚨 CVE-2026-78849
Cross Site Scripting vulnerability in Netgate pfSense Plus software versions <= 26.03 pfSense CE software versions <= 2.8.1 allows a remote attacker to execute arbitrary code via the captive_portal_status.widget.php file

🎖@cveNotify

🚨 CVE-2026-80865
In the Linux kernel, the following vulnerability has been resolved:

bpf: Add missing access_ok call to copy_user_syms

As reported by sashiko we use __get_user without prior access_ok call on the
user space pointer. Adding the missing call for the whole pointer array.

Plus removing the err check in the error path, because it's not needed and
also we can return -ENOMEM directly from the first kvmalloc_array fail path.

[1] https://lore.kernel.org/bpf/20260611115503.AC16D1F00893@smtp.kernel.org/

🎖@cveNotify

🚨 CVE-2026-80866
In the Linux kernel, the following vulnerability has been resolved:

tipc: avoid busy looping in tipc_exit_net()

Blamed commit introduced a busy-wait loop in tipc_exit_net()
to wait for pending UDP bearer cleanup works to complete:

while (atomic_read(&tn->wq_count))
cond_resched();

This loop can busy-wait for a long time if cond_resched() is a NOP. This
typically happens if the netns exit is executed by a high priority task,
or under kernels configured without preemption (CONFIG_PREEMPT_NONE). In
such cases, it wastes CPU cycles and can lead to soft lockups.

Fix this by replacing the busy loop with wait_var_event(), allowing the
thread to sleep properly until the work queue count reaches zero.

Accordingly, update cleanup_bearer() to use atomic_dec_and_test() and
wake_up_var() to wake up the waiter when the count drops to zero.

This uses the global wait queue hash table, avoiding the need to bloat
struct tipc_net with a wait_queue_head_t. The atomic_dec_and_test()
provides the necessary memory barrier to ensure the wakeup is not missed.

🎖@cveNotify

🚨 CVE-2026-80867
In the Linux kernel, the following vulnerability has been resolved:

alpha/PCI: Add security_locked_down() check to pci_mmap_resource()

Currently, Alpha's pci_mmap_resource() does not check
security_locked_down(LOCKDOWN_PCI_ACCESS) before allowing userspace to mmap
PCI BARs.

The generic version has had this check since commit eb627e17727e ("PCI:
Lock down BAR access when the kernel is locked down") to prevent DMA
attacks when the kernel is locked down.

Add the same check to Alpha's pci_mmap_resource().

🎖@cveNotify

🚨 CVE-2026-80868
In the Linux kernel, the following vulnerability has been resolved:

ntfs3: Allocate iomap inline_data using alloc_page

This fixes a BUG reported in iomap_write_end_inline:
iomap_inline_data_valid checks that the inline_data fits within
a page. If the inline_data is allocated with kmemdup there's no
guarantee that it's page-aligned, so the check sometimes fails.
Allocate it with alloc_page to ensure it's page-aligned.

🎖@cveNotify

🚨 CVE-2026-80869
In the Linux kernel, the following vulnerability has been resolved:

ntfs: bound the attribute-list entry in ntfs_read_inode_mount()

The $MFT attribute-list walk in ntfs_read_inode_mount() validates each
entry only with "(u8 *)al_entry + 6 > al_end" and
"(u8 *)al_entry + le16_to_cpu(al_entry->length) > al_end", but then reads
al_entry->lowest_vcn (an __le64 at offset 8) and al_entry->mft_reference
(offset 16) -- fields beyond the 6 bytes proven in range. al_entry->length
is attacker-controlled and only required non-zero, so a short entry (e.g.
length 8) placed at the tail passes both checks while the lowest_vcn /
mft_reference reads fall past al_end.

al_end is ni->attr_list + attr_list_size (the on-disk size); the buffer is
kvzalloc(round_up(attr_list_size, SECTOR_SIZE)), so the sector rounding
usually absorbs the over-read -- but when attr_list_size is a multiple of
SECTOR_SIZE there is no slack and a crafted $MFT attribute list produces an
out-of-bounds read at mount time.

Validate the entry with ntfs_attr_list_entry_is_valid() (added in patch
1/3) before dereferencing it, matching the bound the other attribute-list
walks now use. The validator already requires the length to cover the fixed
header, which makes the separate "!al_entry->length" check redundant, so
drop it too.

🎖@cveNotify

🚨 CVE-2026-80870
In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Validate CRIU-restored IDs before idr_alloc

The KFD CRIU restore flow restores previously saved object IDs from
userspace.

For event restore:

kfd_criu_restore_event()
-> create_signal_event() / create_other_event()
-> allocate_event_notification_slot()
-> idr_alloc(..., *restore_id, *restore_id + 1, ...)

For BO restore:

criu_restore_memory_of_gpu()
-> idr_alloc(..., bo_priv->idr_handle, ...)

In both cases, the restored ID comes from userspace-provided CRIU data.

idr_alloc() expects the ID range values to fit within signed int
limits. If a restored ID is larger than INT_MAX, it can trigger a WARN
in the IDR layer.

A kernel WARN is undesirable because it prints a warning trace and may
cause a panic or reboot on systems with panic_on_warn enabled.

Smatch reported these paths as allowing unchecked userspace values to
reach idr_alloc().

Add INT_MAX validation before using restored IDs in:

- kfd_criu_restore_event()
- criu_restore_memory_of_gpu()

If the restored ID is invalid, return -EINVAL.

This prevents invalid restore data from reaching the IDR layer and
avoids WARN-triggering paths, while keeping valid restore behavior
unchanged.

🎖@cveNotify

🚨 CVE-2026-80871
In the Linux kernel, the following vulnerability has been resolved:

crypto: xilinx-trng - Remove crypto_rng interface

Implementing the crypto_rng interface has no purpose, as it isn't used
in practice. It's being removed from other drivers too. Just remove
it. This leaves hwrng, which is actually used.

Tagging with 'Cc stable' due to the bugs that this removes:

- xtrng_trng_generate() sometimes returned success even when it didn't
fill in all the bytes.

- It was possible for xtrng_trng_generate() and
xtrng_hwrng_trng_read() to run concurrently and interfere with each
other, as the locking code in xtrng_hwrng_trng_read() was broken.

🎖@cveNotify

🚨 CVE-2026-80872
In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda/tas2781: Cancel async firmware request at unbind

TAS2781 HDA I2C and SPI queue RCA firmware loading from component
bind with request_firmware_nowait(). The firmware loader keeps the
callback module pinned and holds a device reference, but the callback
still uses driver-private HDA state.

Component unbind removes controls and DSP state immediately. Later
device removal tears down the TAS2781 private data, including
codec_lock. If the async firmware callback runs after unbind has
started, it can operate on state that is being torn down.

Cancel or synchronize the async firmware request before removing
controls and DSP state. A queued callback is cancelled, and an
already-running callback is allowed to finish before unbind continues.

🎖@cveNotify