We're honored to be named to the #Disruptors60 class of 2026 curated by @GreenfieldVC Partners at
@TechCrunch Disrupt, alongside the top AI companies.
Thank you to our team, customers, and partners.
Proud to represent @Accomplish_ai at AI Dev TLV Conference on December 21! π
Iβll share some cool things weβve learned about how real-world restrictions shape AI agent behavior.
Hope to see you there!
https://t.co/vifoOHwvNt
We're honored to be named to the #Disruptors60 class of 2026 curated by @GreenfieldVC Partners at
@TechCrunch Disrupt, alongside the top AI companies.
Thank you to our team, customers, and partners.
Exciting news!
Our paper has been accepted to NeurIPS 2026 this year in the AI Safety and Security track.
Meet the @Accomplish_ai research team at Sydney!
Very nice find from the Accomplish security team. They found a way to read other customers' data on Cloudflare Containers.
When one container was deleted, its disk space was handed to the next container without being wiped first. So a new container could sometimes read what the previous one had left behind, including full databases.
Very cool work!
https://t.co/ydvQvGSEdp
What's worse than escaping a sandbox and reading the host's files?
Escaping Cloudflare's, and reading other customers' files.
How did that happen? Cloudflare Containers' disk is thin-provisioned, which means the host keeps a shared pool of storage for every container on the machine, and attaches it lazily in 64 KB chunks, instead of provisioning it all upfront.
When we tried reading a chunk of unallocated disk space in a container, we got zeros, which is to be expected.
But we noticed something strange: the chunks that we already wrote to were full of bytes we didn't write.
Turns out a write is what makes the thin provisioner allocate the chunk, and Cloudflare wasn't zeroing it on the way in, so the rest of the chunk still held leftover data from the previous customers' containers that happened to run the same machine.
By writing 4 KB to every chunk of the disk. The other 60 KB of each chunk were instantly filled with other customers' files: .env, credential files, .pem keys, SQLite databases, Chromium cookies and localStorage.
I've disclosed vulnerabilities to many vendors over the years, but working with Cloudflare was something else. Putting aside the speedy triage, mitigation, and generous bounty, they have a unique and earnest engineering culture of transparency.
Which lead to us collaborating and writing the full postmortem together:
https://t.co/xC42aqqtDm
these guys are
c r a c k e d
they escaped https://t.co/7XB0X7YlMK's VMs once (already talked about it)
we fixed in less than a few hours
they got a bounty
and we learned so much
now everyone can be secure
Our research team found a disk isolation bug in Cloudflare Containers, the platform underneath Cloudflare Sandboxes, that exposed other customers' files from inside a sandbox, including credential files and browser cookie stores.
Reported Sept 4, fixed fast, disclosed jointly with @Cloudflare today.
Security researchers at Accomplish identified a Cloudflare Containers vulnerability involving residual disk data. We've detailed the issue, investigation, and fix in our latest post. The vulnerability is fully remediated, and no customer data was compromised. https://t.co/M5pUb2mELH
Shabbat Shalom.
@Docker has issued a critical level (!!) CVE-2026-77179, reported by @Accomplish_ai researcher @orenyomtov.
If you use Docker Sandboxes, run sbx --version. Make sure youβre running 0.42.0 or later.
If you use Docker Desktop, you want 4.88.0 or later
Docker Desktop and Docker Sandboxes are both affected. Docker Desktop is only affected if Docker VMM is turned on in Settings.
Itβs a good thing we found it now, because Docker VMM is scheduled to become the default for Docker Desktop at the end of October 2026!
The escape is in Docker's hypervisor for Mac: a container gets complete read and write access to the host filesystem.
Read the full details of this escape in our blog:
https://t.co/PRj8xoE5Fq
This is our third sandbox escape writeup, and after Claude Code and Cursor, it's OpenAI's Codex this time!
This one is especially cool, for two reasons:
1. One of the escapes is from the open source codex cli. As an open source project, we found it to be generally much more secure than its competition.
2. The second escape is in the rust-based closed source - and it leverages a sophisticated heap attack.
Kudos to @OpenAIDevs@OpenAI for fixing this super quickly and to @Accomplish_ai researcher @orenyomtov for finding it.
Both fixed now, and here are all of the details:
π¨ SANDBOX ESCAPE ALERT π¨
SPACEXAI: PWNED π«‘
CURSOR: LIBERATED π¦
Following a fix shipped by the Cursor team (in about a week, kudos), we present a variant of the Beltdown vuln we shared a few days ago -
Escaping Cursor CLI's sandbox to run arbitrary code on your Mac:
EXCLUSIVE: stealth startup Accomplish reported vulnerabilities in Claude Code, Codex and Cursor this summer. One wasn't fixed for 50 days π
Founders @AmitAvner and @_orcaman warn about wider sandbox security issues with coding tools from the AI labs.
https://t.co/UVU1P6toV4
And... all hacked π¦
Thanks @alexrkonrad for covering some of our work: https://t.co/7KL1z4b2VP
Following fixes shipped from all labs, we will be posting a series of more technical posts, depicting the details of the sandbox escapes, starting with π₯
Beltdown: an RCE made possible due to a Claude Code Sandbox escape:
https://t.co/M6Y0RS9waA
π¨ SANDBOX ESCAPE ALERT π¨
ANTHROPIC: PWNED π«‘
CLAUDE CODE: LIBERATED π¦
@Accomplish_ai researchers uncovered an massive RCE/ACE vulnerability that we are publishing today, where an untrusted git repo opened in Claude Code can escape the macOS sandbox and execute commands on your computer as your privileged user, also bypassing the permission prompt >>