Go net/textproto CVE-2026-42507

Exploitation requires three concurrent conditions: first, the target application must be compiled with a vulnerable Go toolchain (net/textproto < 1.25.11 or < 1.26.4); second, the application must exercise a code path in net/textproto that returns an error incorporating user-supplied input - this occurs naturally in any Go application using net/http, net/mail, or net/textproto directly to parse attacker-reachable protocol data; third, the application must log or print the resulting error string without sanitizing newline or control characters. The CVSS PR:N (no privileges required) and UI:N (no user interaction) signals confirm exploitation does not require authentication or social engineering. Exploitation is limited in practice by the fact that it produces only misleading log/error content - there is no code execution, data exfiltration, or service disruption. Deployments that suppress, discard, or structured-encode net/textproto errors are not exposed to meaningful impact.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) reflects a network-reachable, low-complexity, unauthenticated attack yielding limited integrity impact with no confidentiality or availability consequence - consistent with a log-injection class vulnerability rather than code execution. EPSS corroborates the low operational risk: a 0.02% exploitation probability at the 5th percentile indicates this vulnerability is not being targeted opportunistically in the wild at time of analysis. No CISA KEV entry exists and no public exploit code has been identified. The practical threat is narrower than the CVSS network vector suggests: exploitation only produces meaningful impact when the calling application logs or displays net/textproto error messages in contexts visible to operators or downstream consumers. Applications that discard errors silently or sanitize output before logging are unaffected in practice. Overall, this is a genuine but low-urgency issue: patch during the next scheduled Go runtime update cycle rather than treating as an emergency.

An attacker targeting a Go web service sends an HTTP request containing a crafted header value embedding newline sequences and fabricated log lines (e.g., 'X-Custom: value\n[INFO] Admin login successful from 10.0.0.1'). The Go net/textproto parser encounters a protocol error and constructs an error message that includes the raw header value verbatim; the application's error handler logs this string, resulting in the injected fabricated entry appearing as a legitimate log line in the application's log stream. No public proof-of-concept exploit exists, but the attack requires only standard HTTP tooling and basic knowledge of log injection techniques.