GHSA-RJWR-M7QX-3FJR: Code Generation Injection in oapi-codegen

The Go OpenAPI toolchain oapi-codegen is widely utilized to translate OpenAPI specifications into typed Go boilerplate code, including server interfaces, clients, and type definitions. The code generator operates by parsing JSON or YAML specification files and passing the structured metadata to internal templates. This design exposes an attack surface where the structure and properties of the generated output are directly influenced by the values supplied in the specification document.\n\nGHSA-RJWR-M7QX-3FJR identifies an arbitrary code generation injection flaw within this translation workflow. A remote attacker who can control or manipulate the contents of an OpenAPI specification can craft malicious metadata that escapes the boundaries of generated string constants or code comments. When the code generator executes on this specification, the injected payload is seamlessly written into the resulting Go files as valid executable statements.\n\nThe vulnerability is classified under CWE-94 (Improper Control of Generation of Code), CWE-116 (Improper Encoding or Escaping of Output), and CWE-74 (Improper Neutralization of Special Elements). Because the generated Go files are automatically compiled or evaluated during testing and deployment pipelines, this flaw constitutes a severe supply chain compromise vector. If an automated web service exposes oapi-codegen to process user-supplied specifications, the vulnerability escalates to an unauthenticated remote code execution vector.

The vulnerability stems from two independent validation failures in the string manipulation helpers within the pkg/codegen package. The first failure involves inadequate line break sanitization when documenting generated endpoints. The generator extracts the description fields from the OpenAPI schema and places them within single-line comments (//) to provide context to developers.\n\nTo prevent descriptions from spanning multiple lines and breaking out of comment blocks, the generator implemented a stripNewLines helper function. This function used strings.NewReplacer to target only the line feed character (\n) and replace it with an empty string. However, it completely omitted the carriage return character (\r). If a specification contained platform-specific line endings like \r\n or single \r characters, the carriage return was preserved and passed into the template. The Go compiler interprets certain carriage return sequences as statement terminators, allowing an attacker to end the comment block and declare arbitrary Go structures.\n\nThe second, more severe failure exists in the string-escaping logic within StringToGoString in pkg/codegen/utils.go. This utility was designed to convert arbitrary schema fields into valid Go string literals by replacing double quotes (") with escaped quotes (\"). Crucially, the function failed to escape backslashes (\) before replacing the quotes.\n\nWhen an attacker provides an input sequence containing a backslash followed by a double quote (\"), the naive search-and-replace processes the double quote but leaves the preceding backslash raw. This results in the sequence \\\" in the intermediate string. During compilation, the Go parser evaluates the double-backslash (\\) as a single escaped backslash literal, and treats the subsequent unescaped double-quote (") as the closing delimiter of the string literal. Any characters following this quote are then parsed as raw executable Go code at the package scope.

Prior to the fix in version 2.7.1, the stripNewLines function in pkg/codegen/template_helpers.go was implemented with a single-character replacement mapping. This targeted only \n while allowing carriage returns to persist in the generated code comments.\n\ngo\n// Vulnerable Implementation\nfunc stripNewLines(s string) string {\n r := strings.NewReplacer("\\n", "")\n return r.Replace(s)\n}\n\n\nThe vulnerable string literal escaper in pkg/codegen/utils.go relied on a basic substring replacement that allowed escape-neutralization attacks.\n\ngo\n// Vulnerable Implementation\nfunc StringToGoString(in string) string {\n esc := strings.ReplaceAll(in, "\\"", "\\\\\\"")\n return fmt.Sprintf("\\"%s\\"", esc)\n}\n\n\nThe patch implemented in commit 19c6282e9a6fb84b51aa92b12fad1f0b7e5f5ef6 resolves both deficiencies. First, stripNewLines was modified to explicitly replace carriage returns (\r) as well as line feeds.\n\ngo\n// Patched Implementation\nfunc stripNewLines(s string) string {\n r := strings.NewReplacer("\\n", "", "\\r", "")\n return r.Replace(s)\n}\n\n\nSecond, the custom string escaper StringToGoString was entirely rewritten to use the robust standard library function strconv.Quote. This native function automatically handles backslashes, double quotes, and control characters safely.\n\ngo\n// Patched Implementation\nfunc StringToGoString(in string) string {\n return strconv.Quote(in)\n}\n\n\nAdditionally, the template file pkg/codegen/templates/server-urls.tmpl was updated to pipe variable properties through the toGoString helper, which calls the newly secured StringToGoString function. This ensures that raw formatting using "%s" is completely deprecated.

An exploit against a system using a vulnerable version of oapi-codegen requires the construction of an OpenAPI specification containing structured injection payloads. The attack can target either the comment-rendering pipeline or the constant-string generation pipeline.\n\nTo break out of the single-line comment block, an attacker crafts an OpenAPI servers[].description property with carriage returns that terminate the comment block. The payload then introduces a package initialization function init(). Because init blocks run automatically upon package loading, the payload achieves execution without requiring any direct interaction from the importing application.\n\nyaml\nservers:\n - url: 'https://api.example.com'\n description: "Safe Server\rfunc init() { println(\"Injected\") }\r//"\n\n\nTo exploit the string literal parser, the attacker uses the backslash escape bypass technique in the servers[].url field. By supplying \" within the URL string, the final compiled output collapses the backslash escaping, closes the string literal, and executes the injection.\n\nyaml\nservers:\n - url: 'https://api.example.com\"; func init() { println(\"Injected\") }; var _ = "'\n description: "Exploiting string literal context"\n\n\nmermaid\ngraph LR\n subgraph "Attacker Control"\n A["Malicious OpenAPI Spec"]\n end\n subgraph "Code Generation"\n B["oapi-codegen (Vulnerable)"] --> C["api.gen.go (Injected Code)"]\n end\n subgraph "Compilation Environment"\n C --> D["go build / go test"]\n D --> E["Arbitrary Code Execution"]\n end\n A --> B\n\n\nThe process flow begins when the development environment or CI/CD runner fetches the untrusted specification and triggers code generation. When go test or go build is run subsequently, the Go toolchain compiles the generated api.gen.go file, triggering the injected package initializer.

The security implications of GHSA-RJWR-M7QX-3FJR vary depending on the deployment architecture of the code generation tool. In a standard development pipeline, the vulnerability functions as a supply chain exploit. Attackers can submit malicious specifications to open-source or proprietary repositories, inducing local developers or automated CI/CD workers to run oapi-codegen and compile the output.\n\nIf the pipeline executes tests automatically, compiling the injected init() function results in immediate execution of arbitrary shell commands in the context of the build host. This allows attackers to exfiltrate environment variables, source code, deployment credentials, and signing keys from the runner environment.\n\nIn environments where oapi-codegen is exposed as an online web tool or backend service to generate client SDKs on demand, the severity increases. An unauthenticated remote attacker can submit a malicious payload and trigger immediate code execution on the hosting server, leading to full system compromise.\n\nDue to the lack of an assigned CVE, there is no official CVSS or EPSS rating for this specific advisory. However, applying standard CVSS v3.1 metrics for local supply chain execution results in a base score of 8.6 (High), while remote service scenarios evaluate to a score of 10.0 (Critical).

The primary remediation strategy is to upgrade github.com/oapi-codegen/oapi-codegen to version v2.7.1 or higher. This modifies the code generation engine to use strconv.Quote for all variable outputs and sanitizes carriage returns from comment structures.\n\nFor development environments unable to apply immediate updates, several defense-in-depth measures should be deployed. Organizations must implement strict schema validation pipelines that scan incoming OpenAPI documents for control characters, carriage returns, and abnormal double-quote structures before passing them to development utilities.\n\nTo detect active compromise or vulnerable configurations in build pipelines, security teams can employ static analysis rules. The following YARA rule can be utilized to scan Go binaries or source folders to identify vulnerable implementations of the StringToGoString helper:\n\nyara\nrule vulnerable_oapi_codegen_string_escaping {\n meta:\n description = "Detects the vulnerable implementation of StringToGoString in oapi-codegen source"\n author = "Security Researcher"\n reference = "https://github.com/advisories/GHSA-RJWR-M7QX-3FJR"\n strings:\n $naive_escape = "strings.ReplaceAll(in, \"\\\"\", \"\\\\\\\"\")"\n $naive_fmt = "fmt.Sprintf(\"\\\"%s\\\"\", esc)"\n condition:\n all of them\n}\n\n\nAdditionally, monitoring network logs for unusual outbound connections originating from CI/CD runners during compiler execution can help detect post-exploitation behavior.