Categories
CVE-2026-48040 critical CVSS 9.1

Out-of-Bounds Read in io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl (CVE-2026-48040)

Summary

Vulnerability in io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl (CVE-2026-48040). Confidential information can be exposed externally. Exploitable via sun.misc.Unsafe. Mitigation: upgrade to 0.0.22.Final or later.

Original description

The description as published by the source.

The netty incubator codec.bhttp is a java language binary http parser. The library implements Oblivious HTTP (RFC 9458) using BoringSSL's HPKE C library via JNI. When deriving native memory addresses for cryptographic operations versions prior to 0.0.22.Final provide a fallback path for direct ByteBufs that do not expose their memory address through hasMemoryAddress(). This fallback occurs when sun.misc.Unsafe is unavailable to Netty — for example, when the JVM is started with -Dio.netty.noUnsafe=true, when a SecurityManager restricts Unsafe access, or when running on non-HotSpot JVMs. In these configurations, Netty's default PooledByteBufAllocator returns PooledDirectByteBuf instances for which hasMemoryAddress() returns false. Under the enabling JVM configuration, an unauthenticated network attacker can cause the OHTTP gateway to corrupt memory belonging to other concurrent connections and disclose the contents of adjacent pooled direct buffers by triggering cryptographic operations with crafted OHTTP requests. The corruption occurs regardless of whether the AEAD tag verification succeeds, as BoringSSL zeroizes the output buffer on failure. The information disclosure path provides the attacker with the encryption key needed to extract the leaked data. This violates the confidentiality and integrity of all connections sharing the same Netty buffer arena. Version 0.0.22.Final fixes the issue.

Source: NIST National Vulnerability Database NVD GitHub Advisory

Auto-generated summary

Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.

A vulnerability tracked as CVE-2026-48040 has been found in io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl.
Attackers can target a specific entry point like sun.misc.Unsafe over the network to misuse the product.
Confidential information can be exposed externally. CVSS score: 9.1/10.
What to do: upgrade io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl to 0.0.22.Final or later.
If unsure, ask your IT team or search "io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl CVE-2026-48040" on the vendor's site.

CVE-2026-48040 (io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl) — CWE-125 / CVSS v3 9.1
Attack vector: remote (network-reachable) / unauthenticated / no user interaction
Attack surface: sun.misc.Unsafe / PooledByteBufAllocator / PooledDirectByteBuf
Patched: 0.0.22.Final — apply immediately
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.

❓ What is the problem

Out-of-bounds read (CWE-125) exists in io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl. Attackers reach the vulnerable code path via sun.misc.Unsafe without authentication.

📍 Affected scope

Check the vendor advisory for the affected versions of io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl. Attack surface: sun.misc.Unsafe / PooledByteBufAllocator / PooledDirectByteBuf.

🔥 Severity

Severity: Critical (CVSS 9.1/10). Confidential information can be exposed externally.

🔧 How to fix

Update to 0.0.22.Final.

🛡️ Workaround

Until the patch is applied: disable the affected feature, apply WAF rules, or restrict access via network ACLs.

🔍 Detection

Search webserver/proxy logs for unusual request patterns matching this CVE's known IOCs. Audit SBOM/dependencies to find affected services.

Response actions

Concrete steps and command examples for SOC/SRE teams to execute in order

  1. 1
    Identify exposure identify
    Audit SBOM/dependencies for affected components.

    資産台帳・SBOM・依存マニフェストで io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl を使っているサービスとバージョンを洗い出す。

  2. 2
    Apply patch patch
    Upgrade io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl to 0.0.22.Final

    ステージング環境で 0.0.22.Final に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスを含めること。

  3. 3
    Post-deployment verification verify
    Confirm patched version is live in production

    パッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番ではアクセスログ・WAF でアラート再発が無いか継続監視。

Affected packages

maven io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl
[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.22.Final"}]}]

References

We use cookies for analytics and ad measurement. This setting applies to all Game co., Ltd. sites. Details