Apache Arrow R package: Arbitrary code execution when loading a malicious data file

A buffer-underflow vulnerability exists in GLib’s GVariant parser, specifically within bytestringparse() and stringparse(). The parser uses signed 32-bit integers (gint) as loop indices (i and j). When extremely large strings are parsed, these counters overflow into negative values, causing the parser to write to memory before the start of the allocated buffer (str[j++]). This results in a classic out-of-bounds write condition. Because GVariant parsing is often performed on attacker-influenced data, a remote attacker can trigger heap corruption, causing a crash or potentially achieving code execution. This flaw has been confirmed by maintainers and patched upstream.

A stack buffer overflow may lead to a crash, causing Denial of Service, or potentially remote code execution.

When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such as AES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters is copied into a fixed-size stack buffer without verifying that its length fits the destination. An attacker can supply a crafted CMS message with an oversized IV, causing a stack-based out-of-bounds write before any authentication or tag verification occurs.

Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable. Because the overflow occurs prior to authentication, no valid key material is required to trigger it. While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-based write primitive represents a severe risk.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable to this issue.

OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

Impact

Undici allows duplicate HTTP Content-Length headers when they are provided in an array with case-variant names (e.g., Content-Length and content-length). This produces malformed HTTP/1.1 requests with multiple conflicting Content-Length values on the wire.

Who is impacted: - Applications using undici.request(), undici.Client, or similar low-level APIs with headers passed as flat arrays - Applications that accept user-controlled header names without case-normalization

Potential consequences: - Denial of Service: Strict HTTP parsers (proxies, servers) will reject requests with duplicate Content-Length headers (400 Bad Request) - HTTP Request Smuggling: In deployments where an intermediary and backend interpret duplicate headers inconsistently (e.g., one uses the first value, the other uses the last), this can enable request smuggling attacks leading to ACL bypass, cache poisoning, or credential hijacking

Patches

Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later.

Workarounds

If upgrading is not immediately possible:

1. Validate header names: Ensure no duplicate Content-Length headers (case-insensitive) are present before passing headers to undici 2. Use object format: Pass headers as a plain object ({ 'content-length': '123' }) rather than an array, which naturally deduplicates by key 3. Sanitize user input: If headers originate from user input, normalize header names to lowercase and reject duplicates

Last updated 2 April 2026

A flaw was found in libarchive. On 32-bit systems, an integer overflow vulnerability exists in the zisofs block pointer allocation logic. A remote attacker can exploit this by providing a specially crafted ISO9660 image, which can lead to a heap buffer overflow. This could potentially allow for arbitrary code execution on the affected system.

A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest–Shamir–Adleman – Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.

A flaw was found in the Samba printing subsystem. Samba passes the client-controlled job description string to the command configured with the "print command" setting via the "%J" substitution character without escaping shell meta characters. A remote attacker could exploit this vulnerability by sending a specially crafted print job description that contains unescaped shell characters. This could lead to remote code execution on the affected system.

A flaw was found in Samba. A remote attacker can exploit a misconfiguration in Samba file servers and classic domain controllers that use the "check password script" feature. If this script is configured with the %u substitution character, the client-controlled username is passed without proper escaping of shell meta-characters. This vulnerability allows an attacker to achieve remote command execution on the affected system. This issue primarily affects non-standard configurations where the "check password script" is used with %u and the samba-dcerpcd service is started as a system service.

In an untrusted JMS environment, org.springframework.jms.support.converter.MappingJackson2MessageConverter and org.springframework.jms.support.converter.JacksonJsonMessageConverter allow arbitrary class instantiation, which can lead to unauthorized actions via gadget class deserialization.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Last updated 6 June 2026

Last updated 6 June 2026

NGINX ngxhttpproxyv2module and ngxhttpgrpcmodule vulnerability

Impact What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.

Who is impacted? This affects gRPC-Go servers that meet both of the following criteria: 1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx). 2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer): v1.79.3 The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation) Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

go func pathValidationInterceptor(ctx context.Context, req any, info grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) { if info.FullMethod == "" || info.FullMethod[0] != '/' { return nil, status.Errorf(codes.Unimplemented, "malformed method name") } return handler(ctx, req) }

// Ensure this is the FIRST interceptor in your chain s := grpc.NewServer( grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor), )

2. Infrastructure-Level Normalization If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

Last updated 6 July 2026

Apache Thrift: C++ JSON OOB read

A flaw in GnuTLS DTLS handshake parsing allows malformed fragments with zero length and non-zero offset, leading to an integer underflow during reassembly and resulting in an out-of-bounds read. This issue is remotely exploitable and may cause information disclosure or denial of service.

Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory

Impact

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.

When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation.

The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side, even if the application only requested a small chunk of data.

Affected usages

Applications and libraries using urllib3 version 2.5.0 and earlier to stream large compressed responses or content from untrusted sources.

stream(), read(amt=256), read1(amt=256), readchunked(amt=256), readinto(b) are examples of urllib3.HTTPResponse method calls using the affected logic unless decoding is disabled explicitly.

Remediation

Upgrade to at least urllib3 v2.6.0 in which the library avoids decompressing data that exceeds the requested amount.

If your environment contains a package facilitating the Brotli encoding, upgrade to at least Brotli 1.2.0 or brotlicffi 1.2.0.0 too. These versions are enforced by the urllib3[brotli] extra in the patched versions of urllib3.

Credits

The issue was reported by @Cycloctane. Supplemental information was provided by @stamparm during a security audit performed by 7ASecurity and facilitated by OSTIF.

Impact An out-of-bounds write may be triggered when loading a specially crafted PSD image. Pillow >= 10.3.0 users are affected.

Patches Pillow 12.1.1 will be released shortly with a fix for this.

Workarounds Image.open() has a formats parameter that can be used to prevent PSD images from being opened.

References Pillow 12.1.1 will add release notes at https://pillow.readthedocs.io/en/stable/releasenotes/index.html

--- Summary

The parse() function in flatted can use attacker-controlled string values from the parsed JSON as direct array index keys, without validating that they are numeric. Since the internal input buffer is a JavaScript Array, accessing it with the key "\\proto\\" returns Array.prototype via the inherited getter. This object is then treated as a legitimate parsed value and assigned as a property of the output object, effectively leaking a live reference to Array.prototype to the consumer. Any code that subsequently writes to that property will pollute the global prototype.

--- Root Cause

File: esm/index.js:29 (identical in cjs/index.js) const resolver = (input, lazy, parsed, $) => output => { for (let ke = keys(output), {length} = ke, y = 0; y < length; y++) { const k = ke[y]; const value = output[k]; if (value instanceof Primitive) { const tmp = input[value]; // Bug is here

No validation that value is a safe numeric index input is built as a plain Array. JavaScript's property lookup on arrays traverses the prototype chain for non-numeric keys. The key "\\proto\\" resolves to Array.prototype, which:

- has type "object" → passes the typeof tmp === object guard at line 30 - is not in the parsed Set yet → passes the !parsed.has(tmp) guard. - The reference to Array.prototype is then enqueued in lazy and later unconditionally assigned to the output object. --- Replication Steps const Flatted = require('flatted'); const parsed = Flatted.parse('[{"x":"proto"}]'); parsed.x.polluted = 'pwned'; console.log([].polluted); // Returns true --- Impact An attacker can supply a crafted flatted string to parse() that causes the returned object to hold a live reference to Array.prototype, enabling any downstream code that writes to that property to pollute the global prototype chain, potentially causing denial of service or code execution.

Recommended solution Validate that the index string represents an integer within the bounds of input before accessing it:

// Before (vulnerable) const tmp = input[value];

// After (safe) const idx = +value; // coerce boxed String → number const tmp = (Number.isInteger(idx) && idx >= 0 && idx < input.length) ? input[idx] : undefined;

Last updated 6 June 2026

Summary

A security vulnerability has been detected that allows attackers to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.

This is an incomplete fix for CVE-2024-41110.

Impact

If you don't use AuthZ plugins, you are not affected.

Using a specially-crafted API request, an attacker could make the Docker daemon forward the request to an authorization plugin without the body. The authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

Anyone who depends on authorization plugins that introspect the request body to make access control decisions is potentially impacted.

Workarounds

If unable to update immediately: - Avoid using AuthZ plugins that rely on request body inspection for security decisions. - Restrict access to the Docker API to trusted parties, following the principle of least privilege.

Credits

- 1seal / Oleh Konko (@1seal) - Cody (c@wormhole.guru) - Asim Viladi Oglu Manizada (@manizada)

Resources

- CVE-2024-41110 / GHSA-v23v-6jw2-98fq

Case-sensitive excludedSubtrees name constraints cause Auth Bypass in crypto/x509

Last updated 22 May 2026

Integer wraparound in multiple PostgreSQL server features allows an unprivileged database user to cause the server to undersize an allocation and write out-of-bounds. This may execute arbitrary code as the operating system user running the database. In applications that pass gigabyte-scale user inputs to the relevant database functions, the application input provider may achieve a segmentation fault. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.

Last updated 22 May 2026

Last updated 22 May 2026

A flaw was found in SSSD's LDAP sudo provider. When the ldapsudosearchbase option is not explicitly configured, SSSD searches the entire LDAP directory tree for sudoRole objects. An authenticated attacker with write access to any subtree can inject a sudoRole object granting root-level sudo privileges on all SSSD-enrolled hosts.

A flaw was found in Kubernetes that allows attackers on adjacent networks to reach services exposed on localhost ports, previously thought to be unreachable. This flaw allows an attacker to gain privileges or access confidential information for any services listening on localhost ports that are not protected by authentication.