Comment by SSLy

20 hours ago

if the attacks are live then PHP should release the fix NOW.

The reason we (used to) have responsible disclosure timelines is so that the information & software to fix vulnerabilities can be assessed, organised, written up. Builds could get built, attackers and defenders find out at once. But crucially, defenders could use the normal channels to fix their installations and be sure they'd covered themselves.

When a PoC drops before that timeline is up (like now!) the attackers get a head start because they have less work to do - just figure out how to use it to their payload, start spraying it out.

Meanwhile maintainers don't want release an incomplete or misunderstood fix. Otherwise they'd risk people updating and believing that they're safe when they're not. Even a fragment of misinformation from an official channel will spread like wildfire. So when you demand fixes NOW you're demanding something that may not be completely understood.

So (I'm sure we'll find out but) I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job, and not risk us having to come back tomorrow for a fix to the fix.

LLMs gives attackers the advantage for a while, and it means we'll have to tighten the secrecy around even the rumour of a vulnerability.

  • > Meanwhile maintainers don't want release an incomplete or misunderstood fix.

    > I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job

    I'll be surprised and kind of upset if the fix wasn't already done when they announced the bug and the sub-24-hour release time.

  • No, ‘responsible disclosure’ was and always has been a response from vendors not patching their software or building secure software to start with, and trying to frame researchers as responsible for their shoddy work.

Or you release a "mitigation" immediately (turn off feature X usually) and then release the patch.

  • As far as I can tell, there is no proper mitigation beyond patching. Unless we count turning off your service as a mitigation. Cloudflare is currently busy playing whack-a-mole with new vectors so it’s probably not feasible to properly mitigate it on the edge either.

    • Improper mitigation is still better than literally nothing - a simple "this may not cover everything, but block POST at the edge might help" can go a long way.