CVE-2026-119028 in oapi-codegen
Summary
by MITRE • 10/29/2026
oapi-codegen 2.0.0 before 2.8.1 contains a code injection vulnerability that allows attackers to inject Go code by supplying non-literal enum entries in integer, number, or boolean schemas. Attackers controlling an OpenAPI document can craft an enum entry that closes the const block in constants.tmpl and injects a func init(), executing code when the generated package is built and imported.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in oapi-codegen versions prior to 2.8.1 represents a critical server-side template injection flaw within an automated Go code generation tool. This security issue stems from insufficient input validation and sanitization mechanisms applied to enum entries defined within OpenAPI specification documents. When the generator processes schemas of type integer, number, or boolean that contain non-literal enum values, it fails to properly escape these inputs before embedding them into the underlying Go template files. Specifically, the vulnerability targets the constants.tmpl file used by the tool to generate constant definitions for the specified data types. Because the input is treated as raw text rather than sanitized string literals, an attacker who controls or influences the OpenAPI document can manipulate the structure of the generated code.
The technical mechanism of exploitation relies on breaking out of the intended Go syntax context within the template engine. By supplying a carefully crafted enum entry that includes characters such as double quotes and parentheses, an adversary can close the existing const block prematurely. This structural break allows for the injection of arbitrary Go code fragments directly into the generated source file. The most dangerous aspect of this flaw is the ability to inject function definitions, particularly func init() blocks. In Go programming language conventions, functions named init are automatically executed when a package is initialized or imported by another program. Consequently, injecting such a function means that any malicious payload included within it will run without explicit invocation during the build process of the generated application.
The operational impact of this vulnerability extends beyond simple code generation errors to severe security compromises for downstream consumers of the generated libraries. Organizations relying on oapi-codegen to create client or server stubs from OpenAPI specifications are at risk if they incorporate untrusted or externally sourced API definitions into their development pipelines. If a malicious actor can influence the specification used by an organization, they can effectively achieve remote code execution within the build environment of that organization. This could lead to the compromise of source control systems, theft of cryptographic keys stored in the repository, installation of backdoors, or disruption of continuous integration and deployment workflows through destructive commands embedded in the injected init function. The risk is particularly acute for public-facing API providers who allow third parties to submit specifications or for internal teams that aggregate definitions from multiple sources without rigorous validation.
To mitigate this vulnerability, organizations must immediately upgrade oapi-codegen to version 2.8.1 or later, where these input sanitization issues have been addressed by properly escaping special characters and validating enum entries against strict literal constraints. In environments where upgrading is not immediately feasible, defensive measures should include implementing a pre-processing step that validates all OpenAPI documents for suspicious patterns before they are passed to the code generator. This validation layer should reject any schema definitions containing non-literal values in integer, number, or boolean enums if such flexibility is not strictly required by business logic. Additionally, adopting strict content security policies and sandboxing build environments can limit the blast radius of potential exploitation attempts.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), as it involves the injection of executable code into an application through untrusted input. It also maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically regarding the abuse of init functions for automated execution upon import. The attack vector is classified under CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component (Injection), highlighting the failure to neutralize special elements before they are processed by downstream code generation tools. Security teams should treat this as a high-severity issue requiring immediate patching due to its direct impact on build-time security and potential for arbitrary code execution.