Critical
High
Medium
Low
Secrets
Misconfig
| Severity | CVE ID | Package | Installed | Fixed In | Description |
|---|---|---|---|---|---|
| MEDIUM | GHSA-72hv-8253-57qq | com.fasterxml.jackson.core:jackson-core | 2.18.0 | 2.21.1, 2.18.6 | jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition |
| MEDIUM | CVE-2025-7962 | com.sun.mail:jakarta.mail | 2.0.1 | 1.6.8, 2.0.2 | com.sun.mail/jakarta.mail: Jakarta Mail SMTP Injection Vulnerability |
| CRITICAL | CVE-2025-66516 | org.apache.tika:tika-core | 3.1.0 | 3.2.2 | tika-core: tika-parsers: tika-parser-pdf-module: Apache Tika core, Apache Tika parsers, Apache Tika |
| Type | File | Line | Match |
|---|---|---|---|
| ✅ No secrets found | |||
| Severity | ID | Check | File | Message |
|---|---|---|---|---|
| HIGH | DS002 | Image user should not be 'root' | Dockerfile | Specify at least 1 USER command in Dockerfile with non-root user as argument |
{
"SchemaVersion": 2,
"CreatedAt": "2026-06-24T07:41:31.158027394Z",
"ArtifactName": "/src",
"ArtifactType": "filesystem",
"Metadata": {
"ImageConfig": {
"architecture": "",
"created": "0001-01-01T00:00:00Z",
"os": "",
"rootfs": {
"type": "",
"diff_ids": null
},
"config": {}
}
},
"Results": [
{
"Target": "pom.xml",
"Class": "lang-pkgs",
"Type": "pom",
"Vulnerabilities": [
{
"VulnerabilityID": "GHSA-72hv-8253-57qq",
"PkgID": "com.fasterxml.jackson.core:jackson-core:2.18.0",
"PkgName": "com.fasterxml.jackson.core:jackson-core",
"PkgIdentifier": {
"PURL": "pkg:maven/com.fasterxml.jackson.core/jackson-core@2.18.0"
},
"InstalledVersion": "2.18.0",
"FixedVersion": "2.21.1, 2.18.6",
"Status": "fixed",
"Layer": {},
"SeveritySource": "ghsa",
"PrimaryURL": "https://github.com/advisories/GHSA-72hv-8253-57qq",
"DataSource": {
"ID": "ghsa",
"Name": "GitHub Security Advisory Maven",
"URL": "https://github.com/advisories?query=type%3Areviewed+ecosystem%3Amaven"
},
"Title": "jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition",
"Description": "### Summary\nThe 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).\n\nThe standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.\n\n### Details\nThe root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.\n\n- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.\n- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.\n- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.\n- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.\n\n### PoC\nThe 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.\n\n```java\npackage tools.jackson.core.unittest.dos;\n\nimport java.nio.charset.StandardCharsets;\n\nimport org.junit.jupiter.api.Test;\n\nimport tools.jackson.core.*;\nimport tools.jackson.core.exc.StreamConstraintsException;\nimport tools.jackson.core.json.JsonFactory;\nimport tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;\n\nimport static org.junit.jupiter.api.Assertions.*;\n\n/**\n * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers\n *\n * Authors: sprabhav7, rohan-repos\n * \n * maxNumberLength default = 1000 characters (digits).\n * A number with more than 1000 digits should be rejected by any parser.\n *\n * BUG: The async parser never calls resetInt()/resetFloat() which is where\n * validateIntegerLength()/validateFPLength() lives. Instead it calls\n * _valueComplete() which skips all number length validation.\n *\n * CWE-770: Allocation of Resources Without Limits or Throttling\n */\nclass AsyncParserNumberLengthBypassTest {\n\n private static final int MAX_NUMBER_LENGTH = 1000;\n private static final int TEST_NUMBER_LENGTH = 5000;\n\n private final JsonFactory factory = new JsonFactory();\n\n // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength\n @Test\n void syncParserRejectsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\t\t\n\t\t// Output to console\n System.out.println(\"[SYNC] Parsing \" + TEST_NUMBER_LENGTH + \"-digit number (limit: \" + MAX_NUMBER_LENGTH + \")\");\n try {\n try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n System.out.println(\"[SYNC] Accepted number with \" + p.getText().length() + \" digits \u2014 UNEXPECTED\");\n }\n }\n }\n fail(\"Sync parser must reject a \" + TEST_NUMBER_LENGTH + \"-digit number\");\n } catch (StreamConstraintsException e) {\n System.out.println(\"[SYNC] Rejected with StreamConstraintsException: \" + e.getMessage());\n }\n }\n\n // VULNERABILITY: Async parser accepts the SAME number that sync rejects\n @Test\n void asyncParserAcceptsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\n NonBlockingByteArrayJsonParser p =\n (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());\n p.feedInput(payload, 0, payload.length);\n p.endOfInput();\n\n boolean foundNumber = false;\n try {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n foundNumber = true;\n String numberText = p.getText();\n assertEquals(TEST_NUMBER_LENGTH, numberText.length(),\n \"Async parser silently accepted all \" + TEST_NUMBER_LENGTH + \" digits\");\n }\n }\n // Output to console\n System.out.println(\"[ASYNC INT] Accepted number with \" + TEST_NUMBER_LENGTH + \" digits \u2014 BUG CONFIRMED\");\n assertTrue(foundNumber, \"Parser should have produced a VALUE_NUMBER_INT token\");\n } catch (StreamConstraintsException e) {\n fail(\"Bug is fixed \u2014 async parser now correctly rejects long numbers: \" + e.getMessage());\n }\n p.close();\n }\n\n private byte[] buildPayloadWithLongInteger(int numDigits) {\n StringBuilder sb = new StringBuilder(numDigits + 10);\n sb.append(\"{\\\"v\\\":\");\n for (int i = 0; i < numDigits; i++) {\n sb.append((char) ('1' + (i % 9)));\n }\n sb.append('}');\n return sb.toString().getBytes(StandardCharsets.UTF_8);\n }\n}\n\n```\n\n\n### Impact\nA 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:\n1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.\n2. **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.\n\n### Suggested Remediation\n\nThe 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.\n\n**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)",
"Severity": "MEDIUM",
"VendorSeverity": {
"ghsa": 2
},
"CVSS": {
"ghsa": {}
},
"References": [
"https://github.com/FasterXML/jackson-core",
"https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf",
"https://github.com/FasterXML/jackson-core/pull/1555",
"https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
],
"PublishedDate": "2026-02-28T02:01:05Z",
"LastModifiedDate": "2026-04-07T16:30:17Z"
},
{
"VulnerabilityID": "CVE-2025-7962",
"PkgID": "com.sun.mail:jakarta.mail:2.0.1",
"PkgName": "com.sun.mail:jakarta.mail",
"PkgIdentifier": {
"PURL": "pkg:maven/com.sun.mail/jakarta.mail@2.0.1"
},
"InstalledVersion": "2.0.1",
"FixedVersion": "1.6.8, 2.0.2",
"Status": "fixed",
"Layer": {},
"SeveritySource": "ghsa",
"PrimaryURL": "https://avd.aquasec.com/nvd/cve-2025-7962",
"DataSource": {
"ID": "ghsa",
"Name": "GitHub Security Advisory Maven",
"URL": "https://github.com/advisories?query=type%3Areviewed+ecosystem%3Amaven"
},
"Title": "com.sun.mail/jakarta.mail: Jakarta Mail SMTP Injection Vulnerability",
"Description": "In Jakarta Mail versions prior to 2.0.2 it is possible to perform an SMTP Injection by utilizing the\u00a0\\r and \\n UTF-8 characters to separate different messages.",
"Severity": "MEDIUM",
"CweIDs": [
"CWE-147"
],
"VendorSeverity": {
"amazon": 3,
"ghsa": 2,
"nvd": 3,
"redhat": 2
},
"CVSS": {
"ghsa": {
"V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"V3Score": 7.5
},
"nvd": {
"V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"V3Score": 7.5
},
"redhat": {
"V3Vector": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
"V3Score": 5.3
}
},
"References": [
"http://www.openwall.com/lists/oss-security/2025/09/03/4",
"https://access.redhat.com/security/cve/CVE-2025-7962",
"https://github.com/eclipse-ee4j/angus-mail",
"https://github.com/eclipse-ee4j/angus-mail/commit/269099b652a0a5c2fa140f1296a18f0fbbea0d44",
"https://github.com/jakartaee/mail-api/issues/765",
"https://github.com/jakartaee/mail-api/pull/760",
"https://gitlab.eclipse.org/security/cve-assignement/-/issues/67",
"https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/290",
"https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/290#note_5320539",
"https://nvd.nist.gov/vuln/detail/CVE-2025-7962",
"https://www.cve.org/CVERecord?id=CVE-2025-7962"
],
"PublishedDate": "2025-07-21T18:15:28.82Z",
"LastModifiedDate": "2026-06-23T12:16:24.73Z"
},
{
"VulnerabilityID": "CVE-2025-66516",
"PkgID": "org.apache.tika:tika-core:3.1.0",
"PkgName": "org.apache.tika:tika-core",
"PkgIdentifier": {
"PURL": "pkg:maven/org.apache.tika/tika-core@3.1.0"
},
"InstalledVersion": "3.1.0",
"FixedVersion": "3.2.2",
"Status": "fixed",
"Layer": {},
"SeveritySource": "ghsa",
"PrimaryURL": "https://avd.aquasec.com/nvd/cve-2025-66516",
"DataSource": {
"ID": "ghsa",
"Name": "GitHub Security Advisory Maven",
"URL": "https://github.com/advisories?query=type%3Areviewed+ecosystem%3Amaven"
},
"Title": "tika-core: tika-parsers: tika-parser-pdf-module: Apache Tika core, Apache Tika parsers, Apache Tika PDF parser module: Update to CVE-2025-54988 to expand scope of artifacts affected",
"Description": "Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. \n\nThis CVE covers the same vulnerability as in\u00a0CVE-2025-54988. However, this CVE expands the scope of affected packages in two ways. \n\nFirst, while the entrypoint for the vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2 would still be vulnerable. \n\nSecond, the original report failed to mention that in the 1.x Tika releases, the PDFParser was in the \"org.apache.tika:tika-parsers\" module.",
"Severity": "CRITICAL",
"CweIDs": [
"CWE-611"
],
"VendorSeverity": {
"ghsa": 4,
"nvd": 4,
"redhat": 4,
"ubuntu": 2
},
"CVSS": {
"ghsa": {},
"nvd": {
"V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"V3Score": 9.8
},
"redhat": {
"V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"V3Score": 10
}
},
"References": [
"https://access.redhat.com/security/cve/CVE-2025-66516",
"https://cve.org/CVERecord?id=CVE-2025-54988",
"https://github.com/apache/tika",
"https://lists.apache.org/thread/s5x3k93nhbkqzztp1olxotoyjpdlps9k",
"https://nvd.nist.gov/vuln/detail/CVE-2025-66516",
"https://ubuntu.com/security/notices/USN-8324-1",
"https://www.cve.org/CVERecord?id=CVE-2025-66516"
],
"PublishedDate": "2025-12-04T17:15:57.12Z",
"LastModifiedDate": "2026-06-17T09:56:58.233Z"
}
]
},
{
"Target": "Dockerfile",
"Class": "config",
"Type": "dockerfile",
"MisconfSummary": {
"Successes": 23,
"Failures": 1,
"Exceptions": 0
},
"Misconfigurations": [
{
"Type": "Dockerfile Security Check",
"ID": "DS002",
"AVDID": "AVD-DS-0002",
"Title": "Image user should not be 'root'",
"Description": "Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.",
"Message": "Specify at least 1 USER command in Dockerfile with non-root user as argument",
"Namespace": "builtin.dockerfile.DS002",
"Query": "data.builtin.dockerfile.DS002.deny",
"Resolution": "Add 'USER <non root user name>' line to the Dockerfile",
"Severity": "HIGH",
"PrimaryURL": "https://avd.aquasec.com/misconfig/ds002",
"References": [
"https://docs.docker.com/develop/develop-images/dockerfile_best-practices/",
"https://avd.aquasec.com/misconfig/ds002"
],
"Status": "FAIL",
"Layer": {},
"CauseMetadata": {
"Provider": "Dockerfile",
"Service": "general",
"Code": {
"Lines": null
}
}
}
]
}
]
}