By the screenshot, I would say it is a cylindrical projection of a sphere - the top row and bottom row represent just a single point of the sphere

Bug appearing at my Core 2 Duo / Win7 / PHP 5.3.0.

This is really serious. In fact, I’ve just tested if the problem happens for GET passed values and it does. Not all the passed data to a website is treated as a number, so not all websites with the PHP versions and configuration that could fail with this bug will be vulnerable, but definitely there is going to be a huge amount of websites that will do. This is really scaring.

I hope the PHP team patch it soon.

Meanwhile, a possible workaround would be adding this line at the very top of the execution of php website:

if (strpos(str_replace('.', '', serialize($GLOBALS)), '22250738585072011')!==false) die();

This will stop execution if any decimal version of the number were passed as parameter. Note that 222.50738585072011e-310 cause problems too, and any of the other possibilities to write it.

Do you know if there are any other possible ways to write the number that causes trouble too?

Ugh, I managed to hang one of my websites by sticking that number in place of a normal integer parameter.

Apache2 (mod_php) spun at 100% cpu usage.

This suggested workaround works for me. Obviously, it's a limited bandaid, but thanks for suggesting it.

So basically you can hang (almost) any website written in PHP which expose primary keys as GET parameters?

Does this just crash the local process for that request or will it also cause problems for other requests? Anyone able to test this?

Only if it wasn't cast as an integer.

I usually do something like:

    $id = isset($_GET['id']) ? (int) $_GET['id'] : 0;

It has to be treated as a float to be a problem, not as an int.

Only if that parameter is treated as number and not as string. And only if the php version/configuration have that bug. It seems to be a problem when converting from decimal string to number.

In Windows it leaves a zombie resource putting the cpu to 100%, so it doesn't seems to be a nice thing...

It's going to be a very, very small subset of websites running PHP that could be hung...

- Must be one of the PHP 5.3.3 versions with the bug, where very very few web hosts are running such a recent version (5.0, 5.1 and 5.2 branches are much more common)

- Must be a 32-bit version, no bug in 64-bit

- The PHP program must try to use the input as a number

It seems to me that not only the PHP versions 5.3.3 are vulnerable. I have successfully crashed an older version of PHP 5.0.3.