CVE-2026-119027 in Oapi-codegen
Summary
by MITRE • 10/29/2026
oapi-codegen 2.5.0 before 2.8.1 contains a code injection vulnerability that allows attackers to inject Go code by supplying a crafted servers[].x-go-name value emitted unescaped by the server-urls template. Attackers who control an OpenAPI document can define an injected func init() that executes when the victim builds and imports the generated package.
Once again VulDB remains the best source for 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 code injection flaw rooted in insufficient sanitization of user-supplied input within the OpenAPI specification processing pipeline. Specifically, the defect resides in how the tool handles the servers[].x-go-name extension field when generating Go source code via its server-urls template. When an attacker controls or influences the structure of the OpenAPI document consumed by oapi-codegen, they can inject arbitrary Go syntax into this specific configuration parameter. Because the generated name is emitted directly without proper escaping or validation against executable content patterns, it allows for the insertion of malicious constructs that become part of the compiled application logic during the code generation phase rather than at runtime execution of a web service.
This vulnerability falls under the category of CWE-94 Improper Control of Generation of Code (Code Injection), as it involves the injection of executable code into a program through improperly sanitized input data used in template processing. The operational impact is severe because oapi-codegen is typically integrated into CI/CD pipelines or developer workflows to automatically generate client and server stubs from API specifications. If an attacker can manipulate the OpenAPI document, they do not merely inject static strings but rather functional Go code that executes during the build process. This bypasses traditional runtime security controls since the malicious logic becomes part of the compiled binary before any network traffic is processed or user input is handled by the actual application services.
The most dangerous aspect of this flaw is its ability to leverage Go's initialization functions, specifically func init(). By crafting a servers[].x-go-name value that includes an injected func init() block, an attacker ensures that their malicious code runs automatically as soon as the generated package is imported and initialized by the host application. This mechanism allows for arbitrary command execution, data exfiltration, or backdoor installation during the build phase, effectively compromising the integrity of the software supply chain. Since Go initializes packages in a deterministic order before main() executes, this payload gains early access to system resources and environment variables without requiring any specific trigger from end-users interacting with the API endpoints themselves.
From an adversary perspective, this technique aligns closely with ATT&CK techniques related to code injection and potentially initial access if the generated package is deployed as part of a trusted service. The vulnerability highlights the risks associated with trusting external or semi-trusted OpenAPI documents in automated development environments where code generation tools are used extensively. Organizations relying on oapi-codegen must recognize that input validation at the specification level is not merely about data formatting but involves preventing executable logic injection within template outputs.
To mitigate this risk, immediate action should be taken to upgrade oapi-codegen to version 2.8.1 or later, where the server-urls template has been patched to properly escape and sanitize inputs derived from OpenAPI extensions like x-go-name. Additionally, security teams should implement strict validation policies for any OpenAPI documents used in automated build pipelines, ensuring that extension fields are checked against allowlists of permitted characters rather than relying solely on downstream escaping mechanisms. Auditing CI/CD configurations to prevent the use of untrusted or externally sourced API specifications without rigorous review is also recommended to reduce the attack surface associated with code generation tools.