| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Heap buffer overflow in libaom in Google Chrome prior to 139.0.7258.127 allowed a remote attacker to potentially exploit heap corruption via a curated set of gestures. (Chromium security severity: High) |
| Type Confusion in V8 in Google Chrome prior to 138.0.7204.168 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) |
| Type Confusion in V8 in Google Chrome prior to 138.0.7204.168 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Blink in Google Chrome prior to 137.0.7151.68 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium) |
| The issue was addressed with improved bounds checks. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. Processing a maliciously crafted string may lead to heap corruption. |
| SonarQube Server and Cloud is a static analysis solution for continuous code quality and security inspection. A command injection vulnerability exists in SonarQube GitHub Action in version 4.0.0 to before version 6.0.0 when workflows pass user-controlled input to the args parameter on Windows runners without proper validation. This vulnerability bypasses a previous security fix and allows arbitrary command execution, potentially leading to exposure of sensitive environment variables and compromise of the runner environment. The vulnerability has been fixed in version 6.0.0. Users should upgrade to this version or later. |
| Heap-based buffer overflow in Windows SPNEGO Extended Negotiation allows an unauthorized attacker to execute code over a network. |
| Improper link resolution before file access ('link following') in Windows Update Service allows an authorized attacker to elevate privileges locally. |
| In SAEMM_DiscloseMsId of SAEMM_RadioMessageCodec.c, there is a possible out of bounds read due to a missing bounds check. This could lead to remote information disclosure post authentication with no additional execution privileges needed. User interaction is not needed for exploitation. |
| A request smuggling vulnerability existed in the Google Cloud Classic Application Load Balancer due to improper handling of chunked-encoded HTTP requests. This allowed attackers to craft requests that could be misinterpreted by backend servers. The issue was fixed by disallowing stray data after a chunk, and is no longer exploitable. No action is required as Classic Application Load Balancer service after 2025-04-26 is not vulnerable. |
| Google gVisor's runsc component exhibited a local privilege escalation vulnerability due to incorrect handling of file access permissions, which allowed unprivileged users to access restricted files. This occurred because the process initially ran with root-like permissions until the first fork. |
| A directory traversal issue in Swetrix Web Analytics API 3.1.1 before 7d8b972 allows a remote attacker to achieve Remote Code Execution via a crafted HTTP request. |
| fast-redact is a package that provides do very fast object redaction. A Prototype Pollution vulnerability in the nestedRestore function of fast-redact version 3.5.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence. NOTE: the Supplier disputes this because the reporter only demonstrated access to properties by an internal utility function, and there is no means for achieving prototype pollution via the public API. |
| A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS Software and Cisco IOS XE Software could allow the following:
An authenticated, remote attacker with low privileges could cause a denial of service (DoS) condition on an affected device that is running Cisco IOS Software or Cisco IOS XE Software. To cause the DoS, the attacker must have the SNMPv2c or earlier read-only community string or valid SNMPv3 user credentials.
An authenticated, remote attacker with high privileges could execute code as the root user on an affected device that is running Cisco IOS XE Software. To execute code as the root user, the attacker must have the SNMPv1 or v2c read-only community string or valid SNMPv3 user credentials and administrative or privilege 15 credentials on the affected device.
An attacker could exploit this vulnerability by sending a crafted SNMP packet to an affected device over IPv4 or IPv6 networks.
This vulnerability is due to a stack overflow condition in the SNMP subsystem of the affected software. A successful exploit could allow a low-privileged attacker to cause the affected system to reload, resulting in a DoS condition, or allow a high-privileged attacker to execute arbitrary code as the root user and obtain full control of the affected system.
Note: This vulnerability affects all versions of SNMP. |
| A vulnerability in the IPv6 Router Advertisement (RA) packet processing of Cisco Access Point Software could allow an unauthenticated, adjacent attacker to modify the IPv6 gateway on an affected device.
This vulnerability is due to a logic error in the processing of IPv6 RA packets that are received from wireless clients. An attacker could exploit this vulnerability by associating to a wireless network and sending a series of crafted IPv6 RA packets. A successful exploit could allow the attacker to temporarily change the IPv6 gateway of an affected device. This could also lead to intermittent packet loss for any wireless clients that are associated with the affected device. |
| Any project that parses untrusted Protocol Buffers data containing an arbitrary number of nested groups / series of SGROUP tags can corrupted by exceeding the stack limit i.e. StackOverflow. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. |
| In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even
a failed probe call would modify the global drv_data pointer. So check
if drv_data is valid before overwriting it. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/tdx: Zero out the missing RSI in TDX_HYPERCALL macro
In the TDX_HYPERCALL asm, after the TDCALL instruction returns from the
untrusted VMM, the registers that the TDX guest shares to the VMM need
to be cleared to avoid speculative execution of VMM-provided values.
RSI is specified in the bitmap of those registers, but it is missing
when zeroing out those registers in the current TDX_HYPERCALL.
It was there when it was originally added in commit 752d13305c78
("x86/tdx: Expand __tdx_hypercall() to handle more arguments"), but was
later removed in commit 1e70c680375a ("x86/tdx: Do not corrupt
frame-pointer in __tdx_hypercall()"), which was correct because %rsi is
later restored in the "pop %rsi". However a later commit 7a3a401874be
("x86/tdx: Drop flags from __tdx_hypercall()") removed that "pop %rsi"
but forgot to add the "xor %rsi, %rsi" back.
Fix by adding it back. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: keep DMA buffers required for suspend/resume
Nouveau deallocates a few buffers post GPU init which are required for GPU suspend/resume to function correctly.
This is likely not as big an issue on systems where the NVGPU is the only GPU, but on multi-GPU set ups it leads to a regression where the kernel module errors and results in a system-wide rendering freeze.
This commit addresses that regression by moving the two buffers required for suspend and resume to be deallocated at driver unload instead of post init. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: confirm multicast packets before passing them up the stack
conntrack nf_confirm logic cannot handle cloned skbs referencing
the same nf_conn entry, which will happen for multicast (broadcast)
frames on bridges.
Example:
macvlan0
|
br0
/ \
ethX ethY
ethX (or Y) receives a L2 multicast or broadcast packet containing
an IP packet, flow is not yet in conntrack table.
1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.
-> skb->_nfct now references a unconfirmed entry
2. skb is broad/mcast packet. bridge now passes clones out on each bridge
interface.
3. skb gets passed up the stack.
4. In macvlan case, macvlan driver retains clone(s) of the mcast skb
and schedules a work queue to send them out on the lower devices.
The clone skb->_nfct is not a copy, it is the same entry as the
original skb. The macvlan rx handler then returns RX_HANDLER_PASS.
5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.
The Macvlan broadcast worker and normal confirm path will race.
This race will not happen if step 2 already confirmed a clone. In that
case later steps perform skb_clone() with skb->_nfct already confirmed (in
hash table). This works fine.
But such confirmation won't happen when eb/ip/nftables rules dropped the
packets before they reached the nf_confirm step in postrouting.
Pablo points out that nf_conntrack_bridge doesn't allow use of stateful
nat, so we can safely discard the nf_conn entry and let inet call
conntrack again.
This doesn't work for bridge netfilter: skb could have a nat
transformation. Also bridge nf prevents re-invocation of inet prerouting
via 'sabotage_in' hook.
Work around this problem by explicit confirmation of the entry at LOCAL_IN
time, before upper layer has a chance to clone the unconfirmed entry.
The downside is that this disables NAT and conntrack helpers.
Alternative fix would be to add locking to all code parts that deal with
unconfirmed packets, but even if that could be done in a sane way this
opens up other problems, for example:
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4
-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
For multicast case, only one of such conflicting mappings will be
created, conntrack only handles 1:1 NAT mappings.
Users should set create a setup that explicitly marks such traffic
NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass
them, ruleset might have accept rules for untracked traffic already,
so user-visible behaviour would change. |
