| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Lightroom Classic is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| Lightroom Classic is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| SurrealDB before 2.0.5, 2.1.x before 2.1.5, and 2.2.x before 2.2.2 fails to properly escape table and field names in the command-line export command. An authenticated System User with OWNER or EDITOR roles can create tables or fields with malicious names containing SurrealQL. When a higher-privileged user subsequently imports the exported backup, the injected SurrealQL executes, enabling privilege escalation and root-level takeover of the SurrealDB instance. Applications that let users define custom tables or fields are also exposed to a universal second-order SurrealQL injection even when query parameters are sanitized. |
| WolfStack before 25.9.2 contains a hard-coded cluster-authentication secret compiled into every build and published as a constant in src/auth/mod.rs, allowing remote unauthenticated attackers to bypass authentication by supplying this value in the X-WolfStack-Secret header to the require_auth() gate without any session, API key, or user account. Attackers can reach an affected node's management port to enumerate all Docker and LXC containers on the host and execute arbitrary commands as root inside any container via the POST /api/containers/{runtime}/{id}/exec endpoint. |
| A buffer overflow vulnerability exists in the Palo Alto Networks GlobalProtect™ app that enables a man-in-the-middle (MitM) attacker or a rogue gateway to disrupt system processes and potentially execute arbitrary code with elevated privileges (SYSTEM privileges on Windows, and root privileges on macOS and Linux). |
| Django REST framework is a toolkit for building Web APIs. Prior to 3.17.2, Django REST Framework's request.data parsing in rest_framework/request.py Request._parse() passes the underlying HttpRequest stream to JSONParser and FormParser for application/json and application/x-www-form-urlencoded bodies, bypassing Django's DATA_UPLOAD_MAX_MEMORY_SIZE protection and allowing oversized request bodies to consume additional memory and CPU. This issue is fixed in version 3.17.2. |
| SurrealDB before 2.0.5, 2.1.x before 2.1.5, and 2.2.x before 2.2.2 does not enforce a default execution-time limit on embedded JavaScript scripting functions when the scripting capability is explicitly enabled (via --allow-scripting or --allow-all). An authenticated attacker can submit long-running JavaScript functions to exhaust server resources and cause a denial of service. Scripting is disabled by default. |
| Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Office SharePoint allows an unauthorized attacker to perform spoofing over a network. |
| Deserialization of untrusted data in Microsoft Office SharePoint allows an authorized attacker to execute code over a network. |
| Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Office SharePoint allows an authorized attacker to perform spoofing over a network. |
| Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Office SharePoint allows an authorized attacker to perform spoofing over a network. |
| Autel Maxi Charger Single firmware through V1.03.51 is vulnerable to OS command injection in the /test endpoint exposed on TCP port 9002. An unauthenticated attacker can supply crafted input in the url parameter to execute arbitrary operating system commands. |
| Autel Maxi Charger Single firmware through V1.03.51 is vulnerable to OS command injection when processing OCPP GetDiagnostics requests. A malicious or compromised OCPP server can supply a crafted diagnostics URL that results in arbitrary command execution on the charging station. |
| HCL DevOps Loop is affected by insufficient input validation that allows special characters where they should be restricted. This may result in unintended application behavior under certain conditions. |
| AI_ONLY_REPORT
package: iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10
------
Summary: Out-of-Bounds Write and Information Disclosure via Unvalidated
IPv6 Payload Length: crafted ICMPv6 Echo Requests can cause `iscsiuio` to
trust an inflated `ipv6_plen` larger than the actual received payload,
leading to MTU-bounded out-of-bounds reads and a potential one-byte
out-of-bounds write that may disclose data beyond the valid packet boundary.
Requirements to exploit: Adjacent-network access on the same L2 segment as
a system running `iscsiuio` on an interface that processes IPv6/NDP
traffic, plus the ability to send a crafted ICMPv6 Echo Request with a
forged `IPv6.plen`. No authentication or user interaction is required.
Component affected: `iscsi-initiator-utils` (`iscsiuio`):
`iscsiuio/src/uip/ipv6.c` in `ipv6_icmp_handle_echo_request()` and
`ipv6_insert_protocol_chksum()`.
Version affected: `iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10` when
`iscsiuio` is processing IPv6/NDP traffic on a reachable interface.
Patch available: no released package fix established; proposed patch
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L - 6.3 (MEDIUM)
AV:A - Reachability is limited to an attacker on the same L2 segment who
can send crafted IPv6/ICMPv6 traffic to the affected interface.
AC:L - The attack relies on forging `IPv6.plen`; no race or unusual
environment is needed beyond the vulnerable deployment.
PR:N - No privileges are required.
UI:N - No user interaction is required.
S:U - The impact remains within the `iscsiuio` process and its packet
buffer handling.
C:L - The reply/checksum path can read and potentially transmit data
beyond the valid packet boundary, but the demonstrated exposure is
MTU-bounded.
I:L - For odd forged lengths, the checksum path can write a single
padding byte past the valid protocol data, which may affect adjacent buffer
contents.
A:L - Invalid memory access may destabilize or crash the process, but
reliable high-impact denial of service is not established from the
available evidence.
Impact: Moderate. Under Red Hat's severity guidance, this is more
consistent with a flaw that can affect confidentiality, integrity, or
availability under constrained circumstances than with an Important issue.
The bug is unauthenticated and adjacent-network reachable, but the
currently supported outcome is MTU-bounded out-of-bounds access in a
deployment-dependent IPv6/NDP path, not easy remote system compromise or
clearly high-impact memory corruption.
Embargo: no
Reason: The currently supported impact is Moderate, exposure depends on
`iscsiuio` processing IPv6 traffic on a reachable L2 segment, and operators
can reduce exposure operationally by isolating or disabling the affected
path.
Acknowledgement: Aisle Research
Vulnerability Details: In the ICMPv6 echo-reply path, the code reuses the
inbound `ipv6_plen` field when sizing the reply instead of clamping it to
the bytes actually received:
```c
/* iscsiuio/src/uip/ipv6.c */
static void ipv6_icmp_handle_echo_request(struct ipv6_context *context)
{
...
ipv6_send(context, (u8_t *) icmp - (u8_t *) eth +
sizeof(struct ipv6_hdr) + HOST_TO_NET16(ipv6->ipv6_plen));
}
```
Later, checksum generation also trusts `ipv6_plen` for memory traversal,
and for odd lengths it writes a padding byte at `ptr + protocol_data_len`
before iterating over `protocol_data_len` bytes:
```c
/* iscsiuio/src/uip/ipv6.c */
protocol_data_len = HOST_TO_NET16(ipv6->ipv6_plen);
...
if (protocol_data_len & 1) {
*((u8_t *) ptr + protocol_data_len) = 0;
protocol_data_len++;
}
for (i = 0; i < protocol_data_len / 2; i++) {
sum += HOST_TO_NET16(*ptr);
ptr++;
}
```
The available receive-side logic does not establish a payload-length bound
strong enough to eliminate this condition. `uip_input()` compares the IPv6
payload length against `uip_len`, but `uip_len` is treated as full frame
length in the observed path rather than the actual IPv6 payload length, and
`ipv6_rx_packet()` receives a `len` argument without using it to bound
parsing. A forged `ipv6_plen` can therefore exceed the real IPv6 payload
stored in the buffer. The available evidence supports MTU-bounded
out-of-bounds access in normal receive paths rather than the earlier
arbitrary 64KB worst case. The affected logic appears to be present in the
available 6.2.1.11 code base, but this report is scoped to the scanned SRPM
package.
Steps to reproduce:
1. Build `iscsiuio` with ASAN enabled.
2. Run `iscsiuio` with IPv6/NDP active on a test interface.
3. From the same L2 segment, send an ICMPv6 Echo Request with `IPv6.plen`
set larger than the actual payload bytes in the frame buffer; one tested
shape is `plen=1491` with an Ethernet frame size near 1500 bytes.
4. Observe the reply path: ASAN reports invalid access in
`ipv6_insert_protocol_chksum()` as the checksum walk reads past valid
packet data, odd lengths may also trigger a one-byte write, and reply
sizing is derived from the forged `ipv6_plen` rather than the actual
received payload size.
Mitigation: Until a fix is available, keep `iscsiuio`-managed interfaces on
trusted L2 segments only. Where operationally acceptable, disable IPv6 on
those interfaces or filter ICMPv6 Echo Requests before they reach
`iscsiuio`. If `iscsiuio` is not processing IPv6/NDP traffic, this specific
path is not reachable.
Proposed Fix: Clamp the reply payload length to the actual received payload
derived from `context->ustack->uip_len`, reject packets too short to
contain a complete ICMPv6 header, and rewrite `ipv6->ipv6_plen` before
calling `ipv6_send()`.
```diff
diff --git a/iscsiuio/src/uip/ipv6.c b/iscsiuio/src/uip/ipv6.c
@@ -1100,6 +1100,8 @@ static void ipv6_icmp_handle_echo_request(struct
ipv6_context *context)
{
struct eth_hdr *eth =
(struct eth_hdr *)context->ustack->data_link_layer;
+u16_t rx_total, rx_payload, hdr_plen, safe_plen;
+u16_t l2_l3_len = sizeof(struct eth_hdr) + sizeof(struct ipv6_hdr);
struct ipv6_hdr *ipv6 =
(struct ipv6_hdr *)context->ustack->network_layer;
struct icmpv6_hdr *icmp = (struct icmpv6_hdr *)((u8_t *)ipv6 +
@@ -1126,8 +1128,20 @@ static void ipv6_icmp_handle_echo_request(struct
ipv6_context *context)
icmp->icmpv6_code = 0;
icmp->icmpv6_cksum = 0;
ILOG_DEBUG("IPv6: Send echo reply");
-ipv6_send(context, (u8_t *) icmp - (u8_t *) eth +
sizeof(struct ipv6_hdr) + HOST_TO_NET16(ipv6>ipv6_plen));
+
+rx_total = context->ustack->uip_len;
+if (rx_total <= l2_l3_len)
+return;
+
+rx_payload = rx_total - l2_l3_len;
+hdr_plen = HOST_TO_NET16(ipv6->ipv6_plen);
+safe_plen = (hdr_plen <= rx_payload) ? hdr_plen : rx_payload;
+if (safe_plen < sizeof(struct icmpv6_hdr))
+return;
+
+ipv6->ipv6_plen = HOST_TO_NET16(safe_plen);
+ipv6_send(context, l2_l3_len + safe_plen);
+
return;
}
```
------
This report was generated using AI technology. Always review AI-generated
content prior to use |
| Loofah is a general library for manipulating and transforming HTML/XML documents and fragments, built on top of Nokogiri. Prior to 2.25.2, Loofah's HTML5 sanitizer applies its local-reference restriction only to the xlink:href attribute on SVG use and feImage elements, while browsers also accept the plain href attribute. A crafted sanitized SVG can therefore reference an arbitrary same-origin external document; use may render external SVG content containing scripts or other dangerous content, and feImage may load external images for tracking. Applications that sanitize user-supplied SVG with Loofah's default allowlist are affected. This issue is fixed in version 2.25.2. |
| Shescape is a simple shell escape library for JavaScript. Prior to 2.1.14 and 3.0.1, this impacts users of Shescape on Unix systems that explicitly configure shell to Zsh, or true when the default shell is Zsh, using the escape and escapeAll. The Zsh options EXTENDED_GLOB and MAGIC_EQUAL_SUBST exacerbate the problem. In certain case, an attacker can leverage home directory expansion and extended glob syntax to obtain lists of files and directories on the system. Depending on what the command does, this may be used to leak more information. This issue is fixed in versions 2.1.14 and 3.0.1. |
| UpSnap is a wake on lan web app. Versions 4.4.1 through 5.3.5 are vulnerable to a missing-authentication / privilege-escalation chain in `pb.HandlerInitSuperuser` (`backend/pb/handlers.go:249`), reachable as `POST /api/upsnap/init-superuser`. The vulnerable code lacks any authentication, setup token, IP allow-list, or rate limit and is gated only by a `totalSuperusers > 0` count check — a condition that is false on every fresh install — allowing an unauthenticated network-adjacent attacker to register the initial superuser account, receive a long-lived JWT, and pivot to root remote code execution at `backend/networking/wake.go:43` (`exec.CommandContext(ctx, "/bin/sh", "-c", wake_cmd)`). Version 5.4.0 fixes the issue. |
| Netty is a network application framework for development of protocol servers and clients. In netty-codec-http2 prior to versions 4.1.135.Final and 4.2.15.Final, the `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it. A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Netty is a network application framework for development of protocol servers and clients. In netty-codec-haproxy prior to versions 4.1.135.Final and 4.2.15.Final, when decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls `header.retainedSlice(header.readerIndex(), length)` and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
