IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to obtain sensitive information due to an out-of-bounds read.

IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to obtain sensitive information or cause a denial of service due to an integer overflow.

IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to obtain sensitive information due to a path traversal vulnerability.

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to delete arbitrary files due to path traversal.

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to perform file manipulation due to path traversal.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 and IBM Security Verify Access Container 10.0 through 10.0.9.2 Reverse Proxy in certain configurations is vulnerable to a denial of service attack.

DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) could allow a local attacker to cause a denial of service due to a memory leak.

IBM Business Automation Workflow containers and traditional 26.0.0, 25.0.0 through 25.0.0 Interim Fix 005, 24.0.1 through 24.0.1 Interim Fix 007, and 24.0.0 through 24.0.0 Interim Fix 009 IBM Business Automation Workflow fails to properly verify that the hostname matches the server certificate potentially allowing connections to an attacker-controlled server.

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. in versions 1.7.1 and prior, joserfc accepts JWTs with trailing padding (==) which are not conforming to the JOSE specifications. This leads to malleability of the JWTs when consumed by joserfc. Depending on this application this might or not be an issue. This could lead to bypass of token revocation or anti-replay protection when implemented as a deny list of tokens or a deny list of token hashes. Note that ECDSA JWS are always malleable because of the malleability of ECDSA signatures (first test case in the code bellow). This makes a scheme which assumes that JWTs are not malleable brittle. However for other signatures (or MAC) schemes it might make sense to assume non malleability of the token. This issue has been fixed in version 1.7.2.

A vulnerability was found in HdrHistogram up to 2.2.2. This issue affects the function org.HdrHistogram.DoubleHistogram.recordValue of the file src/main/java/org/HdrHistogram/DoubleHistogram.java of the component Range Check. Performing a manipulation results in incorrect comparison. The attack is only possible with local access. The exploit has been made public and could be used. The presence of this vulnerability remains uncertain at this time. This issue is disputed due to the potential lack of crossing of security boundaries and the pre-requisites for a successful attack.

A vulnerability has been found in HdrHistogram up to 2.2.2. This vulnerability affects the function recordValueWithCount of the file src/main/java/org/HdrHistogram/AbstractHistogram.java of the component AbstractHistogram. Such manipulation of the argument Count leads to state issue. The attack can only be performed from a local environment. The exploit has been disclosed to the public and may be used. The existence of this vulnerability is still disputed at present. This issue is disputed due to the potential lack of crossing of security boundaries and the pre-requisites for a successful attack.

A flaw has been found in HdrHistogram up to 2.2.2. This affects the function org.HdrHistogram.AbstractHistogram.decodeFromByteBuffer of the file src/main/java/org/HdrHistogram/AbstractHistogram.java. This manipulation of the argument numberOfSignificantValueDigits causes uncontrolled memory allocation. The attack can only be executed locally. The exploit has been published and may be used. The actual existence of this vulnerability is currently in question. This issue is disputed due to the potential lack of crossing of security boundaries and the pre-requisites for a successful attack.

A vulnerability was detected in HdrHistogram up to 2.2.2. Affected by this issue is the function org.HdrHistogram.AbstractHistogram.decodeFromCompressedByteBuffer of the file src/main/java/org/HdrHistogram/AbstractHistogram.java. The manipulation of the argument lengthOfCompressedContents results in uncontrolled memory allocation. The attack needs to be approached locally. The exploit is now public and may be used. It is still unclear if this vulnerability genuinely exists. This issue is disputed due to the potential lack of crossing of security boundaries and the pre-requisites for a successful attack.

Summary

oras-go's auth.Client follows the realm URL from a registry's WWW-Authenticate: Bearer challenge without validating its scheme or host. The realm field is server-controlled by design in the OCI/distribution spec — registries legitimately point token requests at a separate auth endpoint (e.g. Docker Hub's registry-1.docker.io -> auth.docker.io), so cross-host realms on public DNS names are not in themselves a vulnerability. Two specific patterns, however, are never legitimate under any registry trust model and can be abused by a malicious or compromised registry (or a man-in-the-middle on a plaintext connection):

1. SSRF to internal networks. A realm of http://169.254.169.254/... (AWS/Azure IMDS), http://10.0.0.x/... (RFC 1918), or http://127.0.0.1/... causes oras-go running on a cloud VM or corporate workstation to issue outbound HTTP requests from inside the user's trust boundary to an endpoint the user did not choose. The user's stored credentials are attached to those requests, but the principal harm is the network primitive — probing internal endpoints from the client. On IMDSv1 the response body is recoverable from log channels; on IMDSv2 the probe itself can still be used for service discovery.

2. TLS downgrade. A registry contacted over https:// can return a realm with an http:// scheme, causing oras-go to send the user's credentials over plaintext to the token endpoint. This defeats the transport security the user chose when typing https://.

What is NOT claimed

This advisory does not claim that credential forwarding to an arbitrary public attacker host through a server-controlled realm is, on its own, a vulnerability. The distribution spec defines realm as a server-controlled field; a strict same-host or same-eTLD+1 enforcement would deviate from the spec and break legitimate split-host deployments. Operators who want defense-in-depth against cross-host realm forwarding can use the opt-in Client.TrustedRealmHosts allowlist (added separately).

Affected versions

oras.land/oras-go/v2 <= v2.6.0

Severity

Medium. Network attack vector, low complexity, no privileges required, user interaction required (victim runs an oras command against the malicious or MITM'd registry), unchanged scope. Confidentiality impact is limited — IMDS probe responses can disclose information, and TLS downgrade exposes the realm request to passive observers — but the attacker does not obtain credentials beyond what the malicious endpoint already controls.

Affected code

- registry/remote/auth/client.go — Client.Do() (bearer challenge handling) - registry/remote/auth/client.go — Client.fetchBearerToken() / fetchDistributionToken / fetchOAuth2Token

The realm parameter from parseChallenge is threaded through to http.NewRequestWithContext without scheme or host validation.

CWE

- CWE-918: Server-Side Request Forgery (SSRF) - CWE-319: Cleartext Transmission of Sensitive Information

Patch

registry/remote/auth/client.go now rejects realm URLs that:

- use a scheme other than http or https - use http when the registry was contacted over https (TLS downgrade) - use an IP literal in a loopback, link-local, private, or unspecified range, unless the registry itself was reached at the same hostname (so loopback / in-cluster deployments are unaffected)

Cross-host realms on public DNS names continue to be accepted.

Credit

Reported by bugbunny.ai.

Summary

JSON.dump(obj, io) and JSON::State#generate(obj, io) can write past the internal JSON generator buffer when a streamed object contains an attacker-controlled string near 16 KB. The issue is a heap out-of-bounds write in the IO-streaming path and is demonstrated as a reliable process crash / denial of service.

This was triaged on HackerOne as report #3785370. The issue was confirmed there and I was asked to open it here.

Details

Root cause is in ext/json/fbuffer/fbuffer.h, fbufferdoinccapa().

On the IO path, the buffer is grown to FBUFFERIOBUFFERSIZE (16383), but the early return checks total capacity instead of remaining capacity:

c if (RBUNLIKELY(fb->io)) { if (fb->capa < FBUFFERIOBUFFERSIZE) { fbufferrealloc(fb, FBUFFERIOBUFFERSIZE); } else { fbufferflush(fb); }

if (RBLIKELY(requested < fb->capa)) { return; } }

If fb->len already contains JSON syntax bytes, and a string flush has 16383 - fb->len <= requested < 16383, this check returns even though there is not enough space left. fbufferappendreserved() then writes past the buffer:

c MEMCPY(fb->ptr + fb->len, newstr, char, len);

The minimal fix is to compare against the remaining capacity:

diff - if (RBLIKELY(requested < fb->capa)) { + if (RBLIKELY(requested <= fb->capa - fb->len)) { return; }

PoC

ruby require "json" require "stringio"

io = StringIO.new big = "a" 16385 big[16382] = '"' # escapable byte near the buffer boundary

JSON.dump([big], io)

Verified results:

text Ruby 4.0.5 / bundled json 2.18.0: malloc(): invalid size (unsorted) .../json/common.rb:956: [BUG] Aborted

ruby/ruby master c78418b7a0 / json 2.19.8 / ASan: heap-buffer-overflow WRITE of size 16382 fbufferappendreserved ext/json/fbuffer/fbuffer.h:145 searchflush ext/json/generator/generator.c:139 convertUTF8toJSON ext/json/generator/generator.c:231 rawgeneratejsonstring ext/json/generator/generator.c:922 cStatemgenerate ext/json/generator/generator.c:1891

Control: the same data through JSON.dump([big]) without an IO argument returns normally. The bug is specific to the IO-streaming path.

Impact

A remote attacker can trigger a heap out-of-bounds write if they control a string field that an application serializes through JSON.dump(obj, io) or JSON::State#generate(obj, io). The demonstrated impact is reliable denial of service. I am not claiming code execution or information disclosure.

Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, XInclude substitution performed by Nokogiri::XML::Node#doxinclude replaced each <xi:include> in place, freeing the include node along with its children (such as <xi:fallback> and its descendants) and any namespaces declared on them. If an application had already exposed one of those nodes or namespaces to Ruby, the corresponding Ruby object was left pointing at freed memory. Using the object could result in invalid reads or writes to memory. This vulnerability is fixed in 1.19.4.

Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri::XML::XPathContext did not keep its source document alive for garbage collection. If an XPathContext outlived its document and the document was collected, evaluating an XPath expression could read invalid memory and potentially segfault. This is only reachable when application code constructs an XPathContext directly and lets the document become unreachable while continuing to use the context. The normal Document#xpath, #css, and related search methods are not affected, and it is not triggerable by malicious document input. This vulnerability is fixed in 1.19.4.

Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri::XML::Document#root= validated only that the new root was a Nokogiri::XML::Node, allowing a DTD node to be set as the document root. The result is a heap use-after-free during garbage collection or finalization, leading to an invalid memory read or potentially a segfault. This vulnerability is fixed in 1.19.4.

Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri’s CRuby native extension could leave a Ruby wrapper pointing to freed memory when replacing the value of an XML attribute. If Ruby code had already accessed an attribute child node, Nokogiri::XML::Attr#value= could free the underlying native child node while the wrapper remained reachable through the document node cache. A later use of the freed child node or a Ruby GC mark could dereference an invalid pointer, causing an invalid read and a possible segfault. This vulnerability is fixed in 1.19.4.

Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri contains a bug when calling certain methods on allocated-but-uninitialized native wrapper classes that inherit from Nokogiri::XML::Node. This caused a NULL pointer dereference that could crash the process. This vulnerability is fixed in 1.19.4.

Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, calling Document#encoding= with an invalid encoding (e.g., a non-string, or a string containing a null byte) raises an exception, but only after freeing the document's current encoding string without replacing it. The document is left referencing freed memory, so the next call to Document#encoding reads invalid memory, which can cause a segfault or leak freed bytes into a Ruby String. Affects the CRuby (libxml2) implementation only; JRuby is not affected. This vulnerability is fixed in 1.19.4.

Summary

Oj::Parser#parse is vulnerable to a heap use-after-free when a SAJ/SAJ2 callback mutates the input JSON string during parsing. The C engine holds a raw const byte pointer into the Ruby string's internal buffer. If a callback (e.g. hashstart) resizes the string — for example by calling String#replace with a longer value — Ruby reallocates the string buffer and frees the old one. The C parser's pointer is left dangling; the next character read at parser.c:607 is a use-after-free.

Version

- Software: oj gem - Affected: all versions with ext/oj/parser.c - Latest tested: 3.17.1 (confirmed present)

Details

ext/oj/parser.c, parserparse → parse:

c static VALUE parserparse(VALUE self, VALUE json) { const byte ptr = (const byte )StringValuePtr(json); // raw pointer into Ruby string // ... parse(p, ptr); // ptr used throughout; any realloc frees the backing buffer }

c // parser.c:607 static void parse(ojParser p, const byte json) { const byte b = json; // ... for (; '\0' != b; b++) { // ← UAF: reads freed memory after callback resizes json

Ruby's String#replace (or <<, gsub!, etc.) can trigger a reallocation of the string's internal buffer if the new content is larger than the embedded capacity, freeing the old buffer that ptr still points to.

ASAN report: ==372273==ERROR: AddressSanitizer: heap-use-after-free on address 0x51900008ed81 READ of size 1 at 0x51900008ed81 thread T0 #0 parse /ext/oj/parser.c:607 #1 parserparse /ext/oj/parser.c:1408 0x51900008ed81 is located 1 bytes inside of 1023-byte region [0x51900008ed80, 0x51900008f17f) freed by thread T0 here: #0 free #1 rubysizedxfree (libruby-3.3.so.3.3) Shadow bytes: [fd]fd fd fd fd fd ... (entire region freed)

Reproduce

ruby require 'oj'

class Mutator def initialize(json) = (@json = json; @done = false)

def hashstart(key) return if @done; @done = true @json.replace('x' 1000000) # triggers String realloc, frees original buffer end

def hashend(key); end def arraystart(key); end def arrayend(key); end def addvalue(value, key); end end

json = '{"a":1,"pad":"' + ('A' 1000) + '","z":2}' parser = Oj::Parser.new(:saj) parser.handler = Mutator.new(json) parser.parse(json)

Summary

Oj::Doc iterators (eachvalue, eachchild, eachleaf) are vulnerable to a heap use-after-free. When a Ruby block yielded during iteration calls doc.close or d.close, the document's heap memory is freed while the C iterator is still running. When control returns from the block, the iterator reads from the freed region, producing a use-after-free accessible from pure Ruby.

Version

- Software: oj gem - Affected: all versions with ext/oj/fast.c - Latest tested: 3.17.1 (confirmed present)

Details

The iterators in ext/oj/fast.c follow the pattern:

c // fast.c:1505 (doceachchild) static VALUE doceachchild(VALUE self, ...) { ... while (cur != NULL) { rbyield(...); // ← Ruby block executes here cur = cur->next; // ← cur is now freed if block called close() } }

rbyield can invoke arbitrary Ruby code, including calling close() on the Doc or any child node, which calls rubysizedxfree on the backing buffer. On return, the C code reads cur->next from the freed region. All three iterators are affected.

ASAN report (eachchild variant): ==253632==ERROR: AddressSanitizer: heap-use-after-free on address 0x5210000bd080 READ of size 8 at 0x5210000bd080 thread T0 #0 doceachchild /ext/oj/fast.c:1505 0x5210000bd080 is located 896 bytes inside of 4064-byte region [0x5210000bcd00, 0x5210000bdce0) freed by thread T0 here: #0 free #1 rubysizedxfree (libruby-3.3.so.3.3)

All three iterators trigger the same freed region (fd shadow bytes): 0x5210000bd080:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

Reproduce

ruby require 'oj' eachchild Oj::Doc.open('[1,2]') { |doc| doc.eachchild { |d| d.close } } eachvalue Oj::Doc.open('[1,2]') { |doc| doc.eachvalue { |v| doc.close } } eachleaf Oj::Doc.open('[1,[2]]') { |doc| doc.eachleaf { |d| d.close } }

Summary

Oj.dump in object mode is vulnerable to a heap buffer overflow when serializing Exception objects with a large :indent value. The serializer allocates a buffer sized for the object's attributes but does not account for the indent bytes added on each write. With indent: 5000, the accumulation of 5,000-byte indent strings overflows the 13,150-byte heap allocation, corrupting adjacent heap memory.

Version

- Software: oj gem - Affected: all versions with ext/oj/dump.h - Latest tested: 3.17.1 (confirmed present)

Details

ext/oj/dump.h, line 75–77:

c static void fillindent(Out out, int depth) { if (0 < out->opts->indent) { memset(out->buf + out->cur, ' ', (sizet)(out->opts->indent depth));

When dumping an Exception object in :object mode, dumpobjattrs calls fillindent repeatedly for each attribute. The buffer is pre-allocated based on the serialized content but not the indentation overhead. With indent: 5000 the indent block for a nested object exceeds the remaining buffer space, producing a heap-buffer-overflow of size 5,000 at the end of the allocated region.

ASAN report: ==101656==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x527000022c5e WRITE of size 5000 at 0x527000022c5e thread T0 #0 memset #1 fillindent /ext/oj/dump.h:77 #2 dumpobjattrs /ext/oj/dumpobject.c:552 #3 dumpobj /ext/oj/dumpobject.c:80 #4 ojdumpobjval /ext/oj/dumpobject.c:708 #5 ojdumpobjtojsonusingparams /ext/oj/dump.c:817 #6 dumpbody /ext/oj/oj.c:1429 #7 dump /ext/oj/oj.c:1480 0x527000022c5e is located 0 bytes after 13150-byte region [0x52700001f900, 0x527000022c5e)

Reproduce

ruby require "oj" obj = Oj.load('{"^o":"RuntimeError"}', mode: :object) Oj.dump(obj, mode: :object, indent: 5000)

Workarounds

This is at the discretion of the developer and not a public facing option so the workaround is the develop should not use extreme indents and should not offer the option for users to dump Ruby data with unlimited indentation size.

Impact

When undici parses a Set-Cookie header, it accepts any SameSite attribute value that contains Strict, Lax, or None as a substring, rather than the case-insensitive exact match specified by RFC 6265. Non-spec values are silently mapped to one of the three standard tokens:

- SameSite=NoneOfYourBusiness is parsed as None, the most permissive setting. - SameSite=StrictLax is parsed as Lax, a downgrade from Strict.

Affected applications are those that consume Set-Cookie headers from server responses (for example via undici's fetch or proxy code paths) and then forward or rely on the parsed sameSite attribute. A malicious or non-compliant server can coerce the consumer's view of a cookie's SameSite policy to a weaker value, silently degrading the SameSite enforcement the cookie is supposed to provide.

This was introduced in undici 5.15.0 when the cookies feature was added.

Patches

Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.

Workarounds

After parsing a Set-Cookie header, validate that the resulting sameSite attribute is one of 'Strict', 'Lax', or 'None' (exact, case-insensitive) before forwarding or relying on it.

Impact

Undici's HTTP/1.1 client is vulnerable to response queue poisoning on reused keep-alive sockets. An attacker-controlled upstream server can inject an unsolicited HTTP/1.1 response onto an idle socket after a request completes. When the client dispatches the next request on that socket, it associates the injected response with the new request, causing responses to be delivered to the wrong requests.

This requires an attacker-controlled or compromised upstream HTTP/1.1 server and keep-alive connection reuse.

Patches

Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.

Workarounds

Disable keep-alive connection reuse by setting keepAliveTimeout: 0 on the Client or Pool.

Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection, albeit heavily restricted.

More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate Proxy objects.

Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions.

This issue affects logback: through 1.5.33 inclusive.

[!NOTE] The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. Impact is reduced auth availability until the next successful fetch, not complete denial of service.

Summary PyJWKClient.getsigningkey() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests.

Additionally, fetchdata() finally block clears the JWKS cache on network error.

Root Cause jwt/jwksclient.py:172-198 - getsigningkey(kid) calls getsigningkeys(refresh=True) for unknown kids, bypassing TTL cache with no cooldown. jwt/jwksclient.py:120-122 - finally block writes None to cache on error, clearing valid data.

Impact - DoS against JWKS endpoint (unlimited requests per invalid token) - DoS against application (network I/O latency) - Cascading failure (rate limiting clears cache, breaking legitimate auth)

Suggested Fix 1. Add refresh cooldown (refuse refresh more than once per TTL period) 2. Move cache write from finally to else block

Affected Versions All versions with PyJWKClient (2.4.0 through 2.12.1)

Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection albeit heavily restricted.

More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate objects from classes in the java.lang and java.util packages that are not explicitly blocked.

Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions.

This issue affects logback: through 1.5.32 inclusive.

Observable Timing Discrepancy vulnerability when comparing AJP secret in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109. Older unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.