Skip to content

← Public intelligence

Maven package

org.typelevel:jawn-parser_3

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

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

  1. High, CVSS 7.5MavenAmendedPublished

    Jawn: Quadratic parsing effort in AsyncParser

    CVE-2026-61814 · GHSA-w4cm-gvhj-cgw6

    Affected
    • Maven org.typelevel:jawn-parser_3 <= 1.6.0
    Fixed in
    1.7.0· Vendor fix available
    Issue
    AsyncParser can be forced to perform O(n^2) work on the length of the input. When a single JSON token arrives across many small chunks, each absorb call rescans the incomplete token from the start. Impact Denial of service via CPU exhaustion when parsing untrusted JSON. Preconditions: - Application uses AsyncParser - Attacker can send large tokens with control over chunk sizes. Patches Fixed in jawn-parser-1.7.0. Workarounds If you can't upgrade immediately: - Use the synchronous Parser. - Buffer incoming bytes into larger chunks before calling absorb

    Recommended action: Upgrade to 1.7.0 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. High, CVSS 7.5MavenAmendedPublished

    Jawn: Uncontrolled nesting depth in JSON parser

    CVE-2026-59990 · GHSA-cc4v-rvgp-2pf3

    Affected
    • Maven org.typelevel:jawn-parser_3 <= 1.6.0
    Fixed in
    1.7.0· Vendor fix available
    Issue
    The Jawn parser before 1.6.1 is vulnerable to a denial of service attack via untrusted input. Impact A remote attacker who can submit JSON to any jawn-backed parse method can exhaust JVM heap and trigger java.lang.OutOfMemoryError. This is treated by Scala as a fatal error and not typically handled by scala.util.Try or cats.effect.IO. Patches Version 1.6.1 introduces a configurable nesting-depth limit (Parser#maxDepth, default 4096). Inputs deeper than the limit fail with a recoverable ParseException instead of exhausting heap. Users who require deeper nesting may override maxDepth on a Parser subclass. Workarounds - Enforce an input size limit small enough that the resulting context stack cannot exhaust heap, (e.g. http4s EntityLimiter). - Pre-scan untrusted input and reject documents whose maximum delimiter nesting exceeds a threshold before handing them to jawn.

    Recommended action: Upgrade to 1.7.0 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 →