NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

check-jsonschema default caching for remote schemas allows for cache confusionGHSA-q6mv-284r-mp36

HIGHFix: python-jsonschema/check-jsonschema@c52714b

GHSA-q6mv-284r-mp36 is a high-severity (CVSS 7.1) CWE-349 vulnerability in check-jsonschema. A fix is available for check-jsonschema — see the affected versions and patch details below.

Also known asCVE-2024-53848PYSEC-2026-1245
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-q6mv-284r-mp36.

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs4th percentile — riskier than 4% of all scored CVEsHighest risk
0.00%0.21%0.43%0.65%0.0%0.1%May 26Aug 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐍check-jsonschema

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

check-jsonschema is a CLI and set of pre-commit hooks for jsonschema validation. The default cache strategy uses the basename of a remote schema as the name of the file in the cache, e.g. https://example.org/schema.json will be stored as schema.json. This naming allows for conflicts. If an attacker can get a user to run check-jsonschema against a malicious schema URL, e.g., https://example.evil.org/schema.json, they can insert their own schema into the cache and it will be picked up and used instead of the appropriate schema. Such a cache confusion attack could be used to allow data to pass validation which should have been rejected. This issue has been patched in version 0.30.0. All users are advised to upgrade. A few workarounds exist: 1. Users can use --no-cache to disable caching. 2. Users can use --cache-filename to select filenames for use in the cache, or to ensure that other usages do not overwrite the cached schema. (Note: this flag is being deprecated as part of the remediation effort.) 3. Users can explicitly download the schema before use as a local file, as in curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIcheck-jsonschemaall versions0.30.0pip install --upgrade 'check-jsonschema==0.30.0'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for check-jsonschema, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update check-jsonschema to 0.30.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q6mv-284r-mp36 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This vulnerability is of significant severity because it directly undermines the integrity of the JSON schema validation process, a important mechanism for ensuring data consistency and security in many applications. By exploiting the cache naming collision, an attacker can inject a malicious schema that bypasses…

Workaround published by Red Hat
- Users can use --no-cache to disable caching. - Users can use --cache-filename to select filenames for use in the cache, or to ensure that other usages do not overwrite the cached schema. (Note: this flag is being deprecated as part of the remediation effort.) - Users can explicitly download the schema before use as a local file, as in curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json
Source: Red Hat security advisory for GHSA-q6mv-284r-mp36 (CC BY 4.0)

Frequently Asked Questions

### Impact The default cache strategy uses the basename of a remote schema as the name of the file in the cache, e.g. `https://example.org/schema.json` will be stored as `schema.json`. This naming allows for conflicts. If an attacker can get a user to run `check-jsonschema` against a malicious schema URL, e.g., `https://example.evil.org/schema.json`, they can insert their own schema into the cache and it will be picked up and used instead of the appropriate schema. Such a cache confusion attack could be used to allow data to pass validation which should have been rejected. ### Patches A pa
O3 Security · Impact-Aware SCA

Is GHSA-q6mv-284r-mp36 in your dependencies?

Find it across PyPI, including transitive dependencies.

GHSA-q6mv-284r-mp36: check — Fixed in 0.30.0