Skip to content

net/url: insufficient validation of bracketed IPv6 hostnames (CVE-2025-47912) #75678

Closed

Description

@neild

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.

This is CVE-2025-47912 and Go issue https://go.dev/issue/75678.


This is a PRIVATE issue for CVE-2025-47912, tracked in http://b/436581568 and fixed by https://go-internal-review.git.corp.google.com/c/go/+/2680.

/cc @golang/security and @golang/release

Activity

  1. added this to the Go1.26 milestone on Sep 30, 2025
  2. neild commented on Oct 1, 2025

    @neild
    ContributorAuthor

    @gopherbot please open backport issues for this security fix

  3. gopherbot commented on Oct 1, 2025

    @gopherbot
    Contributor

    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.

  4. added
    NeedsFixThe path to resolution is known, but the work has not been done.
    on Oct 2, 2025
  5. gopherbot commented on Oct 7, 2025

    @gopherbot
    Contributor

    Change https://go.dev/cl/709838 mentions this issue: [release-branch.go1.24] net/url: enforce stricter parsing of bracketed IPv6 hostnames

  6. gopherbot commented on Oct 7, 2025

    @gopherbot
    Contributor

    Change https://go.dev/cl/709857 mentions this issue: net/url: enforce stricter parsing of bracketed IPv6 hostnames

  7. gopherbot commented on Oct 7, 2025

    @gopherbot
    Contributor

    Change https://go.dev/cl/709847 mentions this issue: [release-branch.go1.25] net/url: enforce stricter parsing of bracketed IPv6 hostnames

  8. added 2 commits that reference this issue on Oct 7, 2025
    d6d2f7b
    9fd3ac8
  9. changed the title [-]security: fix CVE-2025-47912[/-] [+]net/url: insufficient validation of bracketed IPv6 hostnames (CVE-2025-47912)[/+] on Oct 7, 2025
  10. hartwork commented on Oct 8, 2025

    @hartwork

    @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:

    Image

    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?

    PS: Full disclosure, I'm the author of https://github.com/uriparser/uriparser that implements RFC 3986 in C89.

    Best, Sebastian

  11. rolandshoemaker commented on Oct 8, 2025

    @rolandshoemaker
    Member

    @hartwork reading ABNFs is always interesting, but doesn't this show that ls32 can only appear outside of the brackets, not within?

  12. 5 remaining items

  13. added 3 commits that reference this issue on Oct 9, 2025
    854023c
    1cd3cd2
    b2230f5
  14. matthewdupre commented on Jan 23, 2026

    @matthewdupre

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsFixThe path to resolution is known, but the work has not been done.Securityrelease-blocker

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions