jrburke requirejs could allow a remote attacker to execute arbitrary code on the system, caused by a prototype pollution in the function config. By sending a specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code or cause a denial of service.

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.

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.

IBM Planning Analytics connects to a MongoDB server. MongoDB, a document-oriented database system, is listening on the remote port, and it is configured to allow connections without password authentication. A remote attacker can gain unauthorized access to the database.

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 Planning Analytics 2.0, and 2.1 could allow a remote attacker to gain unauthorized administrative access due to improper authentication.

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 WebSphere Application Server 9.0, and 8.5 is affected by a remote code execution vulnerability in the SOAP/JMX connector.

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.

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.

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.

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

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

ClassGraph before 4.8.112 was not resistant to XML eXternal Entity (XXE) attacks.

Summary A ReDOS that exists on currency.js was discovered by Gauss Security Labs R&D team.

Details https://github.com/NaturalIntelligence/fast-xml-parser/blob/v4.4.0/src/v5/valueParsers/currency.js#L10 contains a vulnerable regex

PoC pass the following string '\t'.repeat(13337) + '.'

Impact Denial of service during currency parsing in experimental version 5 of fast-xml-parser-library

https://gauss-security.com

url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.

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.

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 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 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.

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.

A flaw was found in the json-smart package in the JSONParserByteArray. This flaw allows an attacker to cause a denial of service.

Json-smart is a performance focused, JSON processor lib.

When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively.

It was discovered that the code does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause a stack exhaustion (stack overflow) and crash the software.

IBM Planning Analytics 2.0, and 2.1 Local is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.

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.

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