Where
AND
-Infinity
0
First published (updated )
Advisory
IBM-7283486
Severity
7.1
CSRF
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

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.

1 / 2
Source: MITRE
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Impact

The DelegatingDecompressorFrameListener class orchestrates HTTP/2 decompression by embedding a per-stream EmbeddedChannel that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled ByteBuf handed to an anonymous ChannelInboundHandlerAdapter tail handler, which becomes the sole owner responsible for releasing it.

A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME.

1 / 2
Source: GitHub
First published (updated )
Severity
5.3
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Impact DefaultHttp2Connection.DefaultEndpoint initialises maxActiveStreams/maxStreams to Integer.MAXVALUE, and Http2Settings never inserts SETTINGSMAXCONCURRENTSTREAMS by default (Http2Settings.java:305-307 only clamps a user-supplied value). Unless the application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server advertises no limit and enforces none locally. Each open stream allocates a DefaultStream object, PropertyMap slots, flow-controller state and IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP connection can create hundreds of thousands of long-lived stream objects. This is also the precondition for CVE-2023-44487-style Rapid-Reset amplification, where the absence of a low concurrent cap multiplies backend work.

Resources https://www.rfc-editor.org/rfc/rfc7540.html#section-6.5.2

1 / 2
Source: GitHub
First published (updated )
Severity
5.3
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Summary

Before reading the first request-line, HttpObjectDecoder skips every byte for which Character.isISOControl(b) is true (0x00–0x1F and 0x7F) as well as all whitespace. RFC 9112 §2.2 only asks servers to ignore empty CRLF lines preceding the request-line — a carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds. Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes significantly beyond this, and can be exploited for request-boundary confusion in pipelined or multiplexed transports where a front-end component treats those bytes differently.

Affected Code

| File | Lines | Role | |------|-------|------| | codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java | 1298–1313 | ISOCONTROLORWHITESPACE static initialiser — marks all ISO control chars | | codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java | 1307–1313 | SKIPCONTROLCHARSBYTES ByteProcessor — skips the entire set | | codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java | 1275–1289 | LineParser.skipControlChars — advances readerIndex past all matching bytes |

Specification Analysis

RFC 9112 §2.2 — Message Parsing

In the interest of robustness, a server that is expecting to receive and parse a request-line SHOULD ignore at least one empty line (CRLF) received prior to the request-line.

An HTTP/1.1 user agent MUST NOT preface or follow a request with an extra CRLF.

Deviation

The RFC names a single permitted exception: an empty line (bare CRLF, i.e. the two-byte sequence \r\n). The ISOCONTROLORWHITESPACE table is initialised as:

java for (byte b = Byte.MINVALUE; b < Byte.MAXVALUE; b++) { ISOCONTROLORWHITESPACE[128 + b] = Character.isISOControl(b) || isWhitespace(b); }

Character.isISOControl returns true for 0x00–0x1F and 0x7F. This includes NUL (0x00), SOH (0x01), STX (0x02), BEL (0x07), DEL (0x7F), and every other non-CRLF control character. The SKIPCONTROLCHARS state runs this scan unconditionally before the first READINITIAL, meaning any sequence of such bytes prepended to a request is silently consumed.

A load balancer or TLS terminator that does not perform the same scan sees a different message boundary than Netty does, which is the basis of a request-desync / smuggling attack.

Suggested Unit Test

Add to HttpRequestDecoderTest.java.

java @Test public void testNonCrlfControlBytesPrecedingRequestLineAreRejected() { // RFC 9112 §2.2: servers SHOULD ignore "at least one empty line (CRLF)" before the // request-line. Non-CRLF control bytes are not part of this robustness allowance // and must not be silently swallowed. EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());

ByteBuf buf = Unpooled.buffer(); buf.writeByte(0x00); // NUL — not an empty CRLF line buf.writeByte(0x01); // SOH — not an empty CRLF line buf.writeCharSequence( "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n", CharsetUtil.USASCII);

channel.writeInbound(buf); HttpRequest req = channel.readInbound();

// Current behaviour: NUL and SOH are in ISOCONTROLORWHITESPACE, so they are // silently skipped; the request decodes successfully and isFailure() == false. // // RFC-correct behaviour: only empty CRLF lines should be ignored; NUL/SOH must // cause a parse error — isFailure() == true. assertTrue( req.decoderResult().isFailure(), "Non-CRLF control bytes before the request-line must not be silently skipped " + "(RFC 9112 §2.2 allows only empty CRLF lines)");

assertFalse(channel.finish()); }

Current behaviour (unfixed): skipControlChars advances past 0x00 and 0x01 because both are in ISOCONTROLORWHITESPACE; the request parses normally, isFailure() is false → test fails.

Expected behaviour after fix: only CRLF empty lines are tolerated; non-CRLF control bytes produce an error, isFailure() is true → test passes.

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

1 / 6
Source: NVD
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

1 / 3
Source: GitHub
First published (updated )
Severity
7.5
EPSS
0.04%
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

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

1 / 3
Source: Red Hat
First published (updated )
Severity
9.3
Infoleak
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

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.

1 / 5
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

1 / 5
First published (updated )
Severity
7.5
Null Pointer Dereference
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

1 / 5
Source: GitHub
First published (updated )
Severity
9.1
AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

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.

1 / 2
Source: IBM
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203