You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
net/url: insufficient validation of bracketed IPv6 hostnames (CVE-2025-47912) #75678
The Parse function permitted values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.
Thanks to Enze Wang, Jingcheng Yang and Zehui Miao of Tsinghua University for reporting this issue.
changed the title [-]security: fix CVE-2025-47912[/-][+]net/url: insufficient validation of bracketed IPv6 hostnames (CVE-2025-47912)[/+]on Oct 7, 2025
@neild the fix seems to be mistaken in assuming that IPv4-mapped addresses would be forbidden by RFC 3986 when in fact they are not forbidden but explicit part of the grammar in RFC 3986:
As a consequence, added test case…
{"https://[::ffff:192.0.2.1]", false},
…seems to be mistaken and would need to be true. So that's likely a regression from this fix.
Should I create a new bug for it or did you intentionally violate RFC 3986? If so, what was the rationale?
@neild Do you know why this issue was taken up as a security fix? As you can see from the references over the last few weeks it's caused quite a lot of upstream projects to need to make changes after the fact and has likely caused outages.
When a parsing change of this magnitude goes into a minor release, it usually includes a fairly prominent release note, but when it's made in a security patch release they're much less obvious and a much higher standard of forward compatibility can reasonably be expected from developers.
I can see that the CVE is rated as a CVSS3.1 medium, but with the a minimal impact score (confidentiality: low), which itself is questionable: I'm struggling to picture a realistic scenario where an application would need to disallow entry of IPv4 addresses but accept IPv6 addresses from an unauthenticated network user (per the access) or anybody else and choose to enforce that by encasing the address in square brackets.
Activity
neild commentedon Oct 1, 2025
@gopherbot please open backport issues for this security fix
gopherbot commentedon Oct 1, 2025
Backport issue(s) opened: #75712 (for 1.24), #75713 (for 1.25).
Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.
gopherbot commentedon Oct 7, 2025
Change https://go.dev/cl/709838 mentions this issue:
[release-branch.go1.24] net/url: enforce stricter parsing of bracketed IPv6 hostnamesgopherbot commentedon Oct 7, 2025
Change https://go.dev/cl/709857 mentions this issue:
net/url: enforce stricter parsing of bracketed IPv6 hostnamesgopherbot commentedon Oct 7, 2025
Change https://go.dev/cl/709847 mentions this issue:
[release-branch.go1.25] net/url: enforce stricter parsing of bracketed IPv6 hostnames[release-branch.go1.24] net/url: enforce stricter parsing of brackete…
[release-branch.go1.25] net/url: enforce stricter parsing of brackete…
[-]security: fix CVE-2025-47912[/-][+]net/url: insufficient validation of bracketed IPv6 hostnames (CVE-2025-47912)[/+]hartwork commentedon Oct 8, 2025
@neild the fix seems to be mistaken in assuming that IPv4-mapped addresses would be forbidden by RFC 3986 when in fact they are not forbidden but explicit part of the grammar in RFC 3986:
As a consequence, added test case…
…seems to be mistaken and would need to be
true. So that's likely a regression from this fix.Should I create a new bug for it or did you intentionally violate RFC 3986? If so, what was the rationale?
PS: Full disclosure, I'm the author of https://github.com/uriparser/uriparser that implements RFC 3986 in C89.
Best, Sebastian
rolandshoemaker commentedon Oct 8, 2025
@hartwork reading ABNFs is always interesting, but doesn't this show that ls32 can only appear outside of the brackets, not within?
5 remaining items
[release-branch.go1.24] net/url: enforce stricter parsing of brackete…
[release-branch.go1.24] net/url: enforce stricter parsing of brackete…
[release-branch.go1.24] net/url: enforce stricter parsing of brackete…
23325: Upgrade to Go toolchain 1.24.10
[release-branch.go1.25] net/url: enforce stricter parsing of brackete…
Fix square brackets on non-IPv6 addresses in CNI install
Fix square brackets on non-IPv6 addresses in CNI install (#11713)
matthewdupre commentedon Jan 23, 2026
@neild Do you know why this issue was taken up as a security fix? As you can see from the references over the last few weeks it's caused quite a lot of upstream projects to need to make changes after the fact and has likely caused outages.
When a parsing change of this magnitude goes into a minor release, it usually includes a fairly prominent release note, but when it's made in a security patch release they're much less obvious and a much higher standard of forward compatibility can reasonably be expected from developers.
I can see that the CVE is rated as a CVSS3.1 medium, but with the a minimal impact score (confidentiality: low), which itself is questionable: I'm struggling to picture a realistic scenario where an application would need to disallow entry of IPv4 addresses but accept IPv6 addresses from an unauthenticated network user (per the access) or anybody else and choose to enforce that by encasing the address in square brackets.
Fix square brackets on non-IPv6 addresses in CNI install (projectcali…
Fix square brackets on non-IPv6 addresses in CNI install (projectcali…
Fix square brackets on non-IPv6 addresses in CNI install (#11713) (#1…
Fix square brackets on non-IPv6 addresses in CNI install (#11713) (#1…
[release-branch.go1.25] net/url: enforce stricter parsing of brackete…
Enable az:// remote transport (push/fetch/clone)
fedora-cve-triage: tell the fixed-version prompt what it is asking about