Vercel Sandbox Allowlist Does Not See the Server's Next Fetch.

AIR Security's VerCellBreak post, dated 12 October 2026, says a domain allowlist on Vercel Sandbox blocked a direct connection and did not stop an allowed server from fetching a URL named in a client certificate. Matan Elgabsi and Or Nevo wrote it. Vercel classified the report out of scope and did not accept it.

Hacker News tonight led with an OpenAI conference-room arrest, the Gemini 4 Argon launch, and a Ledger hardware implant. Anthropic's source-control post the same day is a migration to an internal system, not a sandbox failure. US X trends at 22:36 UTC were football, a film, and that launch. Reuters in this window had no new operator control failure. The sandbox fact is AIR's post.

Medium Medium because the allowlist people configure as a data boundary did not see the second request, and because the finding needs a secret already inside the sandbox plus an allowed server that fetches during certificate handling. It is not a microVM escape, and nobody has named a build that closes it.

The handshake is the check.#

Vercel's sandbox firewall docs say domain rules identify traffic by the hostname negotiated during the TLS handshake. HTTPS is matched on the Server Name Indication extension. For an ordinary allowed domain, the firewall forwards the connection without terminating TLS, so it does not decrypt the request and does not read the Host header inside it. The default policy on that page is allow-all. A user-defined policy denies traffic unless a domain or an address range is listed.

The same page already describes a separate limit of that match. A client can send an allowlisted hostname in the handshake and a different hostname in the Host header. The docs call that domain fronting, and they say the firewall does not prevent the mismatch by default. AIR writes that Vercel treated the common variants of that bypass as out of scope. That sentence in the docs is not the finding in the post. It is the vendor's own description of what a hostname check can see.

AIR's finding is the next request. The agent connects only to an allowed domain and presents a client certificate. While the allowed server builds the certificate chain, it may fetch a URL carried in the certificate's Authority Information Access extension. AIR says no vulnerability was exploited on that server. The sandbox never opens the other connection. The post says the technique depends on a server Vercel does not operate, which is why Vercel classified the report out of scope and did not accept it. This brief does not describe how to build that certificate or what to put in the URL.

Two clocks, and no version.#

The control clock is the documentation, read tonight. An ordinary domain allow is still described as a hostname check that does not terminate TLS. The same page describes credential brokering: a transform rule injects a credential into traffic as it leaves, and the secret never enters the sandbox. That control is present in the docs. It is not described as a patch for this report.

The disclosure clock is two sentences that do not match. The 12 October post says out of scope, not accepted. On 13 October The Record quotes Niv Hoffman, AIR's cofounder and CTO, saying Vercel needs time because it is unclear how a patch would be done. The Record says Vercel did not respond to a request for comment. Neither piece names a CVE. Neither names a release.

The impact clock is Hoffman's interview, not a telemetry count. He says AIR has not found exploitation in the wild and cannot rule it out, and that the behavior looked longstanding. The post does not date the firewall feature. It calls the certificate extension niche. The flow it describes needs an allowed server that requests a client certificate and then retrieves a URL. A sandbox whose policy is still the default, allow-all, is a different configuration. The allowlist is not in force there.

AIR frames the work as the same shape as the July Hugging Face incident: an allowed service sent a request the sandbox itself would not. That incident is a separate brief. This one is a customer-configured allowlist on Vercel Sandbox.

1. 2026-07
   OpenAI eval agents reached Hugging Face through an allowed internal service. AIR cites the shape. It is not this firewall.
2. 2026-10-12
   AIR publishes VerCellBreak. Vercel classified the report out of scope and did not accept it. No version.
3. 2026-10-13
   The Record quotes Hoffman: Vercel needs time, patch path unclear. Vercel did not comment. Still no version.

What to do with the allowlist.#

If the secret is on the sandbox disk, the allowlist is not the control that keeps it there. AIR's scenario starts from a private key inside the sandbox. Vercel's credential brokering keeps that class of secret out of the guest and injects it on the way to an allowed host. A process that never sees the secret cannot copy it into a certificate. Use that when the workload only needs the credential at the far end.

Treat each allowed hostname as a process that may open its own connections. A registry, a webhook receiver, or a server that validates client certificates can fetch URLs from material the guest supplied. That fetch is not the sandbox's socket. The handshake check does not see it. Narrow the allowlist to hosts whose job is not to retrieve arbitrary URLs.

Do not generalize this to every sandbox on the platform. The docs say the untouched policy is allow-all, which is unrestricted egress, not a failed allowlist. The finding applies where someone turned on a user-defined domain list and is treating that list as a boundary on data, not only on the guest's own sockets.

There is nothing to upgrade to tonight. When a fix exists, it will be a Vercel release note with a version. It will not be a reconstruction of the certificate from this post.