Brian Moon had a problem - one of his cron jobs was lasting for much longer (hours!) than it should have been. He tweaked, tested and debugged the script and finally came down to a call to in_array, something he comments on as being "quite slow".

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

On the PHP Security Blog today, this note has been posted, a notification that a critical vulnerability has finally been fixed - the unset() issue.

Because there are meanwhile a lot of rumours about this vulnerability in the underground and because the PHP 4.4.3 release announcement does not mention this critical hole at all I wrote up a little article about it, which you can read here.

The article (from Hardened PHP) describes the issue - a problem in the hash tables of the Zend Engine, specifically the zend_hash_del_key_or_index function. The logic contained inside the function can find the wrong "bucket" of information and remove it. He also includes PHP code examples that show the issue in action.

To be protected, it's recommended to update to the latest versions of PHP that have been released - 4.4.3 and 5.1.4.