Skip to content

Reject IPv4 octets with leading zeros in the ipv4 format check#207

Open
chuenchen309 wants to merge 1 commit into
horejsek:masterfrom
chuenchen309:fix/ipv4-format-reject-leading-zeros
Open

Reject IPv4 octets with leading zeros in the ipv4 format check#207
chuenchen309 wants to merge 1 commit into
horejsek:masterfrom
chuenchen309:fix/ipv4-format-reject-leading-zeros

Conversation

@chuenchen309

Copy link
Copy Markdown

The ipv4 format check accepts IPv4 octets with leading zeros, which are invalid per the JSON Schema spec:

import fastjsonschema
v = fastjsonschema.compile({"type": "string", "format": "ipv4"})
v("01.2.3.4")   # accepted — should be rejected
v("1.2.3.04")   # accepted — should be rejected
v("00.1.2.3")   # accepted — should be rejected

Root cause (fastjsonschema/draft04.py, the ipv4 entry in FORMAT_REGEXS, inherited unchanged by draft06/07/2019): the octet sub-patterns 1?[0-9][0-9]? and [01]?[0-9][0-9]? both match two-digit leading-zero octets like 01, 04, 00.

The official JSON-Schema-Test-Suite optional/format/ipv4.json requires these to be rejected — "invalid leading zeroes, as they are treated as octals" (the comment cites CVE-2021-28918, an octal-parsing SSRF class). The vendored suite doesn't catch it because its only leading-zero case is the 3-digit 087.10.0.1, which the old regex happens to reject; the 2-digit gap was uncovered.

Fix: tighten each octet to 25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9] — a single 0 is still allowed (0.0.0.0 stays valid), but no leading zeros.

Verification (re-runnable from the diff):

  • Before: 01.2.3.4, 1.2.3.04, 00.1.2.3 accepted. After: rejected. 0.0.0.0, 87.10.0.1, 255.255.255.255 still accepted.
  • Added the three leading-zero cases to test_ipv4 in tests/test_format.py — they fail on the current regex and pass with the fix; tests/test_format.py → 45 passed.
  • The full vendored JSON-Schema-Test-Suite across all drafts is unchanged (same pass/xfail/xpass counts before and after — the new regex still passes every case in the suite's ipv4.json, including 087.10.0.1 and 256.256.256.256).

Same vein as the recently merged format-regex fixes (#196 ipv6, #191 date).


Disclosure: This PR was authored by an AI coding agent (Claude Code) running on this account: the AI found the bug, ran the repro, wrote the test, and wrote this description. The human account holder reviews every change and is accountable for it. The verification above is real and re-runnable from the diff. If this isn't the kind of contribution you want, say so and I'll close it.

The `ipv4` format regex used octet sub-patterns `1?[0-9][0-9]?` /
`[01]?[0-9][0-9]?`, which match two-digit leading-zero octets such as `01`,
`04`, `00`. Per the JSON Schema test suite an address like `01.2.3.4` or
`1.2.3.04` is invalid ("invalid leading zeroes, as they are treated as
octals" — cf. CVE-2021-28918), so the validator was accepting malformed input.

Tighten every octet to `25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9]`, which
still allows a single `0` (e.g. `0.0.0.0`) but rejects any leading zero.
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.

1 participant