🚨 CVE-2026-14078
Insufficient validation of untrusted input in WebRTC in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform privilege escalation via a crafted HTML page. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14086
Insufficient policy enforcement in HID in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14091
Use after free in DevTools in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14094
Use after free in Installer in Google Chrome on Windows prior to 150.0.7871.47 allowed a local attacker to perform OS-level privilege escalation via a malicious file. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14104
Insufficient validation of untrusted input in WebAppInstalls in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14107
Use after free in Scheduling in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14108
Use after free in PDFium in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted PDF file. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14111
Use after free in WebProtect in Google Chrome prior to 150.0.7871.47 allowed an attacker who convinced a user to install a malicious extension to execute arbitrary code via a crafted Chrome Extension. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14115
Insufficient validation of untrusted input in Cast in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to perform privilege escalation via a crafted HTML page. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14121
Use after free in Chromoting in Google Chrome on Linux prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code via malicious network traffic. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14124
Inappropriate implementation in CredentialProvider in Google Chrome on Windows prior to 150.0.7871.47 allowed a local attacker to perform OS-level privilege escalation via a malicious file. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-14149
Use after free in Audio in Google Chrome on Linux prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: Low)

🎖@cveNotify

🚨 CVE-2026-28322
SolarWinds Database Performance Analyzer was found to be affected by a stored cross-site scripting vulnerability, which when exploited, can lead to unintended script execution.

🎖@cveNotify

🚨 CVE-2026-20458
In Modem, there is a possible memory corruption due to a missing bounds check. This could lead to remote escalation of privilege, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01402160; Issue ID: MSV-7298.

🎖@cveNotify

🚨 CVE-2026-20462
In Telephony, there is a possible memory corruption due to a heap buffer overflow. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11006447; Issue ID: MSV-7871.

🎖@cveNotify

🚨 CVE-2026-20463
In Modem, there is a possible escalation of privilege due to a permissions bypass. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: MOLY01716533; Issue ID: MSV-6309.

🎖@cveNotify

🚨 CVE-2026-5136
A flaw was found in Foreman. The Usergroup model in Foreman does not properly validate role assignments against the calling user's permissions. This allows an authenticated user with usergroup management permissions to attach arbitrary roles, including administrative roles, to a user group and then add themselves as a member. Successful exploitation of this vulnerability leads to full privilege escalation, granting the attacker administrator-level access.

🎖@cveNotify

🚨 CVE-2026-24260
NVIDIA Container Toolkit for Linux contains a vulnerability where an attacker could cause a time-of-check time-of-use race condition. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, and data tampering.

🎖@cveNotify

🚨 CVE-2026-49091
Improper Output Neutralization for Logs (CWE-117) in Kibana can lead to log injection via Log Injection-Tampering-Forging (CAPEC-93). An attacker can supply specially crafted input that is written to log files without proper neutralization. When the log files are subsequently viewed in a terminal that interprets control sequences, the injected content may alter the displayed log data.

🎖@cveNotify

🚨 CVE-2026-50160
Hoppscotch is an API development ecosystem. In self-hosted deployments of hoppscotch-backend from version 2026.4.1 and earlier, the unauthenticated POST /v1/onboarding/config endpoint is vulnerable to mass assignment. The global NestJS ValidationPipe is configured without whitelist: true, so extra properties on the request body that are not declared in SaveOnboardingConfigRequest are not stripped and are iterated in the service layer as if they were legitimate InfraConfig entries. Because keys such as JWT_SECRET and SESSION_SECRET are valid InfraConfigEnum values and are not explicitly rejected during validation, an unauthenticated attacker who can reach a fresh instance before onboarding completes (or when no users exist) can overwrite these values in the database. Overwriting JWT_SECRET gives the attacker control of the JWT signing key, allowing them to forge tokens for any user, including administrators, and results in full server compromise. The issue is fixed in hoppscotch 2026.5.0.

🎖@cveNotify

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

Revert "wireguard: device: enable threaded NAPI"

This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is
commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream.

We have had three independent production user reports in combination
with Cilium utilizing WireGuard as encryption underneath that k8s Pod
E/W traffic to certain peer nodes fully stalled. The situation appears
as follows:

- Occurs very rarely but at random times under heavy networking load.
- Once the issue triggers the decryption side stops working completely
for that WireGuard peer, other peers keep working fine. The stall
happens also for newly initiated connections towards that particular
WireGuard peer.
- Only the decryption side is affected, never the encryption side.
- Once it triggers, it never recovers and remains in this state,
the CPU/mem on that node looks normal, no leak, busy loop or crash.
- bpftrace on the affected system shows that wg_prev_queue_enqueue
fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer's
rx_queue is reached.
- Also, bpftrace shows that wg_packet_rx_poll for that peer is never
called again after reaching this state for that peer. For other
peers wg_packet_rx_poll does get called normally.
- Commit db9ae3b ("wireguard: device: enable threaded NAPI")
switched WireGuard to threaded NAPI by default. The default has
not been changed for triggering the issue, neither did CPU
hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always
return valid online CPU in wg_cpumask_choose_online()")).
- The issue has been observed with stable kernels of v5.15 as well as
v6.1. It was reported to us that v5.10 stable is working fine, and
no report on v6.6 stable either (somewhat related discussion in [0]
though).
- In the WireGuard driver the only material difference between v5.10
stable and v5.15 stable is the switch to threaded NAPI by default.

[0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/

Breakdown of the problem:

1) skbs arriving for decryption are enqueued to the peer->rx_queue in
wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer.
2) The latter only moves the skb into the MPSC peer queue if it does
not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an
atomic counter via wg_prev_queue_enqueue.
3) In case enqueueing was successful, the skb is also queued up
in the device queue, round-robin picks a next online CPU, and
schedules the decryption worker.
4) The wg_packet_decrypt_worker, once scheduled, picks these up
from the queue, decrypts the packets and once done calls into
wg_queue_enqueue_per_peer_rx.
5) The latter updates the state to PACKET_STATE_CRYPTED on success
and calls napi_schedule on the per peer->napi instance.
6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks
on the peer->rx_queue. It will wg_prev_queue_dequeue if the
queue->peeked skb was not cached yet, or just return the latter
otherwise. (wg_prev_queue_drop_peeked later clears the cache.)
7) From an ordering perspective, the peer->rx_queue has skbs in order
while the device queue with the per-CPU worker threads from a
global ordering PoV can finish the decryption and signal the skb
PACKET_STATE_CRYPTED out of order.
8) A situation can be observed that the first packet coming in will
be stuck waiting for the decryption worker to be scheduled for
a longer time when the system is under pressure.
9) While this is the case, the other CPUs in the meantime finish
decryption and call into napi_schedule.
10) Now in wg_packet_rx_poll it picks up the first in-order skb
from the peer->rx_queue and sees that its state is still
PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e
---truncated---

🎖@cveNotify