Skip to content

GO-2026-4981 BIT-golang-2026-33811 CVE-2026-33811

Crash when handling long CNAME response in net

High Go
Severity
7.5 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.88%
Chance of exploitation in the next 30 days. Higher than 58.98% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-1341 Multiple Releases of Same Resource or Handle
CWE-415 Double Free
Fix
1.26.3
Upgrade stdlib to this version or later

Description

When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash.

Affected versions

Go

PackageVulnerableFixed in
stdlib
< 1.25.10
>= 1.26.0-0, < 1.26.3
1.25.10
1.26.3

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

stdlib Go → 1.26.3

go
go get stdlib@v1.26.3 && go mod tidy

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-1341: Multiple Releases of Same Resource or Handle

The product attempts to close or release a resource or handle more than once, without any successful open between the close operations.

How to prevent it
  • Implementation: Change the code's logic so that the resource is only closed once. This might require simplifying or refactoring. This fix can be simple to do in small code blocks, but more difficult when multiple closes are buried within complex conditionals.
  • Implementation: It can be effective to implement a flag that is (1) set when the resource is opened, (2) cleared when it is closed, and (3) checked before closing. This approach can be useful when there are disparate cases in which closes must be performed. However, flag-tracking can increase code complexity and requires diligent compliance by the programmer.
  • Implementation: When closing a resource, set the resource's associated variable to NULL or equivalent value for the given language. Some APIs will ignore this null value without causing errors. For other APIs, this can lead to application crashes or exceptions, which may still be preferable to corrupting an unintended resource such as memory or data.

CWE-415: Double Free

The product calls free() twice on the same memory address.

How to prevent it
  • Architecture and Design: Choose a language that provides automatic memory management.
  • Implementation: Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.
  • Implementation: Use a static analysis tool to find double free instances.

References

Advisories

Fixes and patches

Issue reports

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-4374-p667-p6c8
HTTP/2 rapid reset can cause excessive work in net/http
High Known exploited Also affects stdlib
CVE-2020-0601
Certificate validation bypass on Windows in crypto/x509
High Known exploited Also affects stdlib
RUSTSEC-2026-0382
Distrust compromised intermediate certificates in crypto/x509
Medium Also affects stdlib
GO-2026-6613
HTTP/1 server connection desynchronization after 2xx CONNECT response in net/http
High Also affects stdlib
GO-2026-6609
Lack of limit on size of parsed Range headers in net/http
High Also affects stdlib
GO-2026-6608
Memory limit bypass when parsing MIME headers in net/textproto, mime/multipart
High Also affects stdlib
GO-2026-6607
Reject malformed ECH outer extension references in crypto/tls
High Also affects stdlib
GO-2026-6604
Root.Mkdir(All) can follow junctions out of the root on Windows in os
Critical Also affects stdlib

Credits: hamayanhamayan

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor