IBM Guardium Data Protection 12.0, 12.1, and 12.2 could allow a local attacker to obtain sensitive information due to cleartext storage of sensitive information in logs.

IBM OPENBMC FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, and FW1060.00 through FW1060.81 is affected by a vulnerability in the BMC firmware management interface. The host system can cause the BMC firmware management service to crash or allow a limited amount of BMC internal memory to be read, resulting in a confidentiality and availability impact to the managed system.

IBM PowerVM Hypervisor FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, FW1060.00 through FW1060.81, and FW950.00 through FW950.H3 is affected by a vulnerability in the partition resource dump interface. An attacker with authenticated administrator-level access to the HMC or service processor can obtain a limited snapshot of partition processor state. Successful exploitation results in a confidentiality impact to the managed system.

IBM Db2 Mirror for i 7.6, 7.5, and 7.4 could allow a local attacker to obtain sensitive information due to the use of the AES Electronic Codebook (ECB) mode for encryption.

IBM PowerVM Hypervisor FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, and FW1060.00 through FW1060.81 is affected by a vulnerability in a hypervisor call interface. An attacker with root access to a guest partition can read a limited amount of hypervisor memory, potentially exposing sensitive data belonging to the hypervisor or other guest partitions hosted on the same system, resulting in a confidentiality impact. The attacker has no control over which memory contents are returned. This vulnerability is of particular concern in multi-tenant environments where guests may run arbitrary OS images.

IBM Guardium Data Protection 12.2 could allow an administrative user to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system.

IBM Financial Transaction Manager (FTM) could allow a remote attacker to obtain sensitive information due to improper enforcement of mutual TLS authentication.

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a denial of service as a result of a buffer overflow in a PASE process. An authenticated attacker could leverage this to terminate their own process.

IBM WebSphere Application Server 9.0, and 8.5 is affected by an authorization bypass vulnerability.

IBM WebSphere Application Server 8.5 and 9.0 could allow a remote attacker to obtain sensitive information from the administrative console due to missing authorization checks.

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.

DOMPurify through 3.3.3 fails to sanitize DOM elements passed via INPLACE mode when the element originates from a different window/realm (e.g., an iframe's contentDocument). A cross-realm instanceof check in the private isNode() function returns false for foreign-realm nodes, causing DOMPurify to stringify the element (yielding '[object HTMLDivElement]'), silently reset INPLACE to false, and return the unsanitized element unchanged with any XSS payloads intact.

A vulnerability was determined in langchain-ai langgraph up to 1.2.4. The affected element is the function freeze of the file libs/langgraph/langgraph/internal/cache.py of the component Task Result Cache. This manipulation of the argument defaultcachekey causes use of weak hash. The attack is possible to be carried out remotely. The complexity of an attack is rather high. The exploitability is described as difficult. The exploit has been publicly disclosed and may be utilized. The pull request to fix this issue awaits acceptance.

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.