See $URL for a more elaborate explanation, I'll update this with more detail later.
Specially crafted POST parameters can be used to cause hash table operations with a time complexity of O(n^2), causing a Denial of Service.
PHP is working around the issue by limiting the number of input parameters allowed. According to Rasmus Lerdorf, implementing a proper fix will take time. 
The workaround commits are:
These are scheduled for the next 5.3 and 5.4 releases.
 Stated in 28C3 talk: http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html
Until upstream implements the fix, let's bump to a version with the parameter count limit workaround when available.
Secunia advisory says is fixed in git repo https://secunia.com/advisories/47404/
(In reply to comment #2)
> Secunia advisory says is fixed in git repo
Please read my comments. This is a workaround, not a fix.
Core PHP developers and others label max_input_vars as a fix for this issue.
However, I agree with Alex that this is more a workaround than a fix. If an application parse an input string and creates a hash table based on the parsed data, the application would still be vulnerable.
An example of a vulnerable application is one that accepts JSON data through HTTP POST.
Also worth mentioning that those who have dev-php/suhosin installed will have the same protection as the mentioned workaround through suhosin.request.max_vars.
PHP before 5.3.9 computes hash values for form parameters without
restricting the ability to trigger hash collisions predictably, which allows
remote attackers to cause a denial of service (CPU consumption) by sending
many crafted parameters.
PHP 5.3.9 containing the mentioned workaround has been released.
(In reply to comment #7)
> PHP 5.3.9 containing the mentioned workaround has been released.
Great, thanks. Shall we call arches to stabilize now via this bug?
I would wait with dealing with this bug until PHP has released a proper fix.
5.3.9 should be stabilised soon anyway due to bug 384301.
(In reply to comment #9)
> I would wait with dealing with this bug until PHP has released a proper fix.
> 5.3.9 should be stabilised soon anyway due to bug 384301.
Ok, thanks. We'll get the workaround via stabilization in that bug, and hold this open for a more complete fix.
Fixed in 5.3.9
Added to existing glsa request
dev-lang/php-5.3.9 is now stable in the tree. About time we removed, or masked <dev-lang/php-5.3.9 ?
(In reply to comment #13)
> dev-lang/php-5.3.9 is now stable in the tree. About time we removed, or masked
> <dev-lang/php-5.3.9 ?
Great idea! Removed now.
This issue was resolved and addressed in
GLSA 201209-03 at http://security.gentoo.org/glsa/glsa-201209-03.xml
by GLSA coordinator Sean Amoss (ackle).