> I am very curious to hear why you thought it was overblown.

Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.

▲

cowlevel 3 hours ago | parent [-]

Can you? Initial suggestions to block multipart content-types were a red herring.

▲

1718627440 3 hours ago | parent [-]

In theory yes. In practice, I don't know, I hope my provider patched it properly.

▲

cowlevel 2 hours ago | parent [-]

What specific configuration would you recommend to block the vulnerability without actually patching it?

▲

1718627440 2 hours ago | parent [-]

None. Like I wrote "I don't know, I hope my provider patched it properly."

▲

cowlevel 2 hours ago | parent [-]

Then why did you say

> you can prevent PHP being executed on malicious data by configuring the webserver.

▲

1718627440 an hour ago | parent | next [-]

You can do this. I don't know how, and I don't think it's a feasible use of my time, to find out how. It's obviously computable on a Turing machine, because they were able to patch PHP.

▲

cowlevel 31 minutes ago | parent [-]

So it was useless advice? You presented it as if anyone not following the advice is incompetent, now you suggest nobody knows how to do it. Is everyone incompetent?

	▲	1718627440 7 minutes ago \| parent [-]
		What? I never claimed it was "advice"? I explained how other people could have arrived at the conclusion that there can be worse things than a single language interpreter being vulnerable to a unconditional RCE. Were you answering to the wrong comment?

▲

jstanley an hour ago | parent | prev [-]

Configure your webserver to not execute PHP code.