Not using setuid anywhere means you'd have to build a slightly more clever exploit, but it's still trivial - just modify some binary you know will run as root "soon".

But... I didn't check, but IIRC the untrusted_app secontext that apps run in is not allowed to open AF_ALG sockets - so you can't directly trigger the vulnerability as a malicious app. Although it might be possible in some roundabout way (requesting some more privileged crypto service to do so).

> If OSS models are equally up to the task, why not find novel vulnerabilities?

To be fair, in the same blog post Anthropic mentioned costs in the tens of thousands of dollars per project looked at it. So it's a big ask to do an experiment that compares. Would love to see it though.

In one of Anthropic's blog post, they describe that that's basically what they did too. They run the agent many times, each time specifying a different file to focus on. [1]

From my experience as a security researcher, manually finding a fishy file and sicking even sonnet 4.5 yields great results for most memory corruption bugs.

No comments otherwise. I don't have a clue as to who that guy is, and I haven't watched the video yet. You might be right overall.

[1] https://red.anthropic.com/2026/mythos-preview/

Edit: looked at the open source model claims - I agree that they suck. Basically all the details are given away in the prompt - not just the file.

The initial batch of publicly disclosed vulnerabilities by Mythos demonstrates that perfectly. None of the bugs themselves are especially interesting or complex, in my opinion. They were found by applying effort to a very large amount of code which included under-scrutinized areas, where bugs hid. Yes, even in projects like Linux and OpenBSD there are many pieces of code that aren't that properly vetted, because of the finite amount of developer/researcher time allotted.

The fact that this effort is much cheaper does indeed change things. But really strong sandboxing solutions, such as gvisor or firecracker, do a really good job of having very little attack surface, all of which is heavily scrutinized.

Until we see more of the bugs that were found, it remains to be seen whether or not the post's premise about sandboxes is correct.

I can believe that it dramatically speeds up finding certain bugs, but I doubt that it can reach a large class of complex vulnerabilities, which in the case of high value targets is probably all that's left.

The PHP interpreter isn't much of an interesting target, since it (usually) doesn't accept user input, even if it does power a significant part of the web.

For that reason, it's much less researched and still has low complexity bugs.

More robust interpreters such as JavaScript's V8 will probably fare much better against data flow only fuzzing. Bugs in V8 tend to combine both data flow and control flow[1].

[1] https://googleprojectzero.blogspot.com/2021/01/in-wild-serie...