High priorityDisclosed

Advisory · CVE-2026-109237

Crawl4AI config bypass leaks secrets and enables JWT forgery

Non-admin Crawl4AI API clients can wrap forbidden configuration objects in dictionary wrappers to defeat the untrusted-config gate, read the server SECRET_KEY and provider keys through the config dump, and forge admin tokens. Fixed in 0.9.4.

Advisory published October 12, 2026Independent summary
Vendor
Crawl4AI
Product
Crawl4AI
Identifier / CWE
CVE-2026-109237
CWE-502
Action timing
Immediate
ELI5

Explain it like I’m five

Certain config objects are contraband at the API front desk. Wrapping one inside a plain box gets it past inspection, and the front desk then reads out the office safe combination written on it.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01API request sent

    A non-admin API client submits a configuration object the API is supposed to forbid.

  2. 02Wrapper applied

    The client wraps the object in a dictionary-type wrapper so the untrusted-config gate no longer recognizes it.

  3. 03Secrets returned

    A laundered LLM configuration referencing environment values causes the config dump to return the SECRET_KEY and provider keys.

  4. 04Admin forged

    With the SECRET_KEY, the attacker can forge an admin JWT and take over the API.

What happened

The Crawl4AI security advisory for CVE-2026-109237 covers Crawl4AI from 0.9.0 before 0.9.4 and rates the flaw CVSS 3.1 8.1.

Crawl4AI’s API is meant to stop non-admin clients from constructing forbidden configuration objects. Wrapping such an object in a dictionary-type wrapper defeats that gate. An attacker can send a laundered LLM configuration whose token field references an environment variable, and the config dump endpoint returns the resolved values, including the server SECRET_KEY and provider API keys. The SECRET_KEY enables admin JWT forgery.

Per the advisory record, 0.9.4 is the fixed release.

What to do

  1. Inventory Crawl4AI API deployments and check each version.
  2. Upgrade affected deployments to Crawl4AI 0.9.4 or later.
  3. Rotate the server SECRET_KEY and any provider API keys on deployments that served untrusted clients.
  4. Restrict API access to trusted clients until upgraded.
  5. Review config dump requests and issued tokens for access you do not recognize.
  6. Confirm the deployed version after upgrading.

Management note

The leaked SECRET_KEY is the real incident, not just the bypass. Patching without rotating that key and the provider keys leaves forged admin tokens and stolen credentials valid after the upgrade.