As this require an extension doing bad things to be installed and enabled on the server side, I really think this is not a security issue (or a very very low one)

(In reply to Remi Collet from comment #1)
> As this require an extension doing bad things to be installed and enabled on
> the server side, I really think this is not a security issue (or a very very
> low one)

This one got a CVE, and that CVE got a CAT I IAVM: http://iasecontent.disa.mil/stigs/xls/iavm-to-cve%28u%29.xls

But you're right, reading the PHP bug:
...
However currently I am not aware of anything using input filters except for ext/filter and suhosin. Both are not doing anything to the value. But if there is some 3rd party possibly binary only filter extension out there that modifies
value it might result in a remotely exploitable problem for PHP 5.6+.
...

Setting Impact to Low.

Note that this is not really considered security flaw upstream (upstream bug type was changed from Security to Bug).  This can only be a problem if a filter extension attempts to free value passed to it.  No extensions are known to do that.

This issue was introduced upstream in the following commit:

http://git.php.net/?p=php-src.git;a=commitdiff;h=2438490#patch10

Prior to the above change, value was estrndup()ed before being passed to input filters.  Re-introduction of estrndup() is how the issue was fixed upstream:

http://git.php.net/?p=php-src.git;a=commitdiff;h=8d1099a

This change was applied in PHP version 5.6.1:

http://php.net/ChangeLog-5.php#5.6.1

Only PHP 5.6 versions were affected.  No Red Hat product currently ships PHP 5.6.  Older versions included in Red Hat products were not affected.

Statement:

Not vulnerable. This issue did not affect the versions of PHP as shipped with Red Hat Enterprise Linux 5, 6, and 7, and Red Hat Software Collections 1.

Released Fedora versions (up to 20 at the moment) also contain PHP 5.5.  Version 5.6 is only included in Rawhide / upcoming F21, and is already updated to 5.6.1.