This would never have happened with a BDFL

Python is pretty decent. What are you talking about?

The syntax and meaningful spaces are annoying. The dynamic typing is abused to hell in everything including the standard library. It has wacky paradigms like "exceptions instead of conditionals" or having "else" clause for loops.

It lacks decent packaging and by design cannot handle multiple versions of dependencies or perform metadata-only/declarative resolution. To resolve the dependencies of a Python package you need to install it. Many Python packages resolve their dependencies imperatively depending on the current system state. When you need binary dependencies like numpy it gets even worse since libpython doesn't have a stable ABI.

It is one of the most underdesigned languages but it holds a dear place due to being easier to translate from pseudocode to actual implementation. This resulted many academics to pick it up and write advanced math libraries in it.

You'll sleep easier if you think of the graph label as "vulnerability removals"

Deliberately keeping people ignorant doesn't help either

Everyone has evidence of widespread exploit attempts. I totally believe that there are widespread attempts. Where are the compromises?

Why would you do attempts on someone else's server if you haven't been able to exploit a local server yet?

what makes you so sure these would be publicized? what incentive does an adversary have to be loud about it?

I wouldn't be surprised about a timeline like

1: Wiz finds the exploit , begins responsible patching procedure

2: Chainguard,etc gets to know about it, adds some monitoring on top of their patches.

3: OpenAI being happy for the upcoming publicitiy starts an automated run to _count_ vulnerable instances for _marketing_ purposes.

4: Chainguard interprets it as wild exploitation and pulls the trigger early.

lol.

> I wouldn't be surprised

yeah i am not surprised you're not surprised. you seem to have already made up your mind. that said, every single guess you have made here is completely incorrect and not based in facts at all.

literally you have no idea what you're talking about! but don't let that stop you from having an opinion

Any particular compromise might not be published. But 70% of the internet is vulnerable. Even with a low reporting rate, wouldn't you expect to see something?

Surely all the websites that had scheduled downtime for the patch are no longer vulnerable? Would be kind of pointless otherwise.

For all we know, Elias Taylor has been fabricated in order to remove the sense of urgency from as many sysadmins and devops as possible.

I literally know them in person. It's a guy. They have a signal and an email right there, you can message them and talk it's not that deep

Can you tell them that they're acting recklessly here then?

Are they, though? I seriously doubt some sysadmin is going to look at this and say "Maintainers said to patch, but clearly _this guy_ knows better, so I won't."

Besides, he's got a point. The initial PoC that kept popping up on Mastodon (the ones he linked in the post as well) simply didn't work. One of them even posted an updated exploit later that still didn't work, but supposedly meant the vulnerability went from CVSS 10 to CVSS 4.

I know someone who hacked his own site using the exploit and managed to obtain a database dump.

Well, tell him from me, he'll probably regret writing the article when he reaches his thirties.

Doubtful. See the only other post on their blog written on Oct 2,2026 . It argues the exact opposite : https://eliastaylor.com/software-tinderbox/

Which, if true, would at least be kinda funny and would hit institutions that deserve it for having failed to hire trustworthy people that aren't susceptible to that.

So that's a silver lining I guess.

Whoever gets pwned due to this might get naturally out-selected. The system works!!11 Thank you darwin.

If Satan himself proves a theorem, is it nevertheless a true theorem? Claims are either true or they are false. There is no such thing as an evil truth. Where are the breaches?

But don't you understand? The aim wasn't to prevent the breaches that would inevitably happen on day one; it was to prevent the breaches that would happen after that fact. Without mobilising everyone and getting people to patch through an event, we'd be in a far worse position.

The greatest trick that Devil performed was convincing people that he didn't exist, right?

> There is no special caste of people who alone have permission to propose ideas.

I love this

This is from the people who make mandatory protobuf fields "optional".

I just fundamentally disagree with Google on how to evolve data structures. Sloppy open-domain protobuf field presence, enum values, whatever are illusory extension points. Better to have discrete versions of a data structure --- Foo1, Foo2, Foo3, etc., and rigid checking in each one than to have just one "Foo" with optional-everything that changes implicitly over time.

If the TV isn't older than a few years, if it's not checking CRLs, and if it hasn't yet patched itself.

> if it's not checking CRLs

I would be amazed to see a TV that is checking CRLs and keeps the CRLs up to date.

The lengths they would go to prevent you from snooping at them.

And if it's not using its own trust store, which I wouldn't expect from TVs, but would potentially expect with more competent or security focused electronics.

Is it? How? Yes, you can get longjmp to do invalid things, but with an ASLR reset each attempt, can you exploit it?

Not sure how, but from the announcement: Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Maybe just CYA.

Also, CGI PHP skips request cleanup on init failure.

I'm 90% sure CGI can't be exploited this way in default configuration with ASLR and 99% sure if PHP is configured with memory_limit=-1

That said, don't be an idiot and switch to CGI instead of patching. I'm like one of three guys running PHP in CGI mode and I'm vaguely satisfied I have the most resistant configuration.

The reason, BTW, I run PHP in CGI mode is so I can (moral equivalent of) suexec to a locked-down sandboxed environment that limits exploit blast radius. I could do the same with fcgi daemon, but the suexec is stateless, and roundcube doesn't need the performance.

In general, anything stateful or long-lived is just one more thing that can go wrong. One reason why the trend of turning everything into a persistent daemon drives me nuts.

It's going to be hilarious if I'm not vulnerable because I'm running PHP like it's 1995 via CGI and so get a brand new process per request and break ASLR infoleaks by side effect.