Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The netty-incubator-codec-ohttp library implements Oblivious HTTP (OHTTP) gateway and client functionality using Netty's ByteBuf memory management. When an OHTTP gateway processes encrypted client requests, it allocates a pooled direct (native off-heap) ByteBuf to hold the decrypted plaintext before the AEAD tag is verified. If the AEAD tag check fails — meaning the ciphertext is invalid — the decryption method throws a CryptoException, but the allocated buffer is never released because no try/finally block guards the allocation.
Recommended action: Upgrade to 0.0.23.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The codec-ohttp implementation of draft-ietf-ohai-chunked-ohttp does not verify that a cryptographically-signed final chunk was received before the outer HTTP body terminates. An on-path adversary (the OHTTP relay itself, or any MITM on the relay↔gateway or relay↔client transport) can forward a prefix of a legitimate chunked-OHTTP message—cut at a non-final chunk boundary—and close the outer body cleanly, producing no decryption error and no exception in the receiving application.
Recommended action: Upgrade to 0.0.22.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HKDFexpand: returns non-NULL on failure. The byte[] is filled with zeros and has no way to distinguish success from failure. Since this output is used as HKDF key material for the response AEAD, a failure silently produces an all-zero key. When EVPHPKECTXexport fails it also returns an empty byte[] array filled with zeros. This byte[] feeds directly into OHttpCrypto.createResponseAEAD(...). A silent all-zero export secret would produce a deterministic, attacker-predictable AEAD key.
Recommended action: Upgrade to 0.0.21.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
BoringSSLAEADContext keeps track of how many OHTTP responses have been sent and uses this sequence number to calculate the appropriate nonce to use with the encryption algorithm. Unfortunately, two separate errors combine which would allow an attacker to cause the sequence number to overflow and thus the nonce to repeat. Details 1. There is no overflow detection or enforcement of the maximum sequence value. (This is a missed requirement from the draft Chunked Oblivious OHTTP RFC and so should be inherited from the HPKE RFC 9180, Section 5.2). 2. The sequence number (seq) is stored as 32-bit int which is relatively easy to overflow. https://github.com/netty/netty-incubator-codec-ohttp/blob/1ddadb6473cd3be5491d114431ed4c1a9f316001/codec-ohttp-hpke-classes-boringssl/src/main/java/io/netty/incubator/codec/hpke/boringssl/BoringSSLAEADContext.java#L112-L114 Impact If the BoringSSLAEADContext is used to encrypt more than 2^32 messages then the AES-GCM nonce will repeat. Repeating a…
Recommended action: Upgrade to 0.0.11.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.