Nobody ever was. The big argument against needing safer languages was basically "but if you're an expert at C/C++/whatever, your code is pretty much safe". And these are usually the people who don't run extensive fuzzing and test suites.

it is also quite difficult to make a house safe if there are millions of people willing to breach it.

The offender side evolved, the defender needs to evolve too and that will be very, very expensive but much cheaper than not fixing the problems.

We knew we weren't, deep down. Some people did better than others at writing more secure of course. It was just about good enough in a world where – compared to today – it took much more time, skill and effort to find bad bugs.

The mistake is to think that the 'magical' LLMs don't write buggy code and that there isn't some tradeoff in using them. There are always tradeoffs in engineering.

later

And, security is always relative to the adversary and landscape, which has massively changed recently.

Depends on use-case. As a reverse proxy I might use Caddy, for no fuss https. I prefer Apache over nginx for modules that are not available in the later, or they are not for free.

Did it manage to produce a PoC for RCE? Apparently Redhat claimed there's a RCE, while Wiz said they don't have one.

http2 race??

What exactly is the issue and does nginx have it

I was prepared to disagree with you, but I agree: I'd say there's a strong norm of not calling things RCE unless you can actually demonstrate RCE, or at least have a clean pathway to demonstrating it (e.g. a full write-what-where).

It's perfectly sufficient to have a CVE for just memory corruption, so the "RCE" framing here feels overstated. Particularly when an LLM should easily prove RCE out if it is in fact present.

I don't know the backstory here, but there's a long and colorful history of vendors and other parties guessing that some contrived memory corruption bug isn't exploitable and then being proven wrong, so the industry now more or less defaults to the assumption that it's exploitable.

Let me remind you that in response to the PHP bug, one of the front-page HN posts was a guy saying it's probably not exploitable and another offering Bitcoin to anyone who pops their server... with predictable results.

People can be pretty creative with exploitation primitives, and LLMs now replicate that at a scale. And yep, if you found a use-after-free that can be triggered remotely in PHP under some reasonable assumptions, you should probably treat it as a security bug.

If you can corrupt memory in a controllable way, you can get a computer to do just about anything that process has rights to. Possibly even the kernel, if you can get at some shared memory.

RedHat claims there's a working RCE:

> (...) public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled. Successful exploitation allows an attacker to execute arbitrary commands, gain full control of the server process, and access or modify sensitive information.

https://access.redhat.com/security/cve/cve-2026-119618

Discovered independently by Anthropic (Oct 26) and Google (Nov 3), so I'm compelled to believe it: https://httpd.apache.org/security/vulnerabilities_24

But maybe someone will post another HN challenge like with the PHP thing?

Yes, this is slop, extruded from reading the patch and the official announcement, which is at https://httpd.apache.org/security/vulnerabilities_24.html#CV...

[dead]

Well I know someone who will get bitten - a couple of years I did some work (because security said so) to make sure we always pulled latest Apache when building our Docker container. Someone ripped that change out not long ago because it was too hard to maintain the Debian repo config changes needed to pull it in, and as a result they'll probably get stung by having a version right in the meaty part of that range.

I'm guessing you missed out on Heartbleed too :P At work we managed to upgrade to a vulnerable version 1 month before that came out .... ugh

I run apache with prefork on my personal sites. Still works. No idea if it supports http/2.

I don't know, but Claude is fixing that too! (doubt that makes it safer either...)