minitech

- but anyone who deploys thousands of lines of vibe-coded C that implements a transforming HTTP proxy from scratch instead of a patch (hey, it “might even be safer than the patch”!) deserves what they get

edit: shocker https://news.ycombinator.com/item?id=50199456

Comment · 4 days ago

So was “months” a typo for “4 days” or what?

Comment · 4 days ago

Which companies? The earliest claim of an exploit attempt in the wild I had heard was October 17th, and that was “extant”, not “rampant”.

I don’t suppose you’re thinking of when the issue was discovered? That was August 1st, according to https://calif.io/php2shell/#the-discovery.

Comment · 5 days ago

Linking a reasonable way to create a necessary RAM disk rootlessly with namespaces to kernel exploits that involve namespaces seems like a massive reach.

Comment · 5 days ago

Any comment now that it’s been done? Under somewhat more difficult conditions than many real-world deployments, with only a chance at $2k at stake, within about 4 hours (https://news.ycombinator.com/item?id=50233841) of becoming vulnerable (https://news.ycombinator.com/item?id=50234528)?

Comment · 9 days ago

It’d be redundant for me to write up the whole explanation here, but the short version is that every process has its own memory space, provided in a clean state by the OS, that other processes can’t read from or write to, regardless of pointer values. The same pointer value in two processes doesn’t refer to the same memory unless there’s specific coordination. Keywords you can use to read more about the long version on previous Wikipedia link.

> Or is that always formatted by the next process' vm?

So yes, that’s sort of how it is.

Comment · 9 days ago

I forget making the claim that JavaScript was a well-thought-out language. But yes, I can see how discussing programming language and library design/implementation, as or with the type of person who trots out trite thought-terminating clichés, could be a waste of time.

Comment · 9 days ago

> or if it's some address that's truly free and could be picked up by another process

This isn’t a thing; virtual memory (https://en.wikipedia.org/wiki/Virtual_memory) is very old, and Linux has never not used it. It takes a separate vulnerability (a “local privilege escalation”) to do what you’re getting at. (However, those are plentiful, and arbitrary malicious code with PHP process privileges is often already catastrophic for a web service.)

That said,

> OP seems to be implying that there's no way the UAF bug could be used to run arbitrary code with higher privileges than PHP itself

No, nowhere does the article imply that at all.

Comment · 10 days ago

Blog post from a week ago with no “CRITICAL”, any reason to expect it not to look like the last one (https://nodejs.org/en/blog/vulnerability/july-2026-security-...)?

Comment · 10 days ago

Much of Node’s standard library is written in JavaScript, which can’t go on to exploit V8 vulnerabilities even given similar types of bugs, so I wouldn’t say it’s in a similar place. Not as familiar with Java, but I expect PHP is in a class of its own here.

Comment · 10 days ago

Yes? How did you think Cloudflare and other WAFs worked?

Comment · 10 days ago

> PHP doesn’t have any more than others.

Yeah it does. Part of it is being a popular starter language before people know what they’re doing, but a lot of it is legitimately terrible language[1] and API design, especially in older versions. It also has CVE-2026-109618, a type of vulnerability many languages aren’t even capable of having (since it wouldn’t be part of the language, and the library that implemented the equivalent would only be present when necessary and usually not written in C - with some exceptions).

[1] People have already covered this in depth, but here’s a lesser-mentioned taste: https://web.archive.org/web/20261017012819/https://www.php.n... (one section, btw)