CVE-2026-42499

What it actually does

This vulnerability is a network-exploitable denial-of-service condition in Go’s RFC 5322 email address parsing logic. Pathological email address input can cause excessive CPU consumption in the consumePhrase parsing path, potentially tying up application worker threads or request handlers. Applications are most exposed when they parse attacker-controlled email addresses from HTTP requests, API payloads, SMTP/message headers, identity/profile fields, contact forms, invitations, or other user-supplied data using the affected Go email parsing functionality. The CVSS vector indicates no authentication or user interaction is required and the primary impact is loss of availability, not confidentiality or integrity.

Why it matters to the business

An attacker may be able to make public-facing or message-processing services slow, unavailable, or unstable by sending specially crafted email address values. This can disrupt customer signups, authentication flows, messaging pipelines, support/contact forms, notification processing, or any workflow that validates email addresses. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, has low and flat EPSS activity, and has no reported exploit maturity in the provided data, but the 7.5 availability score means internet-exposed services that parse untrusted email addresses should still be prioritized for mitigation.

How an attack unfolds

An attacker first identifies an application endpoint or service path that accepts or processes email address input. They then submit an unusually structured RFC 5322-style address designed to trigger pathological behavior in the parser’s phrase-consumption logic. If the application parses that value synchronously on request, queue, or message-processing workers, the parser may consume excessive CPU and hold execution resources for an extended period. Repeating the request or delivering many such messages can exhaust worker capacity, increase latency, trigger timeouts, and potentially cause health-check failures or autoscaling events. Because the issue affects availability rather than data access, exploitation generally appears as resource exhaustion and service degradation rather than as creation of files, accounts, or persistent artifacts.

How to fix it

Upgrade to a Go release that contains the vendor fix as soon as one is available, then rebuild and redeploy all Go applications that include the affected standard-library parser. No fixed versions were provided in the input, so track official Go security advisories and distribution package updates for the exact patched versions. Until patched builds are deployed, reduce exposure by enforcing strict maximum lengths on email address fields and message headers before parsing, rejecting unnecessarily complex RFC 5322 constructs where business requirements allow, applying request/body/header size limits, rate limiting unauthenticated submission paths, isolating message parsing workers, and using operational timeouts and circuit breakers around workflows that parse untrusted email addresses. For high-risk public endpoints, consider replacing permissive RFC 5322 parsing with a simpler allowlisted validation policy if full RFC compatibility is not required.

How to confirm the fix worked

Confirm exposure by inventorying applications built with Go that parse untrusted email addresses, especially those using Go standard-library email parsing behavior. Verify the Go toolchain or runtime package version used to build each service once patched versions are announced, and ensure binaries were rebuilt rather than only updating the build host. Validate mitigations by confirming maximum input-size limits exist before email parsing, unauthenticated endpoints are rate limited, and oversized or complex email inputs are rejected quickly. Operationally, test representative malformed and oversized email-address inputs in a controlled environment and confirm they do not cause sustained CPU spikes, request-handler starvation, queue backlog, or timeouts.

Typical attack path

1. Find an internet-facing API, web form, SMTP/message ingestion path, or backend job that accepts email address input.
2. Submit crafted RFC 5322 email address strings containing pathological phrase/comment/quoted-token structure.
3. Cause the affected Go email parser path to spend excessive CPU in consumePhrase while validating or parsing the address.
4. Repeat requests or messages to occupy application workers, goroutines, or queue consumers.
5. Induce elevated latency, request failures, queue backlog, health-check failures, or service unavailability.

How to detect it

To determine whether exploitation has already occurred, review application, API gateway, WAF, mail-ingestion, queue-worker, and infrastructure telemetry for bursts of malformed or unusually long email-address values followed by CPU spikes, elevated request latency, 4xx/5xx errors, worker restarts, queue backlog, or health-check failures. Focus on unauthenticated endpoints such as signup, login, password reset, contact forms, invitations, newsletter signup, webhook ingestion, and email/message processing. In Go application logs and crash/debug artifacts, search for stack traces, goroutine dumps, pprof CPU profiles, or panic reports showing execution in net/mail parsing functions, especially consumePhrase. Correlate suspicious requests by source IP, user agent, route, request size, body/header length, and timestamp against host metrics showing high CPU with little corresponding I/O. Because this is a DoS vulnerability, durable host artifacts are unlikely; evidence will usually be in transient logs, metrics, profiling data, load balancer logs, and message queues rather than files or registry changes.

• consumePhrase
• net/mail.(*addrParser).consumePhrase
• net/mail.(*addrParser).parseAddress
• net/mail.ParseAddress
• net/mail.ParseAddressList
• pprof
• goroutine dump
• context deadline exceeded
• request timed out
• upstream timed out
• HTTP 504
• HTTP 503
• mail: missing '@' or angle-addr

What your security team should do

• Inventory Go-based services that parse user-supplied email addresses from web, API, SMTP, webhook, identity, invitation, or message-processing workflows.
• Prioritize internet-facing and unauthenticated parsing paths because the vulnerability requires no privileges or user interaction.
• Apply input length limits and rate limiting immediately where email address parsing occurs before authentication or in high-volume ingestion paths.
• Monitor official Go security releases and rebuild/redeploy affected applications when patched Go versions become available.
• Add detections for CPU saturation, request timeouts, queue backlog, and stack traces involving Go email parsing functions such as consumePhrase.
• Review WAF/API gateway/body size limits to ensure extremely long or deeply nested email-like values cannot reach backend parsers.
• Use canary or load testing after remediation to confirm malformed email inputs are rejected quickly and do not degrade service availability.