Skip to content

fix: reject invalid dotted-decimal in hostname_rfc1123 validation - #1607

Open
deepakganesh78 wants to merge 1 commit into
go-playground:masterfrom
deepakganesh78:fix/issue1561-hostname-ipv4-octet
Open

fix: reject invalid dotted-decimal in hostname_rfc1123 validation#1607
deepakganesh78 wants to merge 1 commit into
go-playground:masterfrom
deepakganesh78:fix/issue1561-hostname-ipv4-octet

Conversation

@deepakganesh78

@deepakganesh78 deepakganesh78 commented Aug 1, 2026

Copy link
Copy Markdown

Fixes #1561

Problem

hostname_rfc1123 accepted strings like 277.168.0.1 as valid hostnames. Per RFC 1123 §2.1, a valid hostname can never have the dotted-decimal form #.#.#.# since the highest-level component label must be alphabetic.

Root Cause

The hostnameRegexRFC1123 regex allows all-digit labels, so a four-part all-numeric string like 277.168.0.1 passes the regex even though it is neither a valid IPv4 address nor a legitimate hostname.

Fix

After the regex matches, a new looksLikeIPv4 helper checks whether the string has exactly four dot-separated all-numeric parts (the dotted-decimal form). Only in that case is net.ParseIP called; invalid addresses are rejected. The guard is deliberately narrow:

Input looksLikeIPv4 Result Rationale
192.168.0.1 true accepted Valid IPv4
0.0.0.0 true accepted Valid IPv4
255.255.255.255 true accepted Valid IPv4
277.168.0.1 true rejected Octet 277 out of range
999.999.999.999 true rejected All octets out of range
1.2.3.256 true rejected Octet 256 out of range
3com.com false accepted Contains letters, not dotted-decimal
1and1.com false accepted Contains letters
7-eleven.com false accepted Contains letters and hyphens
1234 false accepted Single all-numeric label (no dots, not 4-part) — valid per RFC 1123
12345 false accepted Same as above
1.2.3 false accepted 3 numeric parts, not dotted-decimal form
1.2.3.4.5 false accepted 5 numeric parts, not dotted-decimal form

This avoids calling net.ParseIP for the vast majority of inputs and does not affect fqdn, hostname_port, or other validators (fqdn already requires an alphabetic TLD; hostname_port calls hostnameRegexRFC1123 on the host part only after stripping the port).

Validation

  • go test ./... — all 24 packages pass
  • go vet ./... — clean
  • gofmt -l — clean on touched files

Compatibility

No breaking change. Valid IPv4 addresses continue to be accepted. Only invalid four-part dotted-decimal strings that were incorrectly accepted are now rejected.

@deepakganesh78
deepakganesh78 requested a review from a team as a code owner August 1, 2026 16:51
Per RFC 1123 §2.1, a valid hostname can never have the dotted-decimal
form #.#.#.# since the highest-level component label must be alphabetic.
The hostname_rfc1123 validator accepted strings like '277.168.0.1' because
the regex allows all-digit labels. Now, when the input consists entirely
of digits and dots (dotted-decimal form), it is validated as an IPv4
address via net.ParseIP and rejected if invalid.

Fixes go-playground#1561

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@deepakganesh78
deepakganesh78 force-pushed the fix/issue1561-hostname-ipv4-octet branch from 9ace67d to 859cb5a Compare August 1, 2026 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: hostname_rfc1123 validation does not enforce IPv4 octet check

1 participant