A weakness has been identified in antlr ANTLR4 up to 4

CVE-2026-13500 sits in tool/src/org/antlr/v4/codegen/model/OutputFile.java inside ANTLR4's Grammar Action Block Handler. ANTLR4 is a *parser generator* — a developer build-time tool that consumes .g4 grammar files and emits parser source code in Java/C#/Python/Go/etc. The flaw (CWE-74) lets a crafted action block inside a grammar inject arbitrary code into the generated output, which then compiles into whatever target the developer is building. Affected: all ANTLR4 releases through and including 4.13.2; the runtime libraries shipped to production are *not* the target — only the antlr4 tool jar / CLI used at build time.

Vendor severity of HIGH (7.3) with AV:N/PR:N/UI:N is *technically defensible* under literal CVSS rules (a grammar file can arrive over a network), but it badly misrepresents the real exposure. There is no listening service. No production host runs the ANTLR tool. The 'attack' requires a developer or CI pipeline to voluntarily feed an attacker-supplied grammar into antlr4 -Dlanguage=… Foo.g4 — which is functionally identical to running javac on attacker source. Treat this as LOW for the fleet; the only real action item is in your dev-tooling and CI policy.

Why this verdict

• Build-time only: OutputFile.java lives in the tool/ source tree — the ANTLR4 *generator*, not the antlr4-runtime shipped with applications. Your 10,000-host fleet does not run this component.
• Requires voluntary grammar ingestion: Exploit assumes the victim runs antlr4 evil.g4. Grammars are essentially source code; consuming an untrusted one is equivalent to git clone && make on a stranger's repo. The bug is downstream of an already-broken trust decision.
• Role multiplier (low-value role — developer workstation / CI runner): Chain succeeds, blast radius = one developer or one build job. No fleet pivot.
• Role multiplier (typical role — internal CI building first-party grammars): Chain *fails* — grammars are vendored, reviewed in PR, not attacker-supplied. Blast radius = zero.
• Role multiplier (high-value role — public grammar registry / SaaS that compiles user-submitted grammars): Chain succeeds, blast radius = single tenant container, contained by sandbox. Such services are <0.01% of ANTLR4 install base — does not raise the floor.
• EPSS 0.3% + no KEV + no in-the-wild reports confirm market consensus that this is not an active threat.
• CVSS AV:N/UI:N is artifact, not reality: The vector treats file delivery as network attack with no user action. CVSS 4.0 already corrects this to 6.9 MEDIUM; real-world severity is lower still.

Why not higher?

Not MEDIUM/HIGH because there is no production attack surface — the vulnerable code is a developer tool, and no canonical high-value-role deployment (IdP, hypervisor, EDR, CA, backup) uses ANTLR4 at runtime. The role multiplier analysis finds no role where chain success yields fleet, domain, or supply-chain impact at meaningful installed-base share.

Why not lower?

Not IGNORE because there *is* a non-trivial supply-chain edge case: organizations that build language servers, query engines, or parsers from third-party grammars (e.g., language plugins from public registries) do have a real exposure path. Worth documenting and a CI policy update, but not worth waking anyone up.

1. Inventory ANTLR4 tool usage in CI — Grep your build configs (pom.xml, build.gradle, package.json, setup.py, Bazel/Buck rules) for antlr4, antlr4-maven-plugin, antlr4ts-cli. You need to know *which* pipelines invoke the tool before you can scope risk. No mitigation SLA for LOW — fold into normal backlog hygiene.
2. Enforce that .g4 grammar files come only from trusted sources — Add a CI policy check that fails the build if a .g4 file is added or modified outside an allowlist of vendored upstream paths, without a human review label. Stops the only realistic exploitation path (untrusted grammar ingestion).
3. Include generated parser code in SAST scope — Most shops exclude generated code from Semgrep/CodeQL because of noise — for ANTLR-generated parsers, add a narrow ruleset that flags Runtime.exec, eval, os.system, exec.Command, dynamic loads. Catches injected payloads at build time.
4. Pin ANTLR4 tool version and track upstream — If vendor publishes a fix post-disclosure (currently non-responsive), pin to the patched version. Until then, pinning to a known build avoids accidentally pulling a Trojaned distribution.
5. Document risk acceptance for the LOW verdict — Compliance auditors will see vendor HIGH (7.3) and ask. Pre-empt with a one-paragraph rationale citing build-time scope and trust-boundary analysis.

Run on each CI build runner and developer workstation that may invoke ANTLR4. Invoke as ./check_antlr4.sh — no special privileges required (reads filesystem and queries package managers). Outputs VULNERABLE if ANTLR4 tool ≤ 4.13.2 is present, PATCHED if a fixed version is found, UNKNOWN if no ANTLR4 install detected.

#!/usr/bin/env bash
# noisgate verification: CVE-2026-13500 — ANTLR4 tool code injection via grammar action block
# Detects ANTLR4 *tool* (not runtime) at version <= 4.13.2 on this host.
set -u

FIXED_VERSION="" # vendor has not published a fix as of 2026-06-30; update when available
MAX_VULN="4.13.2"
FOUND=0
VULN=0

ver_le() {
  # returns 0 (true) if $1 <= $2 by version sort
  [ "$1" = "$2" ] && return 0
  printf '%s\n%s\n' "$1" "$2" | sort -V -C
}

check_jar() {
  local jar="$1"
  local v
  v=$(unzip -p "$jar" META-INF/MANIFEST.MF 2>/dev/null | awk -F': ' '/Implementation-Version/{gsub(/\r/,"");print $2;exit}')
  [ -z "$v" ] && v=$(echo "$jar" | grep -oE '[0-9]+\.[0-9]+(\.[0-9]+)?' | tail -1)
  if [ -n "$v" ]; then
    FOUND=1
    echo "[+] Found ANTLR4 tool: $jar (version $v)"
    if ver_le "$v" "$MAX_VULN"; then
      VULN=1
      echo "    -> VULNERABLE (<= $MAX_VULN)"
    fi
  fi
}

# 1. Common jar locations
for path in /usr/local/lib /usr/share/java /opt $HOME/.m2/repository/org/antlr $HOME/.gradle/caches; do
  [ -d "$path" ] || continue
  while IFS= read -r jar; do
    check_jar "$jar"
  done < <(find "$path" -type f \( -iname 'antlr-4*.jar' -o -iname 'antlr4-4*.jar' -o -iname 'antlr4-tool-*.jar' \) 2>/dev/null)
done

# 2. npm antlr4ts-cli / antlr4-tool
if command -v npm >/dev/null 2>&1; then
  for pkg in antlr4ts-cli antlr4-tool antlr4; do
    v=$(npm ls -g --depth=0 "$pkg" 2>/dev/null | grep -oE "$pkg@[0-9.]+" | cut -d@ -f2)
    if [ -n "$v" ]; then
      FOUND=1
      echo "[+] Found npm $pkg@$v"
      ver_le "$v" "$MAX_VULN" && { VULN=1; echo "    -> VULNERABLE"; }
    fi
  done
fi

# 3. pip antlr4-tools
if command -v pip >/dev/null 2>&1; then
  v=$(pip show antlr4-tools 2>/dev/null | awk '/^Version:/{print $2}')
  if [ -n "$v" ]; then
    FOUND=1
    echo "[+] Found pip antlr4-tools $v"
    ver_le "$v" "$MAX_VULN" && { VULN=1; echo "    -> VULNERABLE"; }
  fi
fi

# 4. antlr4 on PATH
if command -v antlr4 >/dev/null 2>&1; then
  v=$(antlr4 2>&1 | grep -oE 'Version [0-9.]+' | awk '{print $2}')
  if [ -n "$v" ]; then
    FOUND=1
    echo "[+] Found antlr4 on PATH: $v"
    ver_le "$v" "$MAX_VULN" && { VULN=1; echo "    -> VULNERABLE"; }
  fi
fi

if [ $VULN -eq 1 ]; then
  echo "RESULT: VULNERABLE"
  exit 2
elif [ $FOUND -eq 1 ]; then
  echo "RESULT: PATCHED"
  exit 0
else
  echo "RESULT: UNKNOWN (no ANTLR4 tool detected on this host)"
  exit 1
fi

Sources

1. CVE-2026-13500 — Vulnerability-Lookup (CIRCL)
2. CVE-2026-13501 (sibling local injection in GoTarget) — CIRCL
3. GHSA-M64J-M5C8-F58P — Vulnerability-Lookup
4. CWE-74: Improper Neutralization of Special Elements ('Injection') — MITRE
5. ANTLR4 project — GitHub
6. antlr4 npm package — Snyk advisories
7. FIRST EPSS model
8. CISA KEV catalog