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)
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
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
datamodel-code-generatorReal-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_refsis its default (None); execution falls through to (B). - (B) routes the URL through
_get_text_from_url→get_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:
- Trojaned OpenAPI document. A public REST API publishes
openapi.yaml. One$refpoints athttp://169.254.169.254/latest/meta-data/iam/security-credentials/<role>; runningdatamodel-codegenagainst the spec from an EC2 instance leaks the IAM credentials into the generated client. - Customer-supplied JSON Schema. A B2B SaaS auto-generates client code from customer-uploaded schemas. The customer adds an HTTP
$reftohttp://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. - CI on a private network. A PR adds
schemas/inbound.jsonwith an HTTP$refpointed at a service reachable only from the CI cluster's VPC; the CI runner fetches it and the generated.pyleaks 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.
- Flip the default in
parser/base.py:allow_remote_refs: bool = False, and remove the silent-fetch-with-warning fallback atparser/jsonschema.py:4786-4791. - When fetching is allowed, apply the same IP/host validation proposed for other submitted SSRF report to both the initial
$refURL and every redirect target. - Document HTTP
$refin a third-party schema as equivalent to runningcurlon 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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | datamodel-code-generator | ≥ 0.9.1&&< 0.61.0 | 0.61.0 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
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.
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.
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
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.