Jessica 👾

"When did the bug start?" Really cool feature for causality analysis from my colleagues. antithesis.com/blog/2026/caus…

Remember that bug that cost you three days? Or was it a week? What if we could just tell you why it was happening? We’re not talking about just handing you a perfect repro, we’re talking about actually pointing at an event and saying “Here, look at this. This moment is making it virtually certain the bug is going to happen.” How much time would that have saved you? Causality analysis is available in Antithesis as of today. Read all about it below.

Touched grass over the weekend

NYC folks, @AntithesisHQ is hosting a meetup in the city on the 12th of May. If you're around and want to spend some time with your heroes... We have an incredible line-up of speakers: - Kyle Kingsbury - Sesh Nala - Murat Demirbas Come join us and other awesome folks who care about correctness. Luma invite in the comments below :D

Libghostty can now be used to fuzz TUIs, thanks to @owickstrom + @AntithesisHQ. They already found bugs in multiple including btop. I always imagined libghostty would be useful for testing TUIs, super happy to see this is both practical and valuable. wickstrom.tech/2026-04-30-bom… This is another example of where speed matters! "Why does Ghostty need to be so fast?" Well, if you're running hundreds or thousands of unit tests that each use a clean in-memory terminal, you want that to be fast. If you're fuzz testing and trying to push an unlimited amount of data through a terminal, you want that terminal to be fast. So many people got hung up on "why does my terminal _GUI_ need to be fast" without connecting one more dot and realizing the GUI is only fast if the core is fast, and the core being fast unlocks a hell of a lot more. Like this.

New blog post: "The Bombadil Terminal Experiment" wickstrom.tech/2026-04-30-bom…

Hegel is an open source property-based testing library for every language, based on, and brought to you by some of the folks behind Hypothesis -- the most widely-used, and arguably the best, property-based testing tool in the world today. We're serious when we say "every language": we released Hegel-rust a couple of weeks ago, and Hegel-go is on available on github today.

Say hello to agentOS (beta) A portable open-source OS built just for agents. Powered by WASM & V8 isolates. 🔗 Embedded in your backend ⚡ ~6ms coldstarts, 32x cheaper than sbxs 📁 Mount anything as a file system (S3, SQLite, …) 🥧 Use Pi, Claude Code/Codex/Amp/OpenCode soon

If you're at @QCon London, and wondering how you'll keep up with all the code your agents are writing while you're there, Lawrie Green has an answer for you. 1705H in the Westminster room on the 4th floor. Royals not included.

psst!! Snouty and the @AntithesisHQ team are working hard to get your copies of DDIA sent out 📬

Someone asked what BugBash is about. This is what BugBash is about. Early bird pricing ends today.

An incredibly awful security vulnerability just got revealed in MongoDB. So much that it got named after HeartBleed. MongoBleed is a vulnerability affecting all MongoDB versions from 2017 to... today. The exploit is simple. It's a buffer over read bug due to compression. Here's how it works 👇 Clients can send compressed requests to MongoDB. The client helpfully includes the uncompressed size of the message so the server knows exactly how much memory to allocate when decompressing. The server allocates a memory buffer with the given space. Due to how memory management and garbage collection in programs work, this allocated memory may already contain sensitive information that was copied earlier and is considered garbage now (eg because it's unreferenced). This is technically fine - every computer program works that way because it is assumed that whatever unclaimed memory exists there will be overwritten. Unfortunately that’s exactly where the bug lies. 🙃 The server stupidly trusts the client’s provided uncompressed size. When a malicious client lies about the uncompressed size - e.g the actual decompressed size is 100 bytes, but the client says its 1MB - Mongo will treat the full 1MB block as the message. It will unload the 100 byte decompressed msg into the buffer, yet treat the full 1MB block as the msg. This is extremely problematic if you can get the server to return back parts of the 1MB block, because it could contain data you may not have access to. That is exactly what the exploit does - it sends a badly-formatted BSON message. The server fails to parse it, and "helpfully" returns an error message containing the invalid message. The invalid message can be that whole 1MB block of foreign data. To understand the exploit a bit better, you need to understand the MongoDB protocol. • Mongo also uses its own TCP wire format (i.e doesn't use HTTP, gRPC or the like). • BSON is Mongo's message format passed within the TCP wire format. BSON is basically JSON in binary form • Commands in Mongo don't have particular endpoints or RPC names - rather, they are simply JSON-like messages. The action is inferred from the first key of the JSON. For example, an insert request looks like this: `{ "insert": "users", "documents": [ { "name": "alice", "age": 30 } ] }` Every request to the server is therefore decoded into the BSON format as it’s parsed. Critically, BSON parsing of field names (which are strings) work by parsing the field until you hit a null terminator byte (0x00). It works exactly like strings in C, which have their own rich history of vulnerabilities. We can now tie things together: 1. The client lies to the the server that its request has a big uncompressed size, so the server allocates a large block of memory 2. The client sends an invalid BSON with a field which does NOT contain the null terminator (0x00) 3. The server naively tries to parse the BSON field in that allocated block until it hits the first null byte. The first null byte is encountered in some foreign data since the BSON literally doesn't have it 4. The server realizes this is a completely invalid BSON message so it responds with an error. 5. The error response contains the invalid BSON "field". Critically, the server parsed garbage data from the heap in step 3), so it returns that data in the response. Congrats. If the garbage contains passwords or other sensitive info, you’ve hacked MongoDB! Hackers exploit this by sending many malicious requests per second and then attempting to reconstruct the pieces of garbage they received back. What’s critical about this vulnerability is that it works on ANY internet-accessible unpatched instance of MongoDB. 💀 You don’t need to authenticate with the server, because this whole request/response parsing cycle happens before the server can even authenticate. Obviously you can’t authenticate a malformed request which doesn’t contain credentials - so that path of the code never gets executed. The server simply responds with an error response. It just so happens that this error response can contain sensitive data. 🤷‍♂️ Merry Christmas

Reading a great post about steps on designing diy dst written by @PierreZ on my new kobo! #Cheerleading

merry Christmas to me

So I did an interview about how I hire @tryramp. Deeply personal to me because it’s not the product that makes a company succeed, it’s the people behind it. Thank you Eleanor and Emma for taking the time to listen to me ramble! @eleanormorgan/note/p-181903444" target="_blank" rel="nofollow noopener">substack.com/@eleanormorgan…

when your lead investor is also the sponsor of the annual Advents of Code challenges... #themoreyouknow #janestreet

@Shark_Academia this is one of the reasons why we're super bullish on @AntithesisHQ as a way to build confidence in the code so we can move faster