Attackers taking notes, garbage hidden in JSON, sandbox escapes and Ruby back in the news for the wrong reasons.

This is a big report, and I think it's worth taking the time to read it. We spend a lot of time discussing whether AI can find vulnerabilities. Meanwhile, the attackers described here are using it to do much more: understand applications, use stolen credentials, write tools, and steal data.

One detail I found particularly interesting is how they keep notes and reuse what they learn. They have agents working on different tasks, testing exploits in labs, and continuing the work while the humans are away. A lot of the ideas we discuss for building better AppSec workflows are already being used by attackers.

And then there are the attackers stealing AI API keys and using them to keep hacking at the victim's expense. Getting compromised and paying for their next attack. Ouch!

There is plenty to think about here. Even without finding a new vulnerability, how much more damage can someone do when understanding an unfamiliar application takes a lot less time? Countering misuse of AI: September 2026 / Anthropic.

I know the Tanto team pretty well, and Marcio, the author, is an all-around great guy. There are two details I really enjoyed in this write-up.

First, their padding oracle lets them forge encrypted data, but the fixed IV gets in the way. Their solution leaves a block of garbage they cannot control, so they hide it inside a JSON key and add the field they actually want. The parser happily ignores the mangled key. It reminds me of another trick Luke Jahnke showed me: Ruby's JSON parser can accept comments! Knowing what a parser accepts can give you somewhere to put the bytes you cannot control.

Then there is the timing oracle. Even when the error messages are the same, the two failures take different paths through the code. They send two requests in the same packet and look at which response comes back first. With enough repetitions, they can spot the difference despite the network noise. Plenty to learn here about cryptography, parsing, and why hiding an error does not fix the bug.
From Padding Oracle to Shell: Unauthenticated RCE in Telerik UI for ASP.NET AJAX.

Sandbox escapes. SO HOT RIGHT NOW.

This time, it's Goja, a JavaScript engine written in Go. You would expect Go's memory safety to help here, but the code uses unsafe. A mistake with an array offset gives the researchers a way to write outside the buffer. From there, they build a sandbox escape and get code execution in Zendesk and Nuclei. Plenty to learn about Go internals along the way.

The Nuclei part is particularly fun: the JavaScript in the template's init section ran before the signature was checked. So Nuclei tells you it skipped the unsigned template, but your code has already run. A great reminder that everything happening before signature verification is great attack surface. Out of Bounds, Out of Sandbox: RCE in Go JavaScript Engine.

Apparently Ruby is cool again. I wish it was for a different reason!

This story is crazy. The researchers describe agents using RubyDoc’s documentation builds to execute code, fetch public information, and publish the results back into gems. But the detail that really caught my attention is the attempt to steal API keys through a caching bug. After someone signed in with an older RubyGems client, the CDN could serve their API key to another person hitting the same endpoint. No credentials needed, just the right cache node at the right time.

The packages show attempts to exploit this before the bug was independently reported and fixed. But we still don't know whether they managed to steal any keys. RubyGems found no evidence of abuse in the logs it retained, but those logs cover only a small part of the time the bug existed. OpenAI agents carried out an undisclosed attack on RubyGems.