Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

GHSA-954p-556p-r752 is a high-severity (CVSS 8.2) Server-Side Request Forgery (SSRF) vulnerability in datamodel-code-generator. O3 Security confirms whether GHSA-954p-556p-r752 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

datamodel-code-generator vulnerable to SSRF via JSON-Schema `$ref` to HTTP URL (silent by default)

Also known asCVE-2026-54690PYSEC-2026-3560
Published
Jul 28, 2026
Updated
Aug 4, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 11, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-954p-556p-r752.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs17th percentile — riskier than 17% of all scored CVEsHighest risk
0.00%0.25%0.50%0.76%0.2%0.3%0.3%Aug 26Sep 26Sep 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-954p-556p-r752 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 372,296 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐍datamodel-code-generator

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

Summary

JSON-Schema $ref values pointing at HTTP or HTTPS URLs are silently dereferenced by datamodel-code-generator with no IP/host validation, no scheme allow-list, and redirects followed unconditionally. The --allow-remote-refs gate added in 0.56.0 defaults to None, which only emits a deprecation warning and then fetches the URL anyway; only explicit --allow-remote-refs=false blocks the request. The fetched body is parsed as a sub-schema and reflected verbatim into the generated .py source. As a result, any JSON-Schema document the developer feeds to datamodel-codegen — including documents authored by an attacker — can pivot to arbitrary internal addresses and leak the response into the generated code, with no developer cooperation beyond running the tool.

Details

Sink: src/datamodel_code_generator/parser/jsonschema.py, _get_ref_body (lines 4776–4793, at tag 0.60.1 / commit a321547e):

def _get_ref_body(self, resolved_ref: str) -> dict[str, YamlValue]:
    if is_url(resolved_ref):
        if not resolved_ref.startswith("file://") and self.http_local_ref_path is None:
            if self.allow_remote_refs is False:
                raise Error(f"Fetching remote $ref is disabled: {resolved_ref}...")
            if self.allow_remote_refs is None:
                warn_deprecated(                            # (A) warn only
                    "behavior.remote-ref-default",
                    details=f"Reference: {resolved_ref}",
                    stacklevel=2,
                )
        return self._get_ref_body_from_url(resolved_ref)    # (B) fetch fires
    return self._get_ref_body_from_remote(resolved_ref)
  • (A) emits a deprecation warning when allow_remote_refs is its default (None); execution falls through to (B).
  • (B) routes the URL through _get_text_from_urlget_body, the same fetcher described in other report — no IP validation, redirects followed.

The fetched body is then parsed as a sub-schema and merged into the model graph, so description, title, properties, etc. from the remote document end up in the generated .py source.

Only affects users who installed the [http] extra (pip install 'datamodel-code-generator[http]').

PoC

A self-contained one-file PoC is available here: https://gist.github.com/thegr1ffyn/562a6972d7dc3f2869458ae93fc608c0

Impact

Who is impacted. Anyone running datamodel-codegen on a JSON-Schema or OpenAPI document of uncertain provenance, with the [http] extra installed. Real-world scenarios:

  1. Trojaned OpenAPI document. A public REST API publishes openapi.yaml. One $ref points at http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>; running datamodel-codegen against the spec from an EC2 instance leaks the IAM credentials into the generated client.
  2. Customer-supplied JSON Schema. A B2B SaaS auto-generates client code from customer-uploaded schemas. The customer adds an HTTP $ref to http://internal-admin:8080/users.json; the response (e.g. JSON user list) ends up in the generated Python the SaaS hands back to the customer.
  3. CI on a private network. A PR adds schemas/inbound.json with an HTTP $ref pointed at a service reachable only from the CI cluster's VPC; the CI runner fetches it and the generated .py leaks the response in PR artifacts.

Higher real-world risk than the sibling CLI-flag SSRF (other SSRF in this report bundle) because the schema author chooses the destination — the developer doesn't have to type any URL.

Suggested fix.

  1. Flip the default in parser/base.py: allow_remote_refs: bool = False, and remove the silent-fetch-with-warning fallback at parser/jsonschema.py:4786-4791.
  2. When fetching is allowed, apply the same IP/host validation proposed for other submitted SSRF report to both the initial $ref URL and every redirect target.
  3. Document HTTP $ref in a third-party schema as equivalent to running curl on the developer's host.

Maintainer resolution

This $ref report is fixed by the same shared HTTP fetcher hardening that resolved GHSA-rfr2-mq9m-x2qx. The code landed through the GHSA-rfr2 private security PR koxudaxi/datamodel-code-generator-ghsa-rfr2-mq9m-x2qx#1 and was merged into the public repository as 5fdba4a09f2d7a9996a504975b7ef7d63e3715bb. Follow-up generated-file and coverage fixes were merged in koxudaxi/datamodel-code-generator#3279 and docs were synced in #3280. The patched release is 0.61.0.

No separate net code diff remains in the GHSA-954 private PR because the shared HTTP fetcher patch is already present on main. This advisory remains separate because the affected entry point is remote JSON Schema/OpenAPI $ref resolution rather than direct CLI --url input.

The fix does not flip the --allow-remote-refs compatibility default in this patch. Instead, it mitigates the SSRF issue by blocking localhost, loopback, private, link-local, reserved, and other non-public network targets by default, validating every redirect target before it is fetched, and requiring --allow-private-network / allow_private_network=True for trusted internal schema endpoints. Remote $ref fetching remains controlled by --allow-remote-refs; non-public/internal targets additionally require --allow-private-network.

Submitted by: Hamza Haroon (thegr1ffyn)

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIdatamodel-code-generator0.9.1&&< 0.61.00.61.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 datamodel-code-generator. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update datamodel-code-generator to 0.61.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-954p-556p-r752 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-954p-556p-r752 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-954p-556p-r752. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary JSON-Schema `$ref` values pointing at HTTP or HTTPS URLs are silently dereferenced by `datamodel-code-generator` with no IP/host validation, no scheme allow-list, and redirects followed unconditionally. The `--allow-remote-refs` gate added in 0.56.0 defaults to `None`, which only emits a deprecation warning and then fetches the URL anyway; only explicit `--allow-remote-refs=false` blocks the request. The fetched body is parsed as a sub-schema and reflected verbatim into the generated `.py` source. As a result, any JSON-Schema document the developer feeds to `datamodel-codegen` — i
O3 Security · Impact-Aware SCA

Is GHSA-954p-556p-r752 in your dependencies?

O3 detects GHSA-954p-556p-r752 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-954p-556p-r752: SSRF (High 8.2) | O3 Security