Because the libc crypt() function (and also the PHP port for windows) is not thread safe there exists a race condition that can be exploited on multi threaded systems. When for example two threads are trying to validate passwords through crypt() at the same time they are using the same internal memory area which can result in both crypt() actions returning invalid results or the result of the one operation can overwrite the result of the other. It is obvious that in this case a thread using a wrong password will return the correct crypted password if during the same time another thread calls crypt() on the correct password. In this case the application will usually login the user that used the wrong password. (However the thread race is hard to win from remote)

Because Suhosin changes the default crypt() method to the blowfish implementation it comes with, which is thread safe by default Suhosin users were safe from this vulnerability before this update, unless they provided their own salt when they called crypt().

Note: In PHP 5.2.1 the PHP developers silently closed that hole for UNIX systems that support crypt_r(). It is however very likely that they did not realise the security implications, because they have no protection for systems that do not have crypt_r(), they did not merge it to PHP 4 and they also did not fix the windows implementation.