go to bug id or search bugs for
FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE failing in some circumstances
var_dump(filter_var('::ffff:192.168.1.1', FILTER_VALIDATE_IP, FILTER_FLAG_IPV4));
var_dump(filter_var('::ffff:192.168.1.1', FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE));
var_dump(filter_var('0:0:0:0:0:0:0:1', FILTER_VALIDATE_IP, FILTER_FLAG_NO_RES_RANGE));
bool(false) as ::1 does?
Add a Patch
Add a Pull Request
The FILTER_FLAG_NO_RES_RANGE flag only works in a couple of cases (verified
against ext\filter\logical_filters.c from the php 5.3 snapshot of 2012-05-18).
Its missing almost all of the ranges described in
This is also discussed in the following bugreport: https://bugs.php.net/bug.php?
id=47435 but nothing is done with it?
The problem is still present, even on newer version.
Can you fix please ?
FILTER_FLAG_NO_RES_RANGE also has some false positives, it sees 220.127.116.11/21 as a reserved, when it's not. This is happening in PHP 5.5
Any chance we can look into this further? It's been open and verified for over six years (I encountered it on 7.2.8), and has the potential to lead to security issues if code is relying on the accuracy of this filter to e.g. prevent malicious redirects to localhost. There are a _lot_ of ways to write an IPv6 address that equates to ::1, and this filter only appears to catch one of them.
Given how many notations and short-hands there are, the only real way to validate IPv6 is to inet_pton it (which requires IPv6 support) and check the octets.
PHP doesn't do that. It looks at the input string directly. The checks are self-explanatory.
Note that the address must be mostly normalized beforehand (so no 0:0:0:0:0:0:0:1) yet some of the leading zeroes are required (2001:0010:: is excluded but 2001:10:: is not).
Regarding the original report, the first example should return false as the input was not a valid IPv4 address - the dotted notation has no technical significance and is only a convenience for humans to read. It's an IPv6 address that happens to map onto the IPv4 space.
The second example is debatable, considering that the address is IPv6 and not in the IPv6 private range, but I think it's very reasonable to say it should fail because the address explicitly corresponds to an IPv4 address which *is* private.
(Why should the first not be valid IPv4 but the second be treated as such? The IPV4/IPV6 flags test syntax and general usability, and a system that does not support IPv6 is not going to know to support a mapped address. I'm skeptical this format is used much in the wild anyways.)
Third example, of course, should not pass.