Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package stargate version 1.0.90-r4 fixes 87 vulnerabilities: ghsa-76h9-2vwh-w278, ghsa-pqr6-cmr2-h8hf, ghsa-fjpj-2g6w-x25r, ghsa-qcwq-55hx-v3vh, ghsa-55g7-9cwv-5qfv...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "stargate"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.90-r4"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.0.90-r4"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package stargate version 1.0.90-r4 fixes 87 vulnerabilities: ghsa-76h9-2vwh-w278, ghsa-pqr6-cmr2-h8hf, ghsa-fjpj-2g6w-x25r, ghsa-qcwq-55hx-v3vh, ghsa-55g7-9cwv-5qfv...",
"id": "CLEANSTART-2026-CU18187",
"modified": "2026-07-30T09:30:59Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/stargate/stargate"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in stargate 1.0.90-r4",
"upstream": [
"ghsa-76h9-2vwh-w278",
"ghsa-pqr6-cmr2-h8hf",
"ghsa-fjpj-2g6w-x25r",
"ghsa-qcwq-55hx-v3vh",
"ghsa-55g7-9cwv-5qfv",
"ghsa-4g8c-wm8x-jfhw",
"ghsa-q4rv-gq96-w7c5",
"ghsa-g8m5-722r-8whq",
"ghsa-j26w-f9rq-mr2q",
"ghsa-xq3w-v528-46rv",
"ghsa-389x-839f-4rhx",
"ghsa-3p8m-j85q-pgmj",
"ghsa-269q-hmxg-m83q",
"ghsa-5jpm-x58v-624v",
"ghsa-84h7-rjj3-6jx4",
"ghsa-fghv-69vj-qj49",
"ghsa-jq43-27x9-3v86",
"ghsa-prj3-ccx8-p6x4",
"ghsa-xpw8-rcwv-8f8p",
"ghsa-6mjq-h674-j845",
"ghsa-fx2c-96vj-985v",
"ghsa-h9mq-f6q5-6c8m",
"ghsa-g5ww-5jh7-63cx",
"ghsa-735f-pc8j-v9w8",
"ghsa-4gg5-vx3j-xwc7",
"ghsa-h4h5-3hr4-j3g2",
"ghsa-mvr2-9pj6-7w5j",
"ghsa-7g45-4rm6-3mm3",
"ghsa-5mg8-w23w-74h3",
"ghsa-gvpg-vgmx-xg6w",
"ghsa-xwmg-2g98-w7v9",
"ghsa-wxr5-93ph-8wr9",
"ghsa-cfxw-4h78-h7fw",
"ghsa-78wr-2p64-hpwj",
"ghsa-493p-pfq6-5258",
"ghsa-264p-99wq-f4j6",
"ghsa-pr98-23f8-jwxv",
"ghsa-25qh-j22f-pwp8",
"ghsa-6v67-2wr5-gvf4",
"ghsa-qqpg-mvqg-649v",
"ghsa-j288-q9x7-2f5v",
"CVE-2024-52046",
"CVE-2021-41973",
"CVE-2022-41881",
"CVE-2023-34462",
"CVE-2023-44487",
"CVE-2022-24823",
"CVE-2024-29025",
"CVE-2025-67735",
"CVE-2025-58056",
"CVE-2025-58057",
"CVE-2025-55163",
"CVE-2025-59419",
"CVE-2024-47535",
"CVE-2025-25193",
"CVE-2025-24970",
"CVE-2023-34455",
"CVE-2023-43642",
"CVE-2023-34453",
"CVE-2023-34454",
"CVE-2024-21634",
"CVE-2023-1370",
"CVE-2025-23015",
"CVE-2018-10237",
"CVE-2023-2976",
"CVE-2020-8908",
"CVE-2024-7254",
"CVE-2022-3509",
"CVE-2022-3510",
"CVE-2022-3171",
"CVE-2024-40094",
"CVE-2023-52428",
"CVE-2025-53864",
"CVE-2025-48734",
"CVE-2024-47554",
"CVE-2024-25638",
"CVE-2024-35255",
"CVE-2026-1225",
"CVE-2024-12798",
"CVE-2025-11226",
"CVE-2024-12801",
"CVE-2024-13009",
"CVE-2024-8184",
"CVE-2024-9823",
"CVE-2024-6763",
"CVE-2025-48924",
"CVE-2025-46392"
]
}
GHSA-76H9-2VWH-W278
Vulnerability from github – Published: 2024-12-25 12:30 – Updated: 2025-02-12 18:18The ObjectSerializationDecoder in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks.
This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4.
It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the ObjectSerializationCodecFactory class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library.
Upgrading will not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods:
-
* Accept class names where the supplied ClassNameMatcher matches for deserialization, unless they are otherwise rejected.
@param classNameMatcherthe matcher to use- /
public void accept(ClassNameMatcher classNameMatcher)
-
- Accept class names that match the supplied pattern for deserialization, unless they are otherwise rejected.
@parampattern standard Java regexp- /
public void accept(Pattern pattern)
3.
* Accept the wildcard specified classes for deserialization, unless they are otherwise rejected.
* @param patterns Wildcard file name patterns as defined by {@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch}
* / public void accept(String... patterns)
By default, the decoder will reject all classes that will be present in the incoming data.
Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.mina:mina-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.mina:mina-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.1.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.mina:mina-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0-M1"
},
{
"fixed": "2.0.27"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52046"
],
"database_specific": {
"cwe_ids": [
"CWE-502",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-26T15:59:46Z",
"nvd_published_at": "2024-12-25T10:15:05Z",
"severity": "CRITICAL"
},
"details": "The `ObjectSerializationDecoder` in Apache MINA uses Java\u2019s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks.\n\t\nThis issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4.\n\nIt\u0027s also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the `ObjectSerializationCodecFactory` class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library.\n\nUpgrading will\u00a0 not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods:\n\n1. \n\u00a0 \u00a0\u00a0 * Accept class names where the supplied ClassNameMatcher matches for deserialization, unless they are otherwise rejected.\n * `@param classNameMatcher` the matcher to use\n * / `public void accept(ClassNameMatcher classNameMatcher)`\n\n2. \n * Accept class names that match the supplied pattern for deserialization, unless they are otherwise rejected.\n * `@param` pattern standard Java regexp\n * / `public void accept(Pattern pattern)`\n\n3.\n * Accept the wildcard specified classes for deserialization, unless they are otherwise rejected.\n * `@param` patterns Wildcard file name patterns as defined by `{@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch}`\n * / `public void accept(String... patterns)`\n\nBy default, the decoder will reject *all* classes that will be present in the incoming data.\n\nNote: The FtpServer, SSHd and Vysper sub-project are not affected by this issue.",
"id": "GHSA-76h9-2vwh-w278",
"modified": "2025-02-12T18:18:48Z",
"published": "2024-12-25T12:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52046"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/mina"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/4wxktgjpggdbto15d515wdctohb0qmv8"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250103-0001"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/12/25/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Apache MINA Deserialization RCE Vulnerability"
}
GHSA-78WR-2P64-HPWJ
Vulnerability from github – Published: 2024-10-03 12:30 – Updated: 2025-01-31 15:30Uncontrolled Resource Consumption vulnerability in Apache Commons IO.
The org.apache.commons.io.input.XmlStreamReader class may excessively consume CPU resources when processing maliciously crafted input.
This issue affects Apache Commons IO: from 2.0 before 2.14.0.
Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "commons-io:commons-io"
},
"ranges": [
{
"events": [
{
"introduced": "2.0"
},
{
"fixed": "2.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-47554"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-03T16:52:23Z",
"nvd_published_at": "2024-10-03T12:15:02Z",
"severity": "HIGH"
},
"details": "Uncontrolled Resource Consumption vulnerability in Apache Commons IO.\n\nThe `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input.\n\n\nThis issue affects Apache Commons IO: from 2.0 before 2.14.0.\n\nUsers are recommended to upgrade to version 2.14.0 or later, which fixes the issue.",
"id": "GHSA-78wr-2p64-hpwj",
"modified": "2025-01-31T15:30:42Z",
"published": "2024-10-03T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47554"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/commons-io"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/6ozr91rr9cj5lm0zyhv30bsp317hk5z1"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250131-0010"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/10/03/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"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": "Apache Commons IO: Possible denial of service attack on untrusted input to XmlStreamReader"
}
GHSA-7G45-4RM6-3MM3
Vulnerability from github – Published: 2023-06-14 18:30 – Updated: 2025-11-04 16:44Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.
Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.guava:guava"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "32.0.0-android"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-2976"
],
"database_specific": {
"cwe_ids": [
"CWE-379",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-14T21:01:07Z",
"nvd_published_at": "2023-06-14T18:15:09Z",
"severity": "MODERATE"
},
"details": "Use of Java\u0027s default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.\n\nEven though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.",
"id": "GHSA-7g45-4rm6-3mm3",
"modified": "2025-11-04T16:44:26Z",
"published": "2023-06-14T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2976"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/2575"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/6532"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/commit/feb83a1c8fd2e7670b244d5afd23cba5aca43284"
},
{
"type": "PACKAGE",
"url": "https://github.com/google/guava"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/releases/tag/v32.0.0"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230818-0008"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241108-0002"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01006.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Guava vulnerable to insecure use of temporary directory"
}
GHSA-84H7-RJJ3-6JX4
Vulnerability from github – Published: 2025-12-15 23:28 – Updated: 2025-12-20 02:30Summary
The io.netty.handler.codec.http.HttpRequestEncoder CRLF injection with the request uri when constructing a request. This leads to request smuggling when HttpRequestEncoder is used without proper sanitization of the uri.
Details
The HttpRequestEncoder simply UTF8 encodes the uri without sanitization (buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);)
The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers.
PoC
Simple reproducer:
public static void main(String[] args) {
EmbeddedChannel client = new EmbeddedChannel();
client.pipeline().addLast(new HttpClientCodec());
EmbeddedChannel server = new EmbeddedChannel();
server.pipeline().addLast(new HttpServerCodec());
server.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
System.out.println("Processing msg " + msg);
}
});
DefaultHttpRequest request = new DefaultHttpRequest(
HttpVersion.HTTP_1_1,
HttpMethod.GET,
"/s1 HTTP/1.1\r\n" +
"\r\n" +
"POST /s2 HTTP/1.1\r\n" +
"content-length: 11\r\n\r\n" +
"Hello World" +
"GET /s1"
);
client.writeAndFlush(request);
ByteBuf tmp;
while ((tmp = client.readOutbound()) != null) {
server.writeInbound(tmp);
}
}
Impact
Any application / framework using HttpRequestEncoder can be subject to be abused to perform request smuggling using CRLF injection.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.8.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.129.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67735"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-15T23:28:49Z",
"nvd_published_at": "2025-12-16T01:15:52Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri.\n\n### Details\n\nThe `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`)\n\nThe default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers.\n\n### PoC\n\nSimple reproducer:\n\n```java\npublic static void main(String[] args) {\n\n EmbeddedChannel client = new EmbeddedChannel();\n client.pipeline().addLast(new HttpClientCodec());\n\n EmbeddedChannel server = new EmbeddedChannel();\n server.pipeline().addLast(new HttpServerCodec());\n server.pipeline().addLast(new ChannelInboundHandlerAdapter() {\n @Override\n public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {\n System.out.println(\"Processing msg \" + msg);\n }\n });\n\n DefaultHttpRequest request = new DefaultHttpRequest(\n HttpVersion.HTTP_1_1,\n HttpMethod.GET,\n \"/s1 HTTP/1.1\\r\\n\" +\n \"\\r\\n\" +\n \"POST /s2 HTTP/1.1\\r\\n\" +\n \"content-length: 11\\r\\n\\r\\n\" +\n \"Hello World\" +\n \"GET /s1\"\n );\n client.writeAndFlush(request);\n ByteBuf tmp;\n while ((tmp = client.readOutbound()) != null) {\n server.writeInbound(tmp);\n }\n}\n```\n\n### Impact\n\nAny application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection.",
"id": "GHSA-84h7-rjj3-6jx4",
"modified": "2025-12-20T02:30:14Z",
"published": "2025-12-15T23:28:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67735"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/77e81f1e5944d98b3acf887d3aa443b252752e94"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"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": "Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder"
}
GHSA-CFXW-4H78-H7FW
Vulnerability from github – Published: 2024-07-22 14:33 – Updated: 2024-09-04 14:24Summary
Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones.
Details
DNS Messages are not authenticated. They do not guarantee that
- received RRs are authentic
- not received RRs do not exist
- all or any received records in a response relate to the request
Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!)
- denote by
QNAMEthe name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases - if the ANSWER section contains a valid PTR RRSet for
QNAME, return it (and optionally return the list of aliases as well) - if the ANSWER section contains a valid CNAME RRSet for
QNAME, add it to the list of aliases. SetQNAMEto the CNAME's target and go to 2. - Verify that
QNAMEdoes not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Returnnull.
Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic.
dnsjava does not implement a comparable algorithm, and the provided APIs instead return either
- the received DNS message itself (e.g. when using a ValidatingResolver such as in this example), or
- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in this example)
If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can
- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or
- completely exchange the relevant response records
Impact
DNS(SEC) libraries are usually used as part of a larger security framework. Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. Here are three concrete examples of where this might be detrimental:
- RFC 6186 specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials.
- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic.
- Some research projects like LIGHTest are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications.
Mitigations
At this point, the following mitigations are recommended:
- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...).
- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g.
LookupSession.lookupAsync. - Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "dnsjava:dnsjava"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25638"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-22T14:33:41Z",
"nvd_published_at": "2024-07-22T14:15:04Z",
"severity": "HIGH"
},
"details": "### Summary\n\nRecords in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones.\n\n### Details\n\nDNS Messages are not authenticated. They do not guarantee that\n\n- received RRs are authentic\n- not received RRs do not exist\n- all or any received records in a response relate to the request\n\nApplications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two.\nTo meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!)\n\n1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases\n2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well)\n3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME\u0027s target and go to 2.\n4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`.\n\nNote that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic.\n\ndnsjava does not implement a comparable algorithm, and the provided APIs instead return either\n\n- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or\n- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example)\n\nIf applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can\n\n- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or\n- completely exchange the relevant response records\n\n### Impact\n\nDNS(SEC) libraries are usually used as part of a larger security framework.\nTherefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request.\nHere are three concrete examples of where this might be detrimental:\n\n- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user\u0027s credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials.\n- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic.\n- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications.\n\n### Mitigations\n\nAt this point, the following mitigations are recommended:\n\n- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...).\n- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`.\n- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above.",
"id": "GHSA-cfxw-4h78-h7fw",
"modified": "2024-09-04T14:24:15Z",
"published": "2024-07-22T14:33:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dnsjava/dnsjava/security/advisories/GHSA-cfxw-4h78-h7fw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25638"
},
{
"type": "WEB",
"url": "https://github.com/dnsjava/dnsjava/commit/2073a0cdea2c560465f7ac0cc56f202e6fc39705"
},
{
"type": "PACKAGE",
"url": "https://github.com/dnsjava/dnsjava"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L",
"type": "CVSS_V4"
}
],
"summary": "DNSJava DNSSEC Bypass"
}
GHSA-FGHV-69VJ-QJ49
Vulnerability from github – Published: 2025-09-04 17:35 – Updated: 2025-09-10 20:48Summary
A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.
Details
When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the RFC).
This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):
POST /one HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0
POST /two HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
0
The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see this Portswigger article).
Impact
This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.
The impact is high, but it only affects setups that use a front-end which: 1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. 2. Forwards chunk extensions without normalization.
Disclosure
- This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html
Discussion
Discussion for this vulnerability can be found here: - https://github.com/netty/netty/issues/15522 - https://github.com/JLLeitschuh/unCVEed/issues/1
Credit
- Credit to @JeppW for uncovering this vulnerability.
- Credit to @JLLeitschuh at Socket for coordinating the vulnerability disclosure.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.125.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.5.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58056"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-04T17:35:20Z",
"nvd_published_at": "2025-09-03T21:15:33Z",
"severity": "LOW"
},
"details": "## Summary\nA flaw in netty\u0027s parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.\n\n## Details\nWhen encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)).\n\nThis is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):\n\n```\nPOST /one HTTP/1.1\nHost: localhost:8080\nTransfer-Encoding: chunked\n\n48;\\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\\n0\n\nPOST /two HTTP/1.1\nHost: localhost:8080\nTransfer-Encoding: chunked\n\n0\n\n```\n\nThe intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)).\n\n## Impact\nThis is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.\n\nThe impact is high, but it only affects setups that use a front-end which:\n1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension.\n2. Forwards chunk extensions without normalization.\n\n## Disclosure\n\n - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html\n\n## Discussion\nDiscussion for this vulnerability can be found here:\n - https://github.com/netty/netty/issues/15522\n - https://github.com/JLLeitschuh/unCVEed/issues/1\n\n## Credit\n\n - Credit to @JeppW for uncovering this vulnerability.\n - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure.",
"id": "GHSA-fghv-69vj-qj49",
"modified": "2025-09-10T20:48:05Z",
"published": "2025-09-04T17:35:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-fghv-69vj-qj49"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58056"
},
{
"type": "WEB",
"url": "https://github.com/JLLeitschuh/unCVEed/issues/1"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/issues/15522"
},
{
"type": "WEB",
"url": "https://github.com/github/advisory-database/pull/6092"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/pull/15611"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/edb55fd8e0a3bcbd85881e423464f585183d1284"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://w4ke.info/2025/06/18/funky-chunks.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions"
}
GHSA-FJPJ-2G6W-X25R
Vulnerability from github – Published: 2023-06-15 16:28 – Updated: 2023-06-27 21:57Summary
Due to unchecked multiplications, an integer overflow may occur, causing an unrecoverable fatal error.
Impact
Denial of Service
Description
The function compress(char[] input) in the file Snappy.java receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the rawCompress function.
public static byte[] compress(char[] input)
throws IOException
{
return rawCompress(input, input.length * 2); // char uses 2 bytes
}
Since the length is not tested, the multiplication by two can cause an integer overflow and become negative. The rawCompress function then uses the received length and passes it to the natively compiled maxCompressedLength function, using the returned value to allocate a byte array.
public static byte[] rawCompress(Object data, int byteSize)
throws IOException
{
byte[] buf = new byte[Snappy.maxCompressedLength(byteSize)];
int compressedByteSize = impl.rawCompress(data, 0, byteSize, buf, 0);
byte[] result = new byte[compressedByteSize];
System.arraycopy(buf, 0, result, 0, compressedByteSize);
return result;
}
Since the maxCompressedLength function treats the length as an unsigned integer, it doesn’t care that it is negative, and it returns a valid value, which is casted to a signed integer by the Java engine. If the result is negative, a “java.lang.NegativeArraySizeException” exception will be raised while trying to allocate the array “buf”. On the other side, if the result is positive, the “buf” array will successfully be allocated, but its size might be too small to use for the compression, causing a fatal Access Violation error. The same issue exists also when using the “compress” functions that receive double, float, int, long and short, each using a different multiplier that may cause the same issue. The issue most likely won’t occur when using a byte array, since creating a byte array of size 0x80000000 (or any other negative value) is impossible in the first place.
Steps To Reproduce
Compile and run the following code:
package org.example;
import org.xerial.snappy.Snappy;
import java.io.*;
public class Main {
public static void main(String[] args) throws IOException {
char[] uncompressed = new char[0x40000000];
byte[] compressed = Snappy.compress(uncompressed);
}
}
The program will crash, creating crashdumps and showing the following error (or similar):
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000063a01c20, pid=21164, tid=508
#
.......
Alternatively - compile and run the following code:
package org.example;
import org.xerial.snappy.Snappy;
import java.io.*;
public class Main {
public static void main(String[] args) throws IOException {
char[] uncompressed = new char[0x3fffffff];
byte[] compressed = Snappy.compress(uncompressed);
}
}
The program will crash with the following error (or similar), since the maxCompressedLength returns a value that is interpreted as negative by java:
Exception in thread "main" java.lang.NegativeArraySizeException: -1789569677
at org.xerial.snappy.Snappy.rawCompress(Snappy.java:425)
at org.xerial.snappy.Snappy.compress(Snappy.java:172)
at org.example.Main.main(Main.java:10)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.10.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.xerial.snappy:snappy-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34454"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-15T16:28:08Z",
"nvd_published_at": "2023-06-15T17:15:09Z",
"severity": "MODERATE"
},
"details": "## Summary\nDue to unchecked multiplications, an integer overflow may occur, causing an unrecoverable fatal error.\n## Impact\nDenial of Service\n## Description\nThe function [compress(char[] input)](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L169) in the file [Snappy.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/Snappy.java) receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the [rawCompress](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L422) function.\n\n```java\npublic static byte[] compress(char[] input)\n throws IOException\n {\n return rawCompress(input, input.length * 2); // char uses 2 bytes\n }\n\n```\n\nSince the length is not tested, the multiplication by two can cause an integer overflow and become negative. The rawCompress function then uses the received length and passes it to the natively compiled maxCompressedLength function, using the returned value to allocate a byte array.\n\n```java\n public static byte[] rawCompress(Object data, int byteSize)\n throws IOException\n {\n byte[] buf = new byte[Snappy.maxCompressedLength(byteSize)];\n int compressedByteSize = impl.rawCompress(data, 0, byteSize, buf, 0);\n byte[] result = new byte[compressedByteSize];\n System.arraycopy(buf, 0, result, 0, compressedByteSize);\n return result;\n }\n\n```\n\nSince the maxCompressedLength function treats the length as an unsigned integer, it doesn\u2019t care that it is negative, and it returns a valid value, which is casted to a signed integer by the Java engine. If the result is negative, a \u201cjava.lang.NegativeArraySizeException\u201d exception will be raised while trying to allocate the array \u201cbuf\u201d. On the other side, if the result is positive, the \u201cbuf\u201d array will successfully be allocated, but its size might be too small to use for the compression, causing a fatal Access Violation error.\nThe same issue exists also when using the \u201ccompress\u201d functions that receive double, float, int, long and short, each using a different multiplier that may cause the same issue. The issue most likely won\u2019t occur when using a byte array, since creating a byte array of size 0x80000000 (or any other negative value) is impossible in the first place.\n\n\n## Steps To Reproduce\nCompile and run the following code:\n\n```java\npackage org.example;\nimport org.xerial.snappy.Snappy;\n\nimport java.io.*;\n\npublic class Main {\n\n public static void main(String[] args) throws IOException {\n char[] uncompressed = new char[0x40000000];\n byte[] compressed = Snappy.compress(uncompressed);\n }\n}\n\n```\n\nThe program will crash, creating crashdumps and showing the following error (or similar):\n\n```\n#\n# A fatal error has been detected by the Java Runtime Environment:\n#\n# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000063a01c20, pid=21164, tid=508\n#\n.......\n```\n\n\nAlternatively - compile and run the following code:\n\n```java\npackage org.example;\nimport org.xerial.snappy.Snappy;\n\nimport java.io.*;\n\npublic class Main {\n\n public static void main(String[] args) throws IOException {\n char[] uncompressed = new char[0x3fffffff];\n byte[] compressed = Snappy.compress(uncompressed);\n }\n}\n```\n\nThe program will crash with the following error (or similar), since the maxCompressedLength returns a value that is interpreted as negative by java:\n\n```\nException in thread \"main\" java.lang.NegativeArraySizeException: -1789569677\n\tat org.xerial.snappy.Snappy.rawCompress(Snappy.java:425)\n\tat org.xerial.snappy.Snappy.compress(Snappy.java:172)\n\tat org.example.Main.main(Main.java:10)\n\n```",
"id": "GHSA-fjpj-2g6w-x25r",
"modified": "2023-06-27T21:57:13Z",
"published": "2023-06-15T16:28:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/security/advisories/GHSA-fjpj-2g6w-x25r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34454"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/commit/d0042551e4a3509a725038eb9b2ad1f683674d94"
},
{
"type": "PACKAGE",
"url": "https://github.com/xerial/snappy-java"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L169"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L422"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/Snappy.java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "snappy-java\u0027s Integer Overflow vulnerability in compress leads to DoS"
}
GHSA-FX2C-96VJ-985V
Vulnerability from github – Published: 2022-12-12 21:24 – Updated: 2023-01-13 17:18Impact
A StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion.
Patches
Users should upgrade to 4.1.86.Final.
Workarounds
There is no workaround, except using a custom HaProxyMessageDecoder.
References
When parsing a TLV with type = PP2_TYPE_SSL, the value can be again a TLV with type = PP2_TYPE_SSL and so on. The only limitation of the recursion is that the TLV length cannot be bigger than 0xffff because it is encoded in an unsigned short type. Providing a TLV with a nesting level that is large enough will lead to raising of a StackOverflowError. The StackOverflowError will be caught if HAProxyMessageDecoder is used as part of Netty’s ChannelPipeline, but using it directly without the ChannelPipeline will lead to a thrown exception / crash.
For more information
If you have any questions or comments about this advisory: * Open an issue in netty
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-haproxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.86.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-41881"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-12T21:24:29Z",
"nvd_published_at": "2022-12-12T18:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nA StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion.\n\n### Patches\nUsers should upgrade to 4.1.86.Final.\n\n### Workarounds\nThere is no workaround, except using a custom HaProxyMessageDecoder.\n\n### References\nWhen parsing a TLV with type = PP2_TYPE_SSL, the value can be again a TLV with type = PP2_TYPE_SSL and so on.\nThe only limitation of the recursion is that the TLV length cannot be bigger than 0xffff because it is encoded in an unsigned short type.\nProviding a TLV with a nesting level that is large enough will lead to raising of a StackOverflowError.\nThe StackOverflowError will be caught if HAProxyMessageDecoder is used as part of Netty\u2019s ChannelPipeline, but using it directly without the ChannelPipeline will lead to a thrown exception / crash.\n\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [netty](https://github.com/netty/netty)\n",
"id": "GHSA-fx2c-96vj-985v",
"modified": "2023-01-13T17:18:24Z",
"published": "2022-12-12T21:24:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-fx2c-96vj-985v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41881"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00008.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230113-0004"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5316"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "HAProxyMessageDecoder Stack Exhaustion DoS"
}
GHSA-G5WW-5JH7-63CX
Vulnerability from github – Published: 2022-12-12 15:30 – Updated: 2025-09-02 19:35A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.16.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.17.0"
},
{
"fixed": "3.19.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.20.0"
},
{
"fixed": "3.20.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0"
},
{
"fixed": "3.21.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.20.0"
},
{
"fixed": "3.20.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0"
},
{
"fixed": "3.21.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.16.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3509"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-12T22:33:53Z",
"nvd_published_at": "2022-12-12T13:15:00Z",
"severity": "HIGH"
},
"details": "A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.",
"id": "GHSA-g5ww-5jh7-63cx",
"modified": "2025-09-02T19:35:38Z",
"published": "2022-12-12T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3509"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/a3888f53317a8018e7a439bac4abeb8f3425d5e9"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/blob/v2.6.1/java/core/src/main/java/com/google/protobuf/MessageReflection.java"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/blob/v3.0.0/java/core/src/main/java/com/google/protobuf/MessageReflection.java"
},
{
"type": "PACKAGE",
"url": "https://github.com/protocolbuffers/protobuf/tree/main/java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Protobuf Java vulnerable to Uncontrolled Resource Consumption"
}
GHSA-G8M5-722R-8WHQ
Vulnerability from github – Published: 2024-10-14 21:08 – Updated: 2025-11-03 22:49Impact
Remote DOS attack can cause out of memory
Description
There exists a security vulnerability in Jetty's ThreadLimitHandler.getRemote() which
can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By
repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the
server's memory.
Affected Versions
- Jetty 12.0.0-12.0.8 (Supported)
- Jetty 11.0.0-11.0.23 (EOL)
- Jetty 10.0.0-10.0.23 (EOL)
- Jetty 9.3.12-9.4.55 (EOL)
Patched Versions
- Jetty 12.0.9
- Jetty 11.0.24
- Jetty 10.0.24
- Jetty 9.4.56
Workarounds
Do not use ThreadLimitHandler.
Consider use of QoSHandler instead to artificially limit resource utilization.
References
Jetty 12 - https://github.com/jetty/jetty.project/pull/11723
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.8"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.23"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.23"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.0.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.4.55"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.3.12"
},
{
"fixed": "9.4.56"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-8184"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-14T21:08:38Z",
"nvd_published_at": "2024-10-14T16:15:04Z",
"severity": "MODERATE"
},
"details": "### Impact\nRemote DOS attack can cause out of memory \n\n### Description\nThere exists a security vulnerability in Jetty\u0027s `ThreadLimitHandler.getRemote()` which\ncan be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By\nrepeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the\nserver\u0027s memory.\n\n### Affected Versions\n\n* Jetty 12.0.0-12.0.8 (Supported)\n* Jetty 11.0.0-11.0.23 (EOL)\n* Jetty 10.0.0-10.0.23 (EOL)\n* Jetty 9.3.12-9.4.55 (EOL)\n\n### Patched Versions\n\n* Jetty 12.0.9\n* Jetty 11.0.24\n* Jetty 10.0.24\n* Jetty 9.4.56\n\n### Workarounds\n\nDo not use `ThreadLimitHandler`. \nConsider use of `QoSHandler` instead to artificially limit resource utilization.\n\n### References\n\nJetty 12 - https://github.com/jetty/jetty.project/pull/11723",
"id": "GHSA-g8m5-722r-8whq",
"modified": "2025-11-03T22:49:11Z",
"published": "2024-10-14T21:08:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-g8m5-722r-8whq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8184"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/11723"
},
{
"type": "PACKAGE",
"url": "https://github.com/jetty/jetty.project"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignement/-/issues/30"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Eclipse Jetty\u0027s ThreadLimitHandler.getRemote() vulnerable to remote DoS attacks"
}
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.