Opus 4.6 turned the vulnerabilities it had found in Mozilla's Firefox 147 JavaScript engine—all patched in Firefox 148—into JavaScript shell exploits only two times out of several hundred attempts. We re-ran this experiment as a benchmark for Mythos Preview, which developed working exploits 181 times, and achieved register control on 29 more.

The crux of the vulnerability is that Starlette accepts invalid host header values that cause authenticating apps that use Starlette's request.url object to approve unauthorized access requests.

The important point is that this is not ordinary file writing. It never calls write() on /usr/bin/su. Instead, it appears to rely on a kernel bug/primitive involving spliced file pages and the crypto API to get controlled bytes placed into the page-cache representation of a privileged executable.

projection tends to seize on, and exaggerate, an element that does exist, albeit subtly, in the other person.

Anthropic researchers said this was not an isolated incident, and that Claude had a tendency to “bulk-email media and law-enforcement figures to surface evidence of wrongdoing.”

this propaganda plays on psychological structure and if you're able to fish into that you're able to exploit those irrational Tendencies

To elaborate, a successful live exploit must compromise the unexposed next set of private keysfrom the public-keys declared in the latest rotation

Here is a simplified example of a malicious .gitlab-ci.yml

Most people seem to follow one of two strategies - and these strategies come under the umbrella of tree-traversal algorithms in computer science.

WhyGeneral infrastructure simply takes time to build. You have to carefully design interfaces, write documentation and tests, and make sure that your systems will handle load. All of that is rival with experimentation, and not just because it takes time to build: it also makes the system much more rigid.Once you have lots of users with lots of use cases, it’s more difficult to change anything or to pursue radical experiments. You’ve got to make sure you don’t break things for people or else carefully communicate and manage change.Those same varied users simply consume a great deal of time day-to-day: a fault which occurs for 1% of people will present no real problem in a small prototype, but it’ll be high-priority when you have 100k users.Once this playbook becomes the primary goal, your incentives change: your goal will naturally become making the graphs go up, rather than answering fundamental questions about your system.

Oops, I think that one might even be exploitable… I think I’m going to stop here. This needs a structured effort, not spending ten minutes every now and then. As I said, the codebase isn’t bad. But there are obvious issues that shouldn’t have been there. As always, spotting the issues is the easy part – proving that they are exploitable is far harder. I’m not going to spend time on that right now, so let’s just file these under “minor quality issues” rather than “security problems.”