fastapi-code-generator: Attacker-controlled OpenAPI Spec Can Trigger Code Execution at Import Time (CVE-2026-63469)

What happened

A newly published GHSA advisory (GHSA-6xmv-cjr5-w3q8, CVE-2026-63469) reports a code-injection vulnerability in fastapi-code-generator, the koxudaxi tool that turns an OpenAPI spec into a FastAPI application. According to the maintainer report, when an operation defines a second (non-primary) response, the generator writes that response's status-code key directly into the responses={...} dict literal inside the generated @app.get(...) decorator — as a single-quoted string, without escaping. Because the status-code key is treated as pure data but emitted as code, a single quote in that key can close the string and, via concatenation, splice in a live Python expression (e.g. an __import__("os").system(...) call). That expression executes when the generated main.py is imported — which happens automatically at ASGI server startup, with no request required. The advisory notes it was verified against fastapi-code-generator 0.8.0 with Python 3 and FastAPI, and includes a PoC (make_spec.py / reproduce.sh) that reproduces execution purely by importing the generated module.

Why it matters

This is import-time, pre-request code execution — any pipeline that generates a FastAPI app from an OpenAPI spec and then imports or serves it is affected if that spec is attacker-controlled or attacker-influenced in any way (e.g. ingested from a partner, a marketplace, a CI job building from an external schema, or a codegen-as-a-service workflow). The report estimates this as Critical (CVSS v4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N), and unlike some sibling findings in the same codebase (path and summary/docstring fields), this one specifically abuses the response status-code key inside the decorator's responses dict — a field developers are unlikely to think of as a code-generation sink. The advisory also notes that a payload which breaks Python syntax causes a denial-of-service during the generator's black/isort post-processing step rather than silent corruption, which is a secondary risk to be aware of even for malformed-but-non-malicious specs.

What defenders should watch for now

• Treat any OpenAPI/Swagger spec from an untrusted or partially-trusted source as code input, not pure data, if it feeds fastapi-code-generator — this includes specs pulled from external APIs, vendor integrations, or user-submitted schemas in internal tooling.
• Audit CI/CD and build pipelines for any step that runs fastapi-code-generator against specs that are not fully first-party and reviewed before generation.
• Review generated main.py files for anomalous content in responses={...} dict keys — specifically, status-code-like strings containing quotes, parentheses, or __import__/os.system-style constructs — before they are committed or deployed.
• Where generated code is imported automatically at service startup (the exploitation trigger here), consider adding a static review or sandboxed import/lint pass on freshly generated files before they reach a running ASGI process.
• Watch for unexpected process spawns or outbound activity immediately following application startup/import in environments that run spec-driven codegen, as that is the exploitation window described in the advisory.

No official patched version or fixed-release guidance is cited in the advisory text provided here; the maintainer's suggested fix is to escape response status-code keys for Python string-literal safety (via repr-style escaping) and validate that they are numeric or match a known pattern before emission. Pending a fix release, the most direct mitigation is to avoid generating from untrusted specs and to review generated decorator arguments before import.

Developing intel

This is a same-day advisory and should be treated as developing intelligence — details such as affected version ranges beyond 0.8.0, a confirmed patched release, and broader exploitation-in-the-wild status may evolve. For the full technical write-up, PoC files, and maintainer report, see the original GHSA advisory: GHSA-6xmv-cjr5-w3q8.