<div id="readability-page-1" class="page"><div><p>Theori disclosed CVE-2026-31431 yesterday. A 732-byte PoC Python script. Deterministic root on essentially every Linux system shipped since 2017. If you run untrusted code, this is the kind of bug worth stopping for.</p>
<p><strong>E2B sandboxes are not affected. By design</strong>.</p>
<h2 id="background">Background</h2>
<p><code>algif_aead</code> is a kernel module that exposes the crypto API to userspace via <code>AF_ALG</code> sockets. A 2017 in-place optimization let page cache pages land in a writable scatterlist during AEAD operations. Combined with <code>splice()</code>, an unprivileged process gets a deterministic 4-byte write into the kernel's page cache, the in-memory copy of any file the system reads.</p>
<p>Aim those 4 bytes at <code>/usr/bin/su</code>. Run <code>su</code>. You're root.</p>
<p>Three properties make this lethal in shared-kernel environments:</p>
<ul>
<li><strong>Deterministic</strong>.</li>
<li><strong>Cross-tenant</strong>. The page cache is shared host-wide. A write from one container reaches every other tenant on that host.</li>
<li><strong>Invisible</strong>. Corruption only exists in memory. Disk forensics show the original file.</li>
</ul>
<p>Theori named Kubernetes clusters, CI runners, and "cloud SaaS running user code" as priority targets for patches. That last category covers <strong>most</strong> sandbox-as-a-service providers.</p>
<h2 id="why-e2b-is-not-affected">Why E2B is not affected.</h2>
<p><strong>Per-sandbox kernels</strong>. Every E2B sandbox runs in its own <a href="/resources/firecracker-vs-qemu">Firecracker microVM</a>. Own kernel, own memory, own page cache. Bugcrowd's analysis of Copy Fail puts it cleanly: the boundaries that hold are the ones that don't share a kernel. A kernel exploit inside the sandbox cannot reach the host: the attacker would need a Firecracker escape on top of the kernel bug.</p>
<p><strong>The module isn't compiled in</strong>. We build custom minimal kernels for agent sandboxes. These run code interpreters, drive browsers and CLIs, power RL rollouts, and host long-running agents. <code>CONFIG_CRYPTO_USER</code> and <code>CONFIG_CRYPTO_USER_API_AEAD</code> have never been enabled, cause they're not needed by AI&nbsp;agents.</p>
<figure><div><pre tabindex="0"><code><span><span># CONFIG_CRYPTO_USER is not set</span></span>
<span><span># CONFIG_CRYPTO_USER_API_AEAD is not set</span></span></code></pre></div></figure>
<p><code>‍</code>Fewer features mean fewer places for vulnerabilities.</p>
<h2 id="if-your-sandbox-provider-runs-on-containers">If your sandbox provider runs on containers</h2>
<p>Ask them three questions today:</p>
<ol>
<li>Have you patched every host kernel?</li>
<li>What was your exposure window?</li>
<li>Could one tenant have written into another tenant's page cache before the patch?</li>
</ol>
<h2 id="what-you-should-do">What you should do</h2>
<p>Patch to mainline <code>a664bf3d603d</code>. Ubuntu 26.04 (Resolute) and later are unaffected.</p>
<p>If you can't patch immediately:</p>
<figure><div><pre tabindex="0"><code><span><span>echo</span><span> "install algif_aead /bin/false"</span><span> &gt;</span><span> /etc/modprobe.d/disable-algif.conf</span></span>
<span><span>rmmod</span><span> algif_aead</span><span> 2&gt;</span><span>/dev/null</span><span> ||</span><span> true</span></span></code></pre></div></figure>
<p>Container platforms running untrusted workloads: block <code>AF_ALG</code> socket creation with seccomp even after patching. Almost nothing legitimate uses it.</p>
<p>Security and isolation won't affect 99% of your day-to-day. The 1% when it does affect you outweighs the other 99% combined. The reason we chose VM-based architecture is that 1%.</p>
<p>‍</p></div></div>

E2B Blog & Customer Stories

Vaclav Mlejnsky

Containers fail where purpose-built AI computers shine.

E2B Sandboxes Aren't Affected by Copy Fail (CVE-2026-31431). Here's why.

댓글