Skip to content

← Public intelligence

PyPI package

xgrammar

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.7PyPIAmendedPublished

    xgrammar vulnerable to DoS via multi-layer nesting

    CVE-2026-25048 · GHSA-7rgv-gqhr-fxg3

    Affected
    • PyPI xgrammar <= 0.1.31
    Fixed in
    0.1.32· Vendor fix available
    Issue
    The multi-level nested syntax caused a segmentation fault (core dump). Details A trigger stack overflow or memory exhaustion was caused by constructing a malicious grammar rule containing 30,000 layers of nested parentheses. PoC Impact DoS

    Recommended action: Upgrade to 0.1.32 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. Medium, CVSS 6.9PyPIAmendedPublished

    xgrammar vulnerable to denial of service by huge enum grammar

    CVE-2025-58446 · GHSA-9q5r-wfvf-rr7f

    Affected
    • PyPI xgrammar >= 0.1.23, <= 0.1.23
    Fixed in
    0.1.24· Vendor fix available
    Issue
    Provided grammar, would fit in a context window of most of the models, but takes minutes to process in 0.1.23. In testing with 0.1.16 the parser worked fine so this seems to be a regression caused by Earley parser. Details Full reproducer provider in the POC section. The resulting grammar is around 70k tokens, and the grammar parsing itself (with the models I checked) was significantly longer than LLM processing itself, meaning this can be used to DOS model providers. Patch This problem is caused by the grammar optimizer introduced in v0.1.23 being too slow. It only happens for very large grammars (100k characters), like the below one. v0.1.24 solved this problem by optimizing the speed of the grammar optimizer and disable some slow optimization for large grammars. Thanks to @Seven-Streams PoC where: Impact DOS

    Recommended action: Upgrade to 0.1.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  3. High, CVSS 7.7PyPIAmendedPublished

    XGrammar affected by Denial of Service by infinite recursion grammars

    CVE-2025-57809 · GHSA-5cmr-4px5-23pc

    Affected
    • PyPI xgrammar < 0.1.21
    Fixed in
    0.1.21· Vendor fix available
    Issue
    This issue: http://github.com/mlc-ai/xgrammar/issues/250 should have it's own security advisory. Since several tools accept and pass user supplied grammars to xgrammar, and it is so easy to trigger it seems like a High.

    Recommended action: Upgrade to 0.1.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  4. Medium, CVSS 6.5PyPIAmendedPublished

    xgrammar Vulnerable to Denial of Service (DoS) by abusing unbounded cache in memory

    CVE-2025-32381 · GHSA-389x-67px-mjg3

    Affected
    • PyPI xgrammar < 0.1.18
    Fixed in
    0.1.18· Vendor fix available
    Issue
    Xgrammar includes a cache for compiled grammars to increase performance with repeated use of the same grammar. This cache is held in memory. Since the cache is unbounded, a system making use of xgrammar can be abused to fill up a host's memory and case a denial of service. For example, sending many small requests to an LLM inference server with unique JSON schemas would eventually cause this denial of service to occur. Details The fix is to add a limit to the cache size. This was done in https://github.com/mlc-ai/xgrammar/pull/243 An example of making use of the new cache size limit can be found in vLLM here: https://github.com/vllm-project/vllm/pull/16283 Impact Any system making use of Xgrammar and taking requests as input from potentially untrusted parties would be vulnerable to this denial of service issue.

    Recommended action: Upgrade to 0.1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →