CVE-2026-39820

What it actually does

This vulnerability is a denial-of-service flaw in Go code paths that parse email-style addresses and dates, specifically inputs reaching ParseAddress, ParseAddressList, or ParseDate. A specially crafted string can cause excessive CPU consumption and memory allocation during parsing. Because the CVSS vector is network-accessible, low-complexity, unauthenticated, and requires no user interaction, any Go-based service that accepts untrusted address or date input and passes it to the affected parsing functions may be vulnerable to remote resource exhaustion.

Why it matters to the business

An attacker may be able to make affected Go-based applications slow, unstable, or unavailable by sending malformed address or date values. This can disrupt customer-facing services, APIs, mail-processing workflows, authentication flows that parse email addresses, and backend jobs that consume message headers or user-supplied dates. The issue is not currently listed in CISA KEV, has no known ransomware association, has low EPSS activity, and no public exploit maturity is reported, but availability impact is high and internet-exposed parsers should still be prioritized.

How an attack unfolds

An attacker first identifies an application endpoint or processing path that accepts untrusted email address, address-list, or date-like input. This may include registration forms, contact fields, inbound email processing, API parameters, webhook payloads, message headers, or import pipelines. The attacker then submits specially crafted values designed to exercise worst-case behavior in Go's parsing routines. When the vulnerable code calls ParseAddress, ParseAddressList, or ParseDate, the parser consumes excessive CPU and/or allocates large amounts of memory. Repeated requests or high-concurrency submissions can exhaust worker threads, increase garbage collection pressure, trigger out-of-memory conditions, cause process restarts, or render the service unavailable.

How to fix it

Upgrade to a Go release that contains the upstream fix once available from the Go project or your operating system/package vendor. Because no fixed versions were provided in the input, verify the applicable patched version from official Go security advisories, distribution errata, container base image updates, and language runtime release notes. Rebuild and redeploy all statically linked Go applications after updating the toolchain or standard library, because many Go binaries embed vulnerable code at build time. As compensating controls, enforce strict maximum lengths on address and date fields, reject unusual or deeply nested input before parsing, apply request body limits, rate-limit unauthenticated endpoints, add timeouts/circuit breakers around parsing-heavy workflows, and isolate batch/mail-processing workers so resource exhaustion does not impact critical services.

How to confirm the fix worked

Inventory Go applications that call net/mail ParseAddress, ParseAddressList, or ParseDate directly or indirectly. Confirm the Go toolchain/runtime version used to build each binary and verify it matches a vendor-confirmed fixed release when available. Rebuild binaries and containers, then validate deployed artifacts with `go version -m <binary>` where supported. Perform safe negative testing with oversized and malformed address/date inputs in a non-production environment and confirm requests are rejected quickly, memory usage remains bounded, CPU does not spike abnormally, and processes do not restart. Review dependency and container scans to ensure old Go base images or statically linked binaries are not still present.

Typical attack path

1. Identify a Go-based service or component that accepts address, address-list, or date input from unauthenticated or low-trust sources.
2. Send malformed or adversarially structured email address or date strings to the exposed endpoint, API, queue, or mail-processing path.
3. Trigger vulnerable parsing behavior in ParseAddress, ParseAddressList, or ParseDate.
4. Force excessive CPU use, memory allocation, garbage collection pressure, or process crashes.
5. Repeat or parallelize requests to sustain service degradation or outage.

How to detect it

To determine whether this was already exploited, review application, API gateway, WAF, reverse proxy, container, host, and orchestration logs for bursts of requests containing unusually long, malformed, or repetitive email-address, address-list, or date fields followed by latency spikes, HTTP 500/502/503/504 responses, process restarts, out-of-memory kills, or CPU saturation. Correlate timestamps of abnormal input with Go runtime logs, garbage-collection telemetry, memory allocation spikes, container restart events, kernel OOM messages, and autoscaling events. For mail-processing systems, review inbound message headers and queue items with abnormal From, To, Cc, Reply-To, Date, or Received values that coincide with worker crashes or processing delays. Because no public exploit pattern or actor-specific signature is provided, detection should focus on resource-exhaustion behavior and parser-related failure artifacts rather than a single definitive payload.

• ParseAddress
• ParseAddressList
• ParseDate
• net/mail
• fatal error: runtime: out of memory
• runtime: out of memory
• signal: killed
• OOMKilled
• Killed process
• Out of memory: Killed process
• container restarted
• CrashLoopBackOff
• context deadline exceeded
• upstream timed out
• HTTP 503
• HTTP 504
• panic: runtime error
• gc CPU fraction
• excessive memory allocation

What your security team should do

• Prioritize internet-facing Go services that parse email addresses, message headers, contact lists, user profile fields, API date parameters, inbound email, or webhook payloads.
• Track official Go security advisories and vendor errata for the exact fixed version; upgrade the Go toolchain and rebuild all affected binaries once patched versions are available.
• Apply compensating controls immediately for exposed services: input size limits, schema validation, request timeouts, rate limits, and per-endpoint resource limits.
• Search code repositories for use of ParseAddress, ParseAddressList, ParseDate, and net/mail parsing wrappers that process untrusted input.
• Monitor affected services for CPU saturation, memory growth, garbage collection spikes, out-of-memory kills, container restarts, 5xx bursts, and latency increases following malformed input submissions.
• Ensure autoscaling, queue workers, and restart policies do not amplify the attack by repeatedly retrying malicious payloads without backoff or quarantine.
• Add WAF/API gateway rules where feasible to limit excessively long or malformed address/date fields before they reach Go application code.