CVE-2026-33811

What it actually does

This vulnerability affects Go applications that call LookupCNAME or Resolver.LookupCNAME while using the cgo-based DNS resolver. A DNS response containing an excessively long CNAME can trigger incorrect C memory handling, resulting in a double-free and process crash. The impact is denial of service: the flaw does not provide confidentiality or integrity compromise based on the available description, but it can remotely terminate affected processes if an attacker can cause the application to resolve a malicious or attacker-controlled CNAME response.

Why it matters to the business

Exploitation can cause Go-based services to crash when they perform CNAME lookups, leading to service outages, failed transactions, degraded availability, and potential cascading failures in systems that depend on DNS-based discovery or validation. The CVSS score indicates high availability impact, but current EPSS is low, there is no known KEV listing, no reported ransomware use, and no public exploit maturity in the provided data, so remediation should be prioritized for internet-facing or high-availability Go services that perform DNS lookups on untrusted domains.

How an attack unfolds

An attacker first identifies or influences a code path in a Go application that performs CNAME resolution, especially for user-supplied or externally influenced domain names. The attacker then controls the queried DNS zone, poisons/intercepts DNS resolution, or otherwise causes the application to receive a crafted DNS response containing a very long CNAME. If the application is using the cgo DNS resolver, the malformed response can trigger a double-free in C memory management during LookupCNAME processing. The affected process may abort or crash, causing denial of service until it is restarted. Repeated triggering can create persistent service instability.

How to fix it

Upgrade affected Go toolchains and rebuild affected Go applications once a patched Go release is available from the Go project or the relevant operating system/package vendor. No exact fixed version was provided in the input, so track official Go security advisories and vendor package updates for CVE-2026-33811. As interim mitigation, avoid use of the cgo DNS resolver where possible by using the pure Go resolver, for example by setting GODEBUG=netdns=go or configuring net.Resolver with PreferGo: true in application code. Reduce exposure by avoiding LookupCNAME on untrusted or user-controlled domains, validating and constraining domain-name inputs, routing DNS through trusted resolvers that enforce sane response-size and record-length limits, and adding process supervision/rate limiting to reduce outage duration if crashes occur.

How to confirm the fix worked

Confirm which Go versions were used to build deployed binaries and whether they include the vendor fix once available. Review application code and dependencies for calls to net.LookupCNAME or Resolver.LookupCNAME. Validate resolver mode by checking deployment configuration for GODEBUG=netdns=cgo, platform defaults, CGO_ENABLED builds, or application-level resolver settings; prefer GODEBUG=netdns=go as a mitigation. After remediation, test with controlled DNS responses containing long CNAME chains or oversized CNAME values in a non-production environment and confirm the application handles failures without crashing. Operationally, verify that crash rates, SIGABRT/SIGSEGV events, and DNS-related application errors do not recur after upgrade or mitigation.

Typical attack path

1. Identify a Go-based service or workflow that performs CNAME lookups.
2. Find an input or integration that causes the service to resolve attacker-controlled domain names, or gain the ability to influence DNS responses.
3. Return a DNS response containing an excessively long CNAME record.
4. Trigger the vulnerable LookupCNAME path while the application is using the cgo DNS resolver.
5. Cause a double-free condition in C memory handling, resulting in process abort or crash.
6. Repeat requests or DNS responses to sustain denial of service.

How to detect it

Look for evidence of unexpected crashes in Go services shortly after CNAME lookups or DNS traffic involving unusually long CNAME records. Useful sources include application logs, systemd/journald logs, container runtime logs, Kubernetes pod termination events, core dump metadata, endpoint crash telemetry, DNS resolver logs, packet captures, and egress DNS telemetry. Focus on process aborts or segmentation faults with messages indicating double-free or heap corruption, especially when stack traces reference Go DNS resolution functions such as LookupCNAME, Resolver.LookupCNAME, cgoLookupCNAME, or net package resolver code. In DNS logs, hunt for unusually long CNAME answers, repeated queries to attacker-controlled or newly observed domains, high NXDOMAIN/SERVFAIL patterns around the same time as crashes, and repeated service restarts following DNS lookups. Because exploitation primarily causes denial of service, absence of persistence artifacts does not rule out exploitation; correlate crash timing with DNS query/response data.

• free(): double free
• double free or corruption
• malloc(): memory corruption
• malloc: *** error for object
• pointer being freed was not allocated
• SIGABRT
• SIGSEGV
• signal: aborted
• signal: segmentation fault
• net.LookupCNAME
• Resolver.LookupCNAME
• cgoLookupCNAME
• GODEBUG=netdns=cgo
• GODEBUG=netdns=go
• LookupCNAME
• CNAME response
• Back-off restarting failed container
• CrashLoopBackOff

What your security team should do

• Inventory Go applications and services that perform DNS lookups, especially CNAME lookups on externally supplied domains.
• Prioritize internet-facing, high-availability, and DNS-heavy Go services for assessment and mitigation.
• Determine whether affected services use the cgo DNS resolver; switch to the pure Go resolver where operationally safe.
• Monitor official Go and OS vendor advisories for fixed versions, then rebuild and redeploy affected Go binaries promptly.
• Add regression tests for long or malformed CNAME responses around DNS-resolution code paths.
• Harden DNS egress by using trusted recursive resolvers, response filtering, and monitoring for anomalously long CNAME responses.
• Monitor for crashes with double-free, malloc corruption, SIGABRT, or DNS lookup stack traces that involve Go CNAME resolution.
• Ensure process supervisors, orchestration health checks, and rate limits are configured to prevent repeated crash loops from becoming prolonged outages.