Where
AND
-Infinity
0
Severity
9.1
AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

A flaw was found in Undertow. When Undertow receives an HTTP request where the first header line starts with one or more spaces, it incorrectly processes the request by stripping these leading spaces. This behavior, which violates HTTP standards, can be exploited by a remote attacker to perform request smuggling. Request smuggling allows an attacker to bypass security mechanisms, access restricted information, or manipulate web caches, potentially leading to unauthorized actions or data exposure.

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

A flaw was found in Undertow. This vulnerability allows a remote attacker to construct specially crafted requests where header names are parsed differently by Undertow compared to upstream proxies. This discrepancy in header interpretation can be exploited to launch request smuggling attacks, potentially bypassing security controls and accessing unauthorized resources.

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

A flaw was found in Undertow. A remote attacker can exploit this vulnerability by sending \r\r\r as a header block terminator. This can be used for request smuggling with certain proxy servers, such as older versions of Apache Traffic Server and Google Cloud Classic Application Load Balancer, potentially leading to unauthorized access or manipulation of web requests.

1 / 2
Source: MITRE
First published (updated )
Severity
9.6
Input Validation, SSRF
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L

A flaw was found in the Undertow HTTP server core, which is used in WildFly, JBoss EAP, and other Java applications. The Undertow library fails to properly validate the Host header in incoming HTTP requests. As a result, requests containing malformed or malicious Host headers are processed without rejection, enabling attackers to poison caches, perform internal network scans, or hijack user sessions.

1 / 4
Source: GitHub
First published (updated )
Severity
9.8
Code Injection, Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Pivotal Spring Framework could allow a remote attacker to execute arbitrary code on the system, caused by the exposure of STOMP over WebSocket endpoints with a STOMP broker through the spring-messaging module. By sending a specially-crafted message, an attacker could exploit this vulnerability to execute arbitrary code on the system.

1 / 4
Source: IBM
First published (updated )
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

1 / 3
First published (updated )
Severity
9.8
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Apache Shiro before 1.2.5, when a cipher key has not been configured for the "remember me" feature, allows remote attackers to execute arbitrary code or bypass intended access restrictions via an unspecified request parameter.

1 / 3
First published (updated )
Severity
9.8
AV:N/AC:L/Au:N/C:P/I:P/A:P

It was reported that Elasticsearch versions 1.3.0-1.3.7 and 1.4.0-1.4.2 have vulnerabilities in the Groovy scripting engine. The vulnerability allows an attacker to construct Groovy scripts that escape the sandbox and execute shell commands as the user running the Elasticsearch Java VM.

Upstream bug report: https://github.com/elasticsearch/elasticsearch/issues/9655

Upstream fixes: 1.3: https://github.com/elasticsearch/elasticsearch/commit/69735b0f4ab9ad7df4b82e8c917589b52cb9978c 1.4: https://github.com/elasticsearch/elasticsearch/commit/4e952b2d75de6ca4caf4b6743462714f3b60d07f 1.x: https://github.com/elasticsearch/elasticsearch/commit/716f0b24dc5414616e8dc0590dbfcfa0081be892

Mitigation: Users can address the vulnerability by setting script.groovy.sandbox.enabled to false in config/elasticsearch.yml and restarting the node.

1 / 3
Source: Red Hat
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