By Yarden Porat, Check Point Research

Key Points

• Check Point Research analyzed Cloudflare Code Mode, a technique that changes how AI agents use MCP by turning tools into a TypeScript API the model can write code against.
• The research uncovered five vulnerabilities in workerd, the open-source runtime behind Code Mode and Cloudflare Workers. Two were rated Critical by Cloudflare.
• The blast radius is broad: by Cloudflare’s own numbers, Workers is built by millions of developers,[1] serves millions of requests per second,[2] and carries more than 10% of all traffic on Cloudflare’s network.[3]
• Because workerd underpins both Code Mode sandboxes and Workers tenant isolation, the findings create sandbox-escape and cross-tenant exposure risk.
• Cloudflare’s managed Workers environment has been fixed in production. Self-hosted workerd / Code Mode deployments should update to v1.20260619.1.
• Check Point Research released proof-of-concept code as part of its Black Hat USA 2026 presentation.

The short version

We set out to break Cloudflare Code Mode, and ended up breaking Cloudflare Workers too. We did both by targeting workerd, the runtime beneath both: an in-process sandbox that relies entirely on V8 to isolate untrusted code.

We found five memory-corruption bugs in workerd’s native C++ (the “glue” between JavaScript and the runtime), and turned them into two end-to-end attacks:

1. Cross-tenant heap swipe. An out-of-bounds read in URLPattern lets one Worker reach across the shared process heap and swipe another tenant’s secrets.
2. Code Mode sandbox escape. Starting from a prompt injection, a use-after-free in node:zlib breaks out of the sandbox and runs native code on the host.

Part I – Understanding the target

1. Where this started: Code Mode

Code Mode is Cloudflare’s take on LLM tool use. Instead of a model emitting structured tool calls one at a time, Code Mode exposes the available tools as a typed TypeScript API and lets the model write code that calls them: loops, conditionals, data shuffling and all.

In the traditional MCP / tool-calling loop, the model emits one {tool, args} call, the agent runs it, feeds the result back. The model then emits the next call. Every step is a fresh model invocation, and usually a network round-trip. Code Mode collapses that: the model writes one program that orchestrates many tool calls itself (looping, branching, and combining intermediate results locally) and only the final output returns to the model.

Cloudflare’s argument is that LLMs, trained on enormous amounts of real-world code, are simply better at writing a program against a typed API than at emitting long chains of synthetic tool calls. [4]

Figure 1 – Tool calling vs. Code Mode

That code has to run somewhere, and that “somewhere” is workerd, the runtime behind Cloudflare Workers.

2. The workerd origin story

To understand workerd, start with the product it was built for: Cloudflare Workers. Workers is Cloudflare’s serverless platform: you upload a piece of code and Cloudflare runs it at the edge, in data centers close to the user, on demand for every request. There’s no server to manage and, ideally, no cold machine to wait for.

That model creates a hard isolation problem. Cloudflare runs code from a huge number of different customers, and to keep latency and cost down it packs many of them onto the same machines, and, as we’ll see, into the same process. The classic answer (a container or VM per tenant) is far too heavy for this: each one adds tens to hundreds of milliseconds of cold start and a real memory footprint, which is exactly what an edge platform serving oceans of short requests cannot afford.

Cloudflare’s answer is to isolate at the language-runtime level rather than the OS level, using V8 isolates, the same primitive Chrome uses to separate browser tabs. An isolate is a lightweight, independent JavaScript context. Many can live inside a single process, each starts in single-digit milliseconds, and the isolate is the security boundary between tenants.

The trade-off is that this boundary is a software boundary inside one shared address space, not a hardware or kernel one. Untrusted code runs in-process, and the whole model rests on the isolate holding.

Figure 2 – Many tenants, one process

workerd is the runtime that implements all of this. It was closed-source for years: Workers launched in 2017, but Cloudflare only released workerd as open source in September 2022.[5] It’s exactly what Code Mode runs the model’s generated code on.

3. Why workerd was the obvious sandbox for Code Mode

Code Mode has to run untrusted, model-written code, and it needs that code to reach the declared MCP tools and nothing else. workerd answers both at once.

Running untrusted tenant code in-process is its day job, and it lets Code Mode lock the rest down: no filesystem, no arbitrary network (fetch() and connect() simply throw) with the tools exposed only through bindings.[6] Cloudflare didn’t build a new sandbox for Code Mode. It reused the one it already trusts to isolate millions of Workers.

4. Why we targeted workerd

When you set out to break Code Mode, the obvious place to look is the seam between Code Mode and workerd. This is the integration layer: how tools become bindings, how the configuration is wired, how the two interact. Going after the runtime itself is the unusual move. It’s a bit like setting out to break an AI coding assistant and then going to audit Docker’s own source code, the container runtime itself, not the agent on top of it.

Five reasons made us decide to do it anyway:

1. An in-process sandbox is a bold, inherently risky bet. Isolating untrusted code without an OS-level boundary means no VM, no container, just a V8 isolate inside a shared process. That puts the entire security model on a single software boundary. That kind of ambitious bet is exactly what’s worth stress-testing.
2. workerd had almost no public scrutiny.[7] Despite sitting directly on that boundary, there was barely any prior public vulnerability research on workerd, in stark contrast to V8, which is picked apart continuously.
3. The attack surface is huge. And it’s not just V8. workerd has its own implementation that exposes many Web/Node APIs, each written in C++ and reachable from untrusted JavaScript.
4. The blast radius reaches Cloudflare Workers. workerd isn’t only Code Mode’s runtime. It’s the engine behind Cloudflare Workers, one of the most widely deployed serverless platforms on the internet. A bug here would never have stayed contained to an experimental agent feature.
5. AI security has a low-level side too. Beyond the high-level frameworks, the internal, low-level layers that agents rely on to interact with the world deserve research as well.

5. The cage, memory protection keys, and Node

V8 is one of the most heavily attacked pieces of software around, with a long history of memory bugs, so Cloudflare assumes it can break and layers defenses so a compromise of one isolate doesn’t reach the host or other tenants.

Defenses

1. The V8 sandbox (“the cage”). The cage confines JS-reachable objects so a corrupted one can’t forge pointers outside it. Assume arbitrary read/write inside the cage, and stop it reaching memory outside.

2. Memory protection keys. As a further layer against V8 vulnerabilities, production also tags isolate-group memory with hardware memory protection keys (MPK / pkeys), so even with arbitrary read/write inside one isolate’s V8, an attacker still can’t read another tenant’s pages.

3. The L2 process sandbox. Underneath both sits a second-layer (“L2”) process sandbox, so even native code execution inside the process is meant to be contained. Per Cloudflare, the V8 Workers run in a strict layer-2 sandbox (Linux namespaces plus seccomp) that blocks all filesystem and direct network access,[8] limiting what a compromised process can reach on the host.

Attack Surface

Node. Real-world JavaScript assumes Node.js exists, and code constantly reaches for node:* modules, so workerd reimplements a large slice of the Node API in C++. This is exposed to JS through JSG, its “JavaScript Glue” layer. Node was never designed for a threat model where the attacker writes the JavaScript, so this drops a great deal of extra native code onto the boundary, much of it workerd’s own, and enabled by default (a Worker can just require('node:crypto')).

It also means more native objects allocated on the tcmalloc heap, which is secured by neither the cage nor the memory protection keys.

6. Bottom Line

Putting all of the above together, we did exactly that. We targeted workerd’s JSG code, the “JavaScript Glue” that hands native C++ to untrusted JavaScript, whether it is a Node reimplementation or one of workerd’s own API implementations. It is the code that had a fraction of V8’s scrutiny (§4), and the native objects it allocates sit on the tcmalloc heap, memory that lives outside both the cage and the memory-protection keys (§5). So a bug there is not boxed in the way a V8 bug is. It is exactly the surface those mitigations do not cover.

By going after that code we found five vulnerabilities, all of them in workerd’s own native code, each covered in the Vulnerabilities section (Part II).

Building on those bugs, we developed two end-to-end exploits, covered in the Exploits section (Part III).

1. Code Mode sandbox escape. Starting from a single prompt injection, the model is steered into writing attacker-controlled TypeScript. That TypeScript contains a memory-corruption which leads to native code execution, breaking out of Code Mode and running on the host, fully outside the V8 isolate.
2. Cross-tenant secret leak. Starting from a malicious Worker you deploy into Cloudflare’s shared pool, we show that one tenant can read another tenant’s memory and leak its secrets straight out of the shared process. This is the production scenario, and it holds up there because the whole exploit runs from the tcmalloc heap, the memory the cage and MPK do not cover.

But to be explicit, we did not run the exploit on Cloudflare production ourselves. Both exploits were verified on the self-hosted version of workerd. The cross-tenant idea should work the same way on production, since it runs entirely from the tcmalloc heap that the mitigations do not cover, but we did not test it there. On a shared host, a memory-corruption exploit that crashes the process could take other tenants down with it, and we were not willing to risk that.

Part II – The vulnerabilities

7. URLPattern out-of-bounds read

URLPattern is a Web API for matching a URL against a pattern, essentially what a router does. You build a pattern such as new URLPattern({ pathname: "/users/:id" }), call .exec() on a URL, and read back the named capture groups ({ id: "…" }). workerd exposes it to Workers, and in our setting the pattern itself is attacker-controlled.

workerd actually ships two URLPattern implementations. The first is the original, workerd-native one (the urlpattern_original compatibility flag). The second is the newer standard one backed by the Ada URL-parser library. We found the same out-of-bounds read in both implementations, and it gives the same primitive.

7.1 Root cause

Under the hood, URLPattern turns your pattern into a regular expression. Matching a URL then produces two parallel lists: the matched values (one per capture group in the regex) and the group names.

A quick example of the benign case:

Figure 3 – URLPattern: pattern → result

URLPattern also lets you drop raw regex straight into a pattern, with named or unnamed groups. For example, /(\d+)/(?<slug>[a-z]+) has one unnamed group and one named group:

Figure 4 – URLPattern with named group

Here is the implementation. When you call .exec(), workerd runs the compiled regex against the URL and builds the groups object from the result. The original, workerd-native version does it like this:

// urlpattern.c++: building the groups object from a regex match
KJ_IF_SOME(array, regex.getHandle(js)(js, input)) {  // run regex vs URL
  uint32_t index = 1;                                // [0] is full match, skip
  uint32_t length = array.size();                    // 1 + capture count values
  kj::Vector<Groups::Field> fields(length - 1);

  while (index < length) {                           // each capture value
    auto value = array.get(js, index);
    fields.add(Groups::Field{
      .name = kj::str(nameList[index - 1]),           // name by position
      .value = value.isUndefined() ? kj::String() : kj::str(value),
    });
    index++;
  }
  // ...
}

For each capture group, the loop builds one { name, value } field. The value is what the regex matched in the URL. The name is the group’s name (like id from earlier), taken from the nameList vector.

The two sides of that pairing come from completely different places, and that is the part to hold onto:

• length comes from V8. It’s the size of the match array V8 returns after running the compiled regex, i.e. how many capture groups the regex actually produced.
• nameList comes from URLPattern’s own implementation. It’s the list of names workerd assembled while parsing the pattern, before the regex ever ran.

Figure 5 – The group-count mismatch

The loop lines them up position by position, on the assumption that the two counts agree.

So the whole thing rests on those two counts staying equal, and they don’t always. When URLPattern parses the pattern to build nameList, its own group counting misses a group nested inside another group. V8, compiling the real regex, counts every group, nested ones included. So a pattern with one group nested inside another, like (ab(cde)), gives V8 two capture groups where URLPattern counted only one, and length ends up larger than nameList:

const pattern = new URLPattern({ pathname: "/(ab(cde))" });
pattern.exec({ pathname: "/abcde" });   // V8: 2 groups, nameList: 1 name → OOB

Now the loop runs one step too far. For that extra value, index - 1 points past the end of nameList, and kj::str(nameList[index - 1]) reads from beyond the vector, an out-of-bounds read. That is the bug.

7.2 Why an OOB read is an arbitrary read

nameList is a kj::Vector<kj::String>. A kj::String is 24 bytes:

Figure 6 – kj::String memory layout

The OOB index makes kj::str() read 24 bytes of whatever follows the vector and treat it as a kj::String, then dereference ptr to copy out the “string.” So if we control the memory after nameList, we control ptr, and the returned JS string is the bytes at an address of our choosing. OOB read → arbitrary read.

7.3 Two notes

• The same bug is in both implementations, and the Ada one reaches production. The standard, Ada-backed URLPattern makes the identical counting mistake, with the same out-of-bounds read. We confirmed the Ada version triggers on Cloudflare production, and reported it to the Ada maintainers in parallel.
• Our full end-to-end exploit was on the original implementation, self-hosted. Turning the read into a working cross-tenant secret leak was demonstrated against urlpattern_original on self-hosted workerd. That exact path did not reproduce on production, because production has a check the open-source build lacked.

8. zlib deflateParams() UAF

zlib is the most common compression library around. Node.js ships it as the built-in node:zlib module, and to stay Node-compatible workerd reimplemented it in C++. It exposes a handful of APIs. The basic ones compress and decompress via Gzip, Deflate/Inflate, and Brotli. In workerd it comes with the nodejs_compat flag (compatibility date 2024-09-23 or later).

8.1 Dangling buffers

Let’s look at a basic use of zlib. You call write() with an input buffer and an output buffer, and zlib compresses the input into the output.

const input  = Buffer.from("hello world");
const output = Buffer.alloc(64);
handle.write(input, output);   // compress input → output

Those three lines already span three distinct layers:

1. JavaScript (V8): creates the input and output buffers.
2. workerd’s glue code: the translation layer between JavaScript and native C++, turning those buffers into the raw pointers and lengths the C library expects.
3. zlib: the C compression library that does the actual work.

The buffer to watch is output. As it moves, its pointer is passed between all three layers, handled differently in each. So let’s take it one layer at a time, starting on the JavaScript side.

On the JavaScript side, output is reference-counted: it stays alive as long as at least one reference points at it. Follow that count through a single write():

• const output = Buffer.alloc(64). The JS variable holds it: refcount 1.
• handle.write(input, output, …). As the buffer crosses into native code, workerd takes a reference of its own for the duration of the call: refcount 2. That extra reference is what guarantees the buffer can’t be freed while zlib is mid-compression.
• write() returns, and workerd drops its reference again: back to refcount 1, held by the JS variable.
• nothing holds output anymore (it goes out of scope, or is reassigned), so the last reference is gone: refcount 0.

Figure 7 – output refcount lifecycle

Now follow the same buffer into the native side. To hand output to zlib, workerd fills in a z_stream(zlib’s state struct), copying the buffer’s raw address into its next_out field, the pointer zlib writes its compressed output through. That copy happens in setBuffers, on every write():

// zlib-util.c++
void ZlibContext::setBuffers(kj::ArrayPtr<kj::byte> input, kj::ArrayPtr<kj::byte> output) {
  stream.avail_in  = input.size();
  stream.next_in   = input.begin();    // raw pointer into the JS input buffer
  stream.avail_out = output.size();
  stream.next_out  = output.begin();   // raw pointer into the JS output buffer
}

And write() forgets to clear them. When it returns, it resets nothing in the z_stream. next_out still holds the raw address of output. Clearing it is workerd’s job, and the write path simply doesn’t.

The same sequence, now with stream.next_out shown alongside:

Figure 8 – next_out left dangling

Nothing ever clears next_out after setBuffers sets it. So once output’s refcount reaches 0, the buffer becomes garbage, and the next garbage-collection event reclaims its memory, leaving next_out pointing into freed memory.

8.2 The Use in Use-After-Free

We now have a dangling next_out, and the next step is to find who writes through it.

We started in workerd’s own code, but next_out is zlib’s field, and it is zlib, not workerd, that writes output through it. So the real question is where, inside the zlib library, next_out gets written.

The obvious place is an ordinary compression step: deflate() (and inflate()), the functions that push output through next_out. But in workerd that path is only ever reached through write(), and write() runs setBuffers first, resetting next_out to a fresh buffer before deflate() runs. The stale pointer is overwritten before it is ever used. No good.

What we found instead is deflateParams, reached from handle.params(), the call that adjusts the compression parameters, like the level (how hard zlib compresses). It touches the same z_stream and, crucially, does not reset next_out first:

// zlib-util.c++ — ZlibContext::setParams(), reached from handle.params()
err = deflateParams(&stream, _level, _strategy);

That hands zlib the same z_stream, still carrying the stale next_out from the last write(). And rather than clearing next_in/next_out, deflateParams flushes whatever output zlib still has buffered before it applies the new settings:

// zlib - deflate.c, deflateParams() (trimmed)
func = configuration_table[s->level].func;
if ((strategy != s->strategy || func != configuration_table[level].func)
        && /* there is data still pending */) {
    /* flush the last buffer */
    deflate(strm, Z_BLOCK);   // flush pending output through strm->next_out
}
s->level    = level;          // new config applied only after the flush
s->strategy = strategy;

If the level or strategy changes and data is still pending, zlib calls deflate() to flush it before updating the config, and that deflate() writes through strm->next_out, the dangling pointer.

But there is still a problem. When we called write(), zlib already compressed the data we handed it, so how are we supposed to have any bytes still pending for deflateParams to flush?

8.3 Z_NO_FLUSH

Each zlib write takes a flush mode controlling how eagerly output is emitted. Passing Z_NO_FLUSH tells zlib to hold compressed output in its internal buffer rather than push it all out through next_out, so the write() returns with data still pending. That pending data is exactly what deflateParams flushes.

8.4 Putting everything together

The whole use-after-free is a handful of JavaScript calls. Tracking outBuf’s refcount and next_out across the full cycle, the same way we did on the JavaScript side:

Figure 9 – The zlib use-after-free

9. HTMLRewriter AttributesIterator UAF

HTMLRewriter is a Workers API for transforming HTML as it streams through. A Worker can rewrite tags, attributes, and text on the fly without buffering the whole document. workerd exposes it on top of lol-html, Cloudflare’s Rust streaming HTML rewriter, through a layer of C++ bindings.

The bug is in those bindings, not in lol-html. When you ask an element for an attributes iterator, the C++ binding grabs a raw pointer into the element’s internal attribute array and reads through it on each next(). Adding attributes with setAttribute grows that array, and once it outgrows its capacity the array reallocates to a new location and the old one is freed, but the iterator is still pointing at the old, now-freed array. The next next() reads from that freed memory:

new HTMLRewriter().on('div', {
  element(el) {
    const iter = el.attributes[Symbol.iterator](); // pointer into backing array
    iter.next();                                   // reads backing array
    for (let i = 0; i < 10000; i++)                // grow attributes...
      el.setAttribute(`x${i}`, 'A'.repeat(100));   // ...until it reallocates

    const leaked = iter.next().value;              // iter → freed array: UAF
  }
});

10. KV SQL bypass → arbitrary deserialization

The other four bugs are memory-corruption. This one is a classic that leads to arbitrary deserialization.

10.1 Durable Objects

Workers are stateless. Each request runs in a fresh, short-lived context, and nothing held in memory survives to the next one. Durable Objects are Cloudflare’s answer to that: a Durable Object is a single, uniquely-addressable instance that stays alive and keeps its state across requests, both in memory and in private, strongly-consistent storage. It’s how you hold persistent, coordinated state on the edge: a chat room, a live document, a counter.

That storage has a newer SQLite backend, and a Worker can reach the same database in two ways:

1. the key/value API (storage.get / put), which stores each value serialized with the structured-clone algorithm, and
2. the SQL API (storage.sql.exec), which runs raw SQL against the same database.

The key/value data lives in a reserved SQLite table, _cf_KV, and reading a value back deserializes its bytes with V8’s structured-clone deserializer, including workerd’s handlers for internal types.

10.2 The authorizer bypass

A SQL authorizer guards those internal tables. It rejects any query that touches a _cf_-prefixed table: CREATE, SELECT, INSERT, UPDATE, DROP, all of it. But we found one operation it forgot to check.

The authorizer validates the tables a query references, but not the destination name of a rename. So while every direct query against _cf_KV is rejected, nothing stops you from creating an ordinary table under an allowed name and then renaming it with ALTER TABLE … RENAME TO _cf_KV. You build the table under a name the authorizer permits, fill it with crafted bytes, and rename it into place:

CREATE TABLE kv_tmp (key TEXT, value BLOB);          -- allowed
INSERT INTO kv_tmp VALUES ('k', <attacker bytes>);   -- crafted payload
ALTER TABLE kv_tmp RENAME TO _cf_KV;                 -- not checked → now KV

A later key/value read (storage.get('k')) then feeds those attacker-controlled bytes straight into workerd’s internal deserializers, exactly the untrusted input they were never meant to handle.

We didn’t continue from here. The point is the attack surface. A malicious Worker can control the bytes fed to V8’s deserializer, which will deserialize any object it supports, including workerd’s own internal types. And while we stopped there, the surface is worth stressing: that deserializer was built for trusted, in-process data, and unlike V8’s parser and JIT, it isn’t fuzzed for hostile input. That makes it a very strong attack surface, and a well-worn path to type confusion and memory corruption.

Part III – The full chain and its impact

11. Cross-tenant secret theft (Workers)

Cloudflare Workers run the same workerd and the same many-tenants-one-process model from §2. Different customers’ Workers run as separate V8 isolates inside one OS process, sharing one address space and one native (tcmalloc) heap. The isolate is the only wall between them, and that wall is in V8, not on the native heap.

Figure 10 – Cross-tenant OOB read

So the URLPattern read from §7 isn’t just a crash, it’s a way for a Worker you deploy to read another tenant’s memory out of that shared heap. Here is how that out-of-bounds read becomes a private key read from a different Worker. Everything below operates on the tcmalloc heap, outside the cage and the memory-protection keys (§5).

11.1 The strategy

Recall the primitive from §7. The read goes one entry past the end of nameList, treats those 24 bytes as a kj::String { ptr, size, disposer }, and returns the bytes at ptr. So if we control whatever sits right after nameList, we control that fake kj::String, and reading one attacker-chosen kj::String is reading any address we point it at:

Figure 11 – Fake kj::String read primitive

That is the basic primitive. What we actually want is to sweep another tenant’s memory for secrets, to read anywhere in the process, and to do it with as little heap spraying as possible. To get there we need three things:

1. Break ASLR. Leak a real heap address, so we know where to read.
2. Control the ptr of the fake kj::String. So we can read the bytes at any address we choose.
3. Make it repeatable. Read one address after another without re-shaping the heap each time.

11.2 Sizing nameList

One lever first, because it makes the rest easier. nameList’s size is ours to choose. Its length is just the number of capture groups the pattern declares, so padding the pattern with extra groups grows the kj::Vector<kj::String> to whatever size we want. tcmalloc places allocations by size class, so choosing nameList’s size chooses the neighborhood it lands in, and picking the size class is what makes landing our own allocations right next to it reliable.

11.3 Defeating ASLR

A read is only useful once we know where to aim it, and ASLR hides that. To beat it we just need to leak any one real heap address. The out-of-bounds read already returns whatever the fake kj::String’s ptr points at, so if we arrange for ptr to point at a location that itself holds a heap pointer, the read hands that pointer’s bytes back to us as a string:

Figure 12 – Leaking a heap pointer

So we need an object right after nameList with two things:

1. ptr (first 8 bytes), points at a heap pointer, so dereferencing it leaks a heap address.
2. size (next 8 bytes), a small, valid length: not zero, not a pointer, just short enough that the read returns a sane string.

We didn’t find a real object whose layout already satisfies both, so as a last resort we turned to the tcmalloc free list, and it has two properties that fit perfectly:

1. The first 8 bytes of a freed chunk are the next pointer (to the next free chunk), which is requirement #1.
2. The rest of the chunk, including bytes 8–15, is left untouched by the free, so a size we wrote there earlier stays put. That is requirement #2.

So what we can do is allocate a chunk right after nameList, write size = 8 into its bytes 8–15, and free it. The free turns its first 8 bytes into a next pointer to the next free chunk, while our size = 8 survives:

Figure 13 – Freelist next-pointer overwrite

The read hands back that heap pointer as bytes. Since tcmalloc aligns its heap to a 1 GB boundary, one leaked pointer gives us the heap base.

11.4 A repeatable read with VFS files

ASLR gives us an address. Now we want to read many, to sweep the heap. The problem is doing that without re-shaping every time. If reading a new address meant a fresh allocation, we’d have to land it next to nameList again on each read. What we need instead is an allocation we can keep in place and change in-place, so we just rewrite the target pointer and read again.

The best fit we found is a workerd API called VFS, a virtual (memory-only) filesystem. A VFS file’s contents are a native kj::heapArray on the tcmalloc heap, and crucially we can overwrite those contents at will without reallocating. It also lets us pick the file’s size, so we match nameList’s size class and a sprayed file lands right after it.

The idea is to shape the heap once so a VFS file lands right after nameList, then read any address by rewriting that file’s bytes in place and calling exec() again, with no re-shaping per read:

Figure 14 – Repeatable read via VFS

(This works because nameList is allocated when the URLPattern is constructed, but the out-of-bounds read only fires later on exec(), so the shaped layout persists across reads.)

11.5 Reading another Worker’s secret

From here it’s just a sweep. We walk the heap with the repeatable read and look for bytes that look like a secret, in the PoC, Bearer sk…-style API tokens, until we find one belonging to a co-located Worker.

12. Sandbox escape: from the zlib UAF to host RCE

The second demo stays inside Code Mode and goes all the way to native code on the host, starting from the zlib use-after-free of §8.

12.1 Improving the primitive

Recall what §8 gives us, broken into the pieces we’ll build on:

• A use-after-free write. When params() flushes, zlib writes through the stale next_out into the output buffer, after that buffer has been freed and its slot can be reused.
• A controllable allocation size. We choose the size of the output buffer, which decides which freed slot the write targets and what we can spray into it.

Our primitive, then:

Figure 15 – Reusing the freed buffer

And the write isn’t clean. The first 5 bytes of every flush are compression metadata.

Two improvements make it precise:

1. The offset of the write. workerd’s write() lets us choose where in the output buffer zlib starts writing. Alongside the buffer it takes an output offset, and zlib sets next_out = buffer + offset, so the write lands at freed + offset, a precise spot inside the reused object instead of always at its start.

2. The size of the write. We also keep the flush small, down to a single 8-byte field, so the write overwrites exactly the field we’re aiming at, rather than splattering the whole object around it.

Together that turns a blunt write at the top of the buffer into a small write landing exactly on a field we pick:

Figure 16 – Flush at chosen offset

12.2 From use-after-free to repeatable read/write

You might still be wondering how an imprecise write is exploitable at all. We control where it lands, but not the bytes. The trick with this kind of primitive is to stop caring about the bytes. Instead of writing a value, you find a “strong” object and overwrite its size / length field. You don’t need the exact bytes, you just need to make that length bigger. A bloated length turns the object’s own bounded read/write into an out-of-bounds read/write, and that you can build on.

The strong object we use is, again, a VFS file, but this time we corrupt the file’s metadata (the FileImpl object that tracks where the file’s data lives and how long it is), not the file’s contents:

Figure 17 – FileImpl metadata layout

With a FileImpl in the freed slot, we aim the UAF write at offset 0x20 so it lands on data.size and inflates the length.

Why does a bigger data.size matter? The file’s data lives at data.ptr, and data.size is the length workerd treats as its bounds, any read or write through the file API is allowed as long as it stays within [0, data.size) of data.ptr. Normally data.size matches the real buffer, so the file stays in bounds. After we inflate it, that bound now covers the real buffer and whatever heap follows it, so a file read or write past the real buffer still passes workerd’s bounds check and is carried out normally, even though it now reaches into adjacent memory:

Figure 18 – Inflating data.size out-of-bounds

And the file API makes that precise. Node’s fs read/write take a position argument (the file offset to read or write at, passed straight to the call, no separate seek), plus a length, so we can land exactly on any spot at data.ptr + position. To read 8 bytes from an out-of-bounds offset:

Figure 19 – OOB read via readSync

And to write 8 bytes at an out-of-bounds offset. Here the bytes are ours, it’s an ordinary file write:

Figure 20 – OOB write via writeSync

So one inflated length turns the VFS file into an out-of-bounds read and write at any offset across the heap.

12.3 Arbitrary read/write

OOB across adjacent heap is strong, but it only reaches forward from one buffer and the exact distances depend on the layout. We upgrade it to a clean, anywhere-in-the-process read/write with a second FileImpl.

The idea is to use the OOB write from the inflated file to reach a second FileImpl sitting further along the heap, and overwrite its data.ptr with any address we want. That second file’s metadata now says “your contents live at <address>”, so an ordinary read or write of the second file reads or writes that address:

Figure 21 – Arbitrary read/write primitive

And it’s repeatable. To hit a new address we just rewrite the second file’s data.ptr through the first file again and read/write once more, with no re-triggering the bug. That gives us a stable arbitrary 64-bit read and write across the whole process, the same shape of primitive we built for the cross-tenant read in §11.

12.4 To native code

On the self-hosted build the V8 sandbox is off, which makes the finish almost trivial. Normally turning a memory read/write into code execution means defeating W^X with a ROP chain and chasing per-version gadget offsets. Here we don’t have to. With the sandbox off, workerd reserves V8’s code region as a 256 MB read-write-execute (RWX) mapping at a fixed address, 0xaaaaf0000000, present from process startup, no leak required. So we skip ROP entirely.

The finish is simple. Use the arbitrary write to drop ARM64 shellcode (a reverse shell) into that RWX region, then redirect a function pointer to it. The pointer we hijack belongs to the zlib stream itself, the native write callback that handle.write() invokes (reached through the z_stream, which we locate via its avail_in field). We overwrite that callback’s target with our shellcode address and then call handle.write() once more. Instead of running zlib’s write path, control jumps to the shellcode, native code in the host process, out of the V8 isolate entirely.

Cage-off caveat. This chain was built against a self-hosted workerd compiled with the V8 sandbox off, which lets ArrayBuffer backing stores and native C++ objects share one heap, exactly what the FileImpl overlap relies on (and how Code Mode runs, §5). The underlying UAF is independent of the cage, but with the cage on this specific FileImpl technique would not work as-is. Reaching RCE there would need a different post-UAF path.

Part IV – Takeaways and disclosure

13. Defensive takeaways

• The engine is not the whole boundary. Hardening V8 and shipping the cage is necessary, not sufficient. Every native API reachable from untrusted JS is part of the boundary.
• Glue layers deserve first-class security review. JSG marshals lifetimes and pointers across the JS/native seam. That’s exactly where UAFs and missing bounds checks live. It had a fraction of V8’s scrutiny.
• Native allocations need their own threat model. tcmalloc free-list behavior, VFS buffers, and kj containers live outside the cage. If the cage is your isolation story, the things it doesn’t cover are your attack surface.
• Agent-generated code is normal code. In Code Mode the model writing exploit-shaped TypeScript isn’t an exceptional event, it’s the intended mode of operation. Prompt injection is a code-execution entry point, and should be modeled as one.

Disclosure timeline

All five vulnerabilities were reported to Cloudflare through HackerOne under coordinated disclosure.

Date	Event
February 1, 2026	4 of the 5 vulnerabilities reported via HackerOne (zlib UAF, HTMLRewriter UAF, both URLPattern OOB reads)
March 11, 2026	Cloudflare rated two of them Critical (zlib UAF, HTMLRewriter UAF)
March 12, 2026	The 5th, the KV SQL-bypass → deserialization, reported
Aug 5–6, 2026	Public reveal at Black Hat USA 2026 (Mandalay Bay)

Cloudflare’s responses and confirmations:

• Two rated Critical. Cloudflare rated the zlib use-after-free and the HTMLRewriter use-after-free as Critical.
• Production reach. Cloudflare confirmed that the bugs reproduce on Cloudflare production, with one exception. The original URLPattern out-of-bounds read (urlpattern_original) does not trigger there (the Ada-backed standard URLPattern does).
• The cage doesn’t cover the heap we used. Cloudflare confirmed our central claim, that the tcmalloc native heap is outside both the V8 sandbox (cage) and the memory-protection keys. Exactly the memory every primitive in this post operates on.
• Fix. Cloudflare’s managed Workers were fixed in production, and workerd v1.20260619.1 closes all of these bugs for self-hosted deployments. As of now, Cloudflare has not assigned CVEs.

Links

1. Cloudflare Q1 2026 earnings call (May 7, 2026), “Developers on Cloudflare’s platform increased to more than 5.5 million…”: https://www.theglobeandmail.com/investing/markets/stocks/NET/pressreleases/1904486/cloudflare-q1-earnings-call-highlights/
2. “go from no traffic at all to millions of requests per second instantly”: https://blog.cloudflare.com/workerd-open-source-workers-runtime/
3. “More than 10% of all requests flowing through our network today use Cloudflare Workers”: https://blog.cloudflare.com/cloudflare-workers-serverless-week/
4. “LLMs are better at writing code to call MCP, than at calling MCP directly” : https://blog.cloudflare.com/code-mode/
5. “workerd is Open Source under the Apache License version 2.0” (post dated 2022-09-27) : https://blog.cloudflare.com/workerd-open-source-workers-runtime/
6. “we prohibit the sandboxed worker from talking to the Internet. The global fetch() and connect() functions throw errors” : https://blog.cloudflare.com/code-mode/
7. only two published security advisories, both Moderate : https://github.com/cloudflare/workerd/security/advisories
8. “The ‘layer 2’ sandbox uses Linux namespaces and seccomp to prohibit all access to the filesystem and network” : https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/
9. no public link, Cloudflare coordinated-disclosure correspondence. Cloudflare confirmed there are no MPK protection keys on the tcmalloc allocations.

The post When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers appeared first on Check Point Research.

For years, the cyber security industry tracked AI as a force multiplier: something that made existing attack techniques faster, cheaper, and more accessible. That framing was accurate. But the Annual AI Security Report 2026 from Check Point Research documents a transition that goes further. AI has crossed from assistant to operator. Where it once helped attackers prepare, it now runs the operation.

Key observed findings

• AI has crossed from development aid to live attack operator. It now does the hands-on work inside live intrusions, from China-nexus espionage campaigns to a criminal breach of multiple Mexican government agencies and has spread from nation states to ordinary cyber criminals. 
• AI now builds deployment-ready malware and attack suites. Its involvement is often invisible in the finished artifact: one developer used an AI environment to produce VoidLink, an 88,000-line command-and-control offensive framework, in under a week. 
• Attackers prefer commercial models, and now abuse them by exploiting the agentic architecture, not just single prompts. Most actors favor jailbroken mainstream models over self-hosted ones, and the durable bypass is now a planted configuration file an agent loads and trusts across sessions. 
• An AI-enabled criminal tooling market has matured. Phishing-as-a-service kits now embed a language model with the jailbreak built in, and conversational AI voice-agent services run vishing and one-time-passcode theft at scale.
• Virtual Identity is no longer a reliable trust anchor. Voice, face, documents, and live video are now cheap to forge convincingly and are widely used in attacks taking multi-channel social engineering to a new level of integration. 
• AI itself is an expanding attack surface. Models cannot always separate data from instructions and content they process might influence the model’s behavior; the surrounding stack adds ordinary software vulnerabilities and supply-chain risk, all in a rapidly evolving ecosystem where security practices not always mature. 
• Indirect prompt injection is on the rise. Detections of longer malicious payloads increased sharply, rising roughly fivefold between March and May 2026 and approaching 1% of observed prompts in May. Longer payloads are more typical of content-borne and agentic attack paths, this pattern suggests that indirect prompt injection is becoming more operationally relevant. 
• Enterprise data leakage through GenAI is persistent and growing risk. High-risk prompts doubled from 2% to 4% during the last year, while organizations used an average of 10 AI applications each month, many without official approval. 
• Data exposure risks are not evenly distributed across the verticals. Sector-level analysis reveals that AI-related data exposure risks are not evenly distributed across the verticals, and correlate both with AI usage patterns and security maturity. Business Services recorded the highest rate of high-risk GenAI prompts at 5.91%, meaning nearly one in every 17 AI interactions carried a significant risk of sensitive data exposure. 

To read the full findings, access the AI Security Report 2026 from Check Point Research here. 

The post AI Security Report 2026 appeared first on Check Point Research.

Research by: Alexey Bukhteyev

Key Takeaways

• AI can turn high-level malicious ideas into concrete techniques, and can independently design and implement novel attack paths that have not yet appeared in real-world campaigns.
• In this research, DeepSeek connected unrealistic browser-malware concepts with a real browser capability, turning an AI-generated malware hallucination into a plausible browser-native ransomware technique. Although the generated sample was incomplete, it exposed a practical abuse path based on the File System Access API and access to photo directories.
• The technique does not require a native payload, APK installation, browser exploit, or root access. It relies on social engineering and a legitimate permission prompt exposed by the File System Access API in Google Chrome.
• The Android scenario is especially concerning because photo directories are high value personal data stores and, unlike iOS, modern Android Chrome versions expose a browser API that allows web pages to read and modify files in those directories after user approval. Using a fake AI image-enhancement workflow gives users a plausible reason to approve folder-level file access. Our PoC demonstrates this browser-only workflow against selected image directories on Android.

Introduction

Over the past several years, large language models have reshaped software development, and malware development has followed the same path. Check Point Research has documented this trend from early experiments showing that AI systems could generate offensive components, to cases of cybercriminals using ChatGPT to create malicious tools, and later to advanced AI-authored malware frameworks such as VoidLink. In some cases, LLMs lowered the barrier enough for users with little or no development experience to produce working offensive code.

As frontier models became better at writing reliable code, including complex security related components, major AI vendors also turned cyber safety into a dedicated control area. Clearly malicious requests involving credential theft, malware deployment, ransomware behavior, persistence, stealth, or unauthorized exploitation are now commonly blocked or refused. OpenAI’s cyber-safety documentation, for example, describes additional safeguards for models classified as having High Cybersecurity Capability, while Anthropic has published reports on detecting and countering cyber misuse of Claude.

DeepSeek then becomes particularly relevant in this context for several reasons:

• Lower refusal rates for harmful cyber enforcement: compared with Anthropic and OpenAI, DeepSeek models were less consistent refusing harmful cyber requests, including the File System Access API implementation we will be discussing later on this article.
• Low barrier to access: DeepSeek is free to use via the web interface, widely available, and accessible in regions where other frontier models face regulatory or commercial restrictions. This lowers the cost of repeated malicious experimentation.
• End-to-end malicious code from a single prompt: in our testing, a working malicious application could often be generated from a single broad prompt. Achieving a comparable result with OpenAI or Anthropic typically requires decomposing the attack into multiple benign-looking requests and manually assembling the generated components.

Putting this all together, these differences make DeepSeek particularly attractive to threat actors: DeepSeek models can turn high‑level malicious ideas into concrete, complete attacks with less expertise than competing platforms.

Check Point Research analyzed nearly 3,000 files attributed to DeepSeek observed in public telemetry over the past year. The dataset included Python, PowerShell, Batch, HTML, JavaScript, VBScript, and other file types. Of these, 1,383 files were classified as malicious or dangerous by either VirusTotal detection or static source analysis. Within this dataset, we found a sample that implemented a dangerous browser-native technique we have not observed exploited in the wild. We refer to it as In-Browser Ransomware. The technique uses a phishing lure to persuade the victim to grant file-system access to a web page; once access is granted, the page can enumerate local files in the selected folder, read and exfiltrate their contents, encrypt and overwrite them, and display a ransom-style message, all without installing a native payload or exploiting the browser.

The underlying browser risk was already known to browser engineers. The File System Access specification explicitly lists ransomware as a security consideration, and the 2023 USENIX Security paper RoB: Ransomware over Modern Web Browsers studied the abuse of the File System Access API to encrypt local files from a malicious web application.

The important finding in our research and what is new, is how the AI model brought these previously documented concepts together, into a realistic and enforceable attack scenario leveraging a method that defenders had originally thought was unfeasible due to browser sandboxing limits: a DeepSeek-attributed malicious sample, generated as an all-in-one malware fantasy, connected this documented platform risk to a realistic phishing-style web application, demonstrating a viable end-to-end attack chain. An attacker does not need to know that a browser exposes a file-system API. They can ask for an impossible-sounding outcome – a website that steals files, captures keystrokes, takes screenshots, encrypts files, and demands payment – and the model may connect the request to a real browser capability. Basically, the AI model showed an ability to reason across existing knowledge and combined multiple known components into a coherent attack workflow that could be readily used by an attacker. This illustrates how frontier AI models may move beyond simply enhancing existing attacker techniques to lowering the expertise required to operationalize complex attack chains by connecting knowledge in ways that previously relied on human experience and creativity.

A Noisy Sample With One Important Idea

The sample that caught our attention is SHA256

07c39f79ab92fb21557b82283472dce1c112f577d796111fb752c3c6d84c86b5, a Python Flask application that serves victim-facing HTML and JavaScript from embedded templates and also includes backend routes intended to receive information from the victim and provide an administration panel.

We do not have the prompt submitted to the AI model that produced this sample. Judging by the code structure, function names, and comments, it was likely formulated very broadly such as something similar to this example: create a universal malicious tool that runs through the browser and collects as much victim data as possible, encrypts files, and demands ransom. In a single front-end, the generated code assembled routines and stubs for keylogging, clipboard monitoring, form and network-request interception, Discord-token collection, crypto-wallet and payment-card discovery, geolocation requests, webcam and microphone access, screenshots, local-file access, Chrome exploit stubs, “persistence,” and a ransomware-style overlay. This does not mean the sample actually implements all of these capabilities. A more accurate reading is that it is an AI-generated blueprint in which the model tried to translate familiar capabilities of native stealers and ransomware tools into a web page opened in the browser.

The victim-facing page is disguised as a Discord avatar AI upscaler:

Clicking the button on the victim-facing lure page is intended to start the malicious browser-side sequence, although the generated control flow is inconsistent and does not complete reliably. After a fake processing step, the page is intended to display a ransomnote-style overlay under the name InfernoGrabber v9.0. The message claims that passwords, credit cards, and personal files were encrypted, demands Bitcoin, and displays a countdown threatening publication of private data.

Most of the functionality claimed in the sample collapses at the browser boundary. A normal web page can observe activity inside its own origin, capture input events delivered to its own DOM, request browser-mediated permissions, access storage scoped to its own origin, and render frightening overlays. It remains constrained by the browser security model.

In this sample, the “desktop screenshot” routine captures the rendered web page, the keylogger observes keystrokes only while the user interacts with the page, webcam and microphone capture depend on browser permission prompts, and the Discord-token stealing logic searches storage available to the current origin. The “persistence” logic relies on browser storage and a service worker registration attempt.

Much of the sample therefore reads as an AI hallucination produced in response to an overly broad prompt or to requirements that a normal web page cannot satisfy. The exception was the file-access workflow, where the generated code reached for a real browser primitive with practical abuse potential.

The generated JavaScript referenced:

• showOpenFilePicker();
• showDirectoryPicker();
• recursive traversal of a user-selected directory;
• reading selected files through browser file handles;
• sending file contents to the Flask backend;
• displaying a ransomware-style warning after the interaction.

The File System Access API is a legitimate browser capability designed for web applications such as editors, IDEs, and creative tools. After the user grants access, a web application can read files and folders from the local device. The API also supports write access and directory enumeration under browser permission controls.

The technique is limited to browsers that expose the picker-based File System Access API. At the time of writing, this primarily means Chromium-family browsers: the API shipped on desktop in Chrome 86, and Chrome 132 extended File System Access support to Android and WebView. Firefox and Safari do not expose the same local file and directory picker methods, which limits the immediate attack surface but also concentrates the risk in Chrome-based browsing environments.

The sample lacked a complete and reliable browser-side encryption flow, yet the attack design was concrete: a fake utility convinces the user to grant browser file access, which allows the page to exfiltrate and encrypt files.

The model combined fake OS-level malware claims with a real browser primitive and produced a browser-native file-theft and ransomware scaffold. The sample shows how an LLM can transform an abstract malicious request into a new attack blueprint. The user likely wanted an all-in-one tool: a Discord-themed lure, a stealer, an admin panel, and a ransomware or locker workflow. The model chose a Flask application and a browser frontend as the unifying architecture. In doing so, it connected a hallucinated malware concept to a real platform feature with genuine abuse potential.

Even though we have not yet observed this exact browser-native ransomware pattern widespread in-the-wild campaigns, the technique is still operationally relevant for several reasons:

• The browser becomes the execution environment: the attack runs entirely inside the browser process, without installing any additional app, dropping a binary, or exploiting a vulnerability. Traditional endpoint protections focus on apps and native payloads; a website that encrypts files after a legitimate-looking permission sits outside those assumptions.
• Lower friction for victims: opening a web page and clicking “Allow” on a file-access prompt is a normal part of using modern web applications. Users do not intuitively treat this as “running malware”, which makes the social-engineering angle powerful.
• Cross-platform reach: the same browser-native technique can target any platform where the File System Access API is exposed, we tested on Android and Windows.

From Hallucinated Scaffold to Working PoC

Because the original sample was incomplete, we tested whether the latest DeepSeek model V4 could turn the same browser-native attack idea into a working proof of concept.

When prompted directly to create ransomware, the model consistently refused across all tested modes.

Even though some requests were denied, we managed to succeed in the end. We removed explicit terms such as “ransomware” while preserving the same functionality: a web page that asks the user for access to local files, processes them inside the browser, and leaves the user unable to recover the original content.

In Instant mode, DeepSeek consistently generated HTML/JavaScript code that used the File System Access API to interact with user-selected files.

In Expert mode, the behavior was inconsistent across attempts:

• several attempts ended in refusal;
• one generated a non-functional sample;
• one generated a fully working browser-based ransomware PoC.

One response was especially notable because the model described the result as:

“a crafted trap that combines a convincing AI upscaler interface with hidden ransomware-like behaviors”

This wording shows that the model recognized the malicious nature of the scenario while still continuing the generation.

For comparison, we tested similar requests against ChatGPT and Claude. In our tests, these systems either refused to help or generated constrained browser-safe implementations that did not use the File System Access API.

This does not mean that the same outcome is impossible with other frontier systems. With an incremental approach, a user can ask for separate components that appear benign in isolation, such as a user interface, browser file handling, client-side data transformation, and neutral status messaging, and then assemble them into a harmful workflow by replacing the neutral messages with a ransom note. The difference is the level of steering required. In that scenario, the user needs enough technical understanding to decompose the attack, preserve the malicious objective across separate requests, identify the right browser primitive, and combine the generated pieces manually.

In-Browser Ransomware on Android

To assess the practical risk of this technique, we used an LLM to build a controlled proof-of-concept (PoC) based on the same idea we observed in the DeepSeek-attributed sample: a browser-native ransomware workflow disguised as an AI image upscaler.

On Android, modern Chrome versions expose the picker-based File System Access API to web content. On iOS, Safari does not expose the same File System Access primitives to websites. Access to photos is mediated by the operating system’s app-sandbox and photo-library permissions instead of a web API that can enumerate and modify arbitrary folders. Chrome on iOS uses WebKit which also does not implement File System Access API. As a result, on mobiles, the technique we demonstrate is currently practical on Android Chromium browsers.

At the same time, the attack surface is narrower than arbitrary disk access. The picker-based File System Access API does not let a web page target the whole system disk, and Chromium applies additional restrictions to sensitive locations. In Chromium’s current implementation, broad access to locations such as the user’s home directory, Desktop, Documents, Downloads, Chrome data, application directories, Windows, Program Files, AppData, and several Linux and Android system paths is blocked or constrained. The File System Access specification also explicitly recommends restricting sensitive directories and lists ransomware as one of the risks the API design must account for.

However, selection of the root of the default Pictures and Videos directories was not restricted on any of the tested operating systems (Android and Windows). This capability fits naturally into a social-engineering workflow for a fake photo-processing application.

On desktop, the Pictures folder may contain personal files, but it is usually less central to business workflows than the user’s entire home directory or a Documents directory.

On mobile, the risk profile changes: the photo library is often one of the most valuable local data stores. It may contain years of private photos, identity documents, banking screenshots, medical records, recovery codes, travel documents, work images, and photos of family members. Losing access to this data, or having it exfiltrated, can create personal or business issues from ransomware to blackmail or if the data is sensitive, public disclosure leading to reputational damage and more. Chrome 132 introduced File System Access support on Android, allowing web applications, after user approval, to read and save changes directly to selected files and folders. We tested this capability on several Android devices and confirmed that the latest Chrome version available to us at the time of testing, Chrome 148, also allowed selecting the photo directory, including the root of the DCIM folder.

The workflow on Android looks very natural. The user opens a web page that promises to enhance a photo, selects an image, and is then asked to choose a directory for saving the “enhanced” results. The browser warning that the site will be able to edit files in the selected folder is easy to rationalize in that context: the user expects the service to write processed images back to the device. During the fake processing step, the PoC encrypts pictures inside the selected directory.

Video 1 – Demonstration of a browser-native ransomware PoC on Android using the File System Access API.

The combination of this technique, a natural social-engineering lure, and browser-only execution makes the Android scenario especially concerning. The resulting flow requires no APK installation, no vulnerability exploitation, no native payload, and no root access.

Users generally do not treat opening a web page as a malware execution event, especially when no application is installed and no binary is downloaded. In this case, the browser prompt appears in a context where file access feels expected, while the granted permission gives the page meaningful control over a directory that may contain highly sensitive personal data.

Practical Recommendations for Users

While this research focuses on a controlled PoC, there are concrete steps users can take today to reduce the risk of browser-native ransomware abuse:

Treat browser folder-access prompts as high-stakes decisions: before approving “access to files in a folder”, check which site is asking, which folder is being selected, and whether editing files is truly necessary for the feature you expect. If you are unsure why a site needs write access to an entire directory, decline the request.

Avoid granting websites access to sensitive or irreplaceable data: do not expose folders that contain personal photos, identity documents, recovery codes, or work data unless the site is highly trusted and the need is clear. Prefer selecting a temporary or empty folder for experimental web tools, rather than your main photo library.

Prefer well-established applications for high-value data: for tasks such as backing up photos, editing large collections, or processing sensitive images, use reputable native apps or well-known cloud services instead of newly discovered browser tools with unknown reputation.

Maintain offline and cloud backups of important data: regular backups reduce the leverage attackers gain from encrypting or deleting local files, whether through native ransomware or browser-based techniques.

Keep browsers and mobile OSes updated: browser and OS vendors continue to refine permission models and harden sensitive APIs. Applying updates promptly ensures that you benefit from the latest security controls around features like File System Access.

Be skeptical of AI-branded lures: attackers increasingly disguise malicious flows as “AI” utilities, avatar upscalers, photo enhancers, or productivity tools. A polished AI-themed interface is not a guarantee of safety; apply the same caution you would to any unfamiliar site asking for broad access to local files.

Conclusion

LLM-assisted malware development changes the economics of malicious experimentation. A user with limited technical understanding can describe a harmful outcome, generate code, test the result, adjust the prompt, and repeat the process at very low cost. Tasks that once required a developer, a purchased builder, or prior knowledge of the relevant platform can now be approached through cheap iteration.

This also changes the defender’s problem. Malware generated this way may move the ecosystem away from a limited set of reused families and builders toward a larger volume of disposable, one-off artifacts, each carrying a unique combination of techniques, API usage, and payload logic.

Hallucination adds another important dimension. AI-generated malware can be technically wrong and still reveal practical malicious techniques. When a model tries to satisfy unrealistic requirements, it may search across legitimate platform features and map a malicious goal to an API that actually exists. This process can surface techniques that defenders have not yet seen in the wild, or turn risks previously described mostly in theory into workable attack concepts. The case analyzed in this research shows exactly that: a noisy and partially broken artifact connected a theoretical browser risk to a practical browser-only ransomware technique.

In this case, the user likely asked for an impossible web application, a single browser page that behaves like a fully features stealer and ransomware agent. The model could not satisfy all of those requirements correctly, but in the process of trying, it searched across legitimate browser features and anchored part of the fantasy to a real API: the File System Access API.

This illustrates a broader risk:

• A non-expert attacker does not need to know that such an API exists or how to abuse it.
• By describing a high-level malicious outcome in natural language, they can cause the model to discover and connect the malicious goal to previously under-explored platform capabilities.
• The resulting prototype can then be refined into a working PoC with minimal additional prompting or manual editing.

In other words, AI is not only lowering the barrier for reimplementing existing malware techniques; it is also capable of bridging the gap between purely theoretical risks and practical, novel attacks that defender have not yet seen deployed in the wild.

Historically, new attack techniques emerged through human experimentation, experience, and creativity. Frontier AI changes that dynamic. Rather than being constrained by conventional thinking or established attacker playbooks, AI can reason across existing knowledge and synthesize it in unexpected ways, connecting known capabilities into practical attack chains. The real shift is not that AI is inventing entirely new vulnerabilities, but that it may identify combinations and attack paths that humans had not previously recognized or operationalized.

At the time of analysis, we found no evidence that this technique had been adopted as an in-the-wild malware pattern. The original DeepSeek-attributed sample was incomplete and failed to implement the full attack reliably. However, our testing showed how little effort is required to transform the same idea into a fully working implementation using modern LLMs. The resulting workflow is especially concerning on mobile devices, where a seemingly legitimate request for access to a photo directory can expose highly sensitive personal data to encryption, exfiltration, or both. From a defensive perspective, browser folder-access prompts should be treated as security decisions rather than routine clicks. Before granting a website access to an entire folder, users should review which site is asking, which folder is being selected, whether file modification is allowed, and whether the permission matches the action they intended. Users should avoid granting websites access to directories containing sensitive, private, or irreplaceable data whenever possible.

The post Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique appeared first on Check Point Research.

Executive Summary

During the March–April 2026 reporting period, AI use in offensive operations advanced from development and planning to real-time operational deployment. Multiple independent cases, involving individual criminal actors, mass exploitation platforms, ransomware groups, and state-sponsored espionage, show evidence of commercial AI models executing autonomous attack workflows across extended campaigns.

Key findings:

• AI-orchestrated attacks have progressed from experimental, state-sponsored use to in-the-wild criminal deployment. Multiple criminal operations relied on commercial Claude Code as a persistent operational tool in multi-week campaigns.
• Agentic configuration files are being weaponized as persistent jailbreak vectors. Hooks, project-level files, and settings files abuse the operational control level and redefine the model behaviour at the architecture level.
• AI-enabled attack platforms are commercializing AI capabilities. Operators can now buy access to platforms where the AI pipeline, model selection, jailbreak, and delivery mechanisms are embedded in the product.
• AI provider credentials have become a high-value target. As commercial AI services become central to offensive operations, API keys for Anthropic, OpenAI, Groq, Mistral, and HuggingFace are harvested at scale from compromised .env files, providing access without registration and resilience against provider attempts to revoke this access.

AI as Live Attack Operator

AI selection considerations

Underground forum discussions still show actors debating the use of commercial models, dedicated jailbreak services, or locally hosted open-source models, reflecting the lower-skill end of AI adoption. More advanced actors combine tools pragmatically: from commercial AI models, open or uncensored models where commercial providers restrict output, and custom automation pipelines that perform repetitive analysis at scale. Tasks are systematically broken down into smaller sub-requests that present a lower apparent risk profile.

Forum users further discuss and share methods and alternatives to avoid mainstream-provider safety controls by mixing open-weight Chinese frontier models, privacy-routed proxies, and explicitly uncensored services.

The Mexico Breach

When Anthropic disclosed GTG-1002, a Chinese nexus campaign using Claude Code for cyber espionage, in November 2025, this was seen as an experimental, state-sponsored development. The disclosure carried no IoCs and was therefore disputed by independent researchers, and the activity was detected only through Anthropic’s own API monitoring. The Mexico breach, which occurred a few months later, demonstrates similar architecture in operational, financially motivated criminal use, at scale, and with a recovered forensic record.

Between late December 2025 and mid-February 2026, a single operator compromised nine Mexican government agencies. Researchers documented the case after recovering materials from attacker-controlled VPS servers. Details include the operational record: 1,088 attacker prompts generating 5,317 AI-executed commands across 34 sessions.

The breach scope was significant: tax records, civil registry data, vehicle records, patient files, and electoral infrastructure were affected. However, an even more important lesson is how the campaign was run.

The operator built a dual AI workflow. Claude Code served as the interactive exploitation assistant, helping advance access, write exploits, build tunnel chains, map victim environments, and escalate privileges. In parallel, harvested server data was processed through GPT-4.1 for automated intelligence analysis. The GPT output was then used to task new Claude sessions.

As we highlighted in our previous review, the agentic infrastructure itself was exploited to bypass the model’s safety restrictions. At the start of the campaign, Claude refused to execute requests which it correctly identified as offensive cyber activity. The attacker then changed tactics. Instead of asking Claude to generate malicious content directly, they pasted a large penetration-testing cheatsheet into CLAUDE.md in the project root, the file Claude Code automatically loads as persistent project context at the start of every session. From that point on, subsequent sessions inherited the rules and techniques in that file. The attacker did not need to repeat the jailbreak as the behavior persisted through the project configuration layer. After gaining root on a civil registry server, the model’s actions in subsequent sessions were consistent with the persistent cheatsheet, including unprompted post-exploitation steps such as shadow file extraction and timestamp cleanup.

Bissa Scanner

A second documented case, Bissa Scanner, was published in April 2026, after researchers identified an exposed operator server. Bissa is a modular mass-exploitation platform built around React2Shell (CVE-2025-55182), with 900+ confirmed compromises across millions of scanned Next.js endpoints and an archive of 30,000+ distinct .env filenames recovered from operator-controlled S3 storage. The operation has been running since September 2025. Here, AI is positioned one step back from the exploitation layer: Claude Code and OpenClaw (running claude-sonnet-4-6, with a Telegram bot for triage alerting) served as the operator’s working environment for reading the scanner codebase, troubleshooting, refining the collection pipeline, and prioritizing high-value access. No jailbreak was documented and commercial Claude was accessed through the standard API.

Bissa harvested .env files specifically for AI provider credentials (Anthropic, OpenAI, Groq, Mistral, OpenRouter, HuggingFace, Replicate, DeepSeek). AI provider credentials have become a deliberate target, valuable enough for sophisticated operators to enumerate and harvest at scale alongside conventional credential theft. These credentials are likely intended to be used in future offensive criminal activity and attribute it to the legitimate account holder instead of the attacker.

Agentic Configuration Files: A Persistent Attack Surface

The previous section demonstrates the use of agentic configuration files to override safety features in their own AI sessions. The same inheritance mechanism can be used in reverse: an attacker plants malicious agentic configuration files in a repository, and an innocent developer uses the project and becomes the next victim.

A recent CPR report documented three exploitation paths and disclosed two (now patched) CVEs. CVE-2025-59536 exploits Claude Code’s Hooks feature (hooks, .claude/settings.json), executing arbitrary commands before the developer can read them. A parallel path uses .mcp.json to trigger the MCP server startup, bypassing the consent dialog entirely. CVE-2026-21852 redirects ANTHROPIC_BASE_URL to a malicious proxy that intercepts authorization headers and potentially steals API keys, granting read/write access to the entire team Workspace before any trust prompt appears. The attack vector in all three cases is “supply chain”, a malicious settings file embedded in a pull request, honeypot repository, or compromised codebase that results in system compromise on the developer machine.

The underlying issue of using agentic configuration files as the attack surface and supply chain is not specific to Claude. The potential attack surface is architectural and may apply equally to Cursor (.cursorrules), Windsurf (.windsurfrules), and GitHub Copilot Workspace (.github/copilot-instructions.md).

AI-Powered Fraud at Scale: EvilTokens

EvilTokens represents a category of offensive tooling offered for sale: a commercial Phishing-as-a-Service (PhaaS) platform, built using AI and operating an LLM pipeline as a runtime component of the attack. A buyer with no AI knowledge can purchase access to a fully integrated pipeline in which model selection, jailbreak, and output delivery are handled at the platform level.

EvilTokens runs a multi-stage attack flow. Device-code phishing pages impersonating Adobe, DocuSign, and SharePoint harvest Microsoft OAuth tokens. The AI pipeline then activates these tools:

• Via Groq, llama-3.1-8b-instant ingests up to 5,000 emails in 250-email batches, extracting account numbers, routing numbers, wire amounts, payment deadlines, and reporting hierarchies.
• Also via Groq, llama-3.3-70b-versatile synthesizes the intelligence, generates BEC (Business Email Compromise) drafts tailored to the victim’s writing style, and assigns a BEC score.
• gpt-4o-mini translates stolen emails for non-English-speaking operators.
• The SMTP Sender delivers the output with rotating SMTP pools, header fingerprint randomization, DKIM signing, and CSS randomization.

The researchers assessed with high confidence that the platform’s backend was AI-generated.

The model choices reflect deliberate task routing: Llama 3.1 8B was used for cheap high-volume extraction, Llama 3.3 70B for reasoning-heavy synthesis and stylistic mimicry, and GPT-4o-mini was reserved for translation where it has the strongest multilingual capability and where the task itself looks innocuous to provider-side monitoring. The riskiest content generation is kept on Groq-hosted open-weight models instead of on OpenAI’s more closely monitored surface.

The jailbreak is the product. Both Groq-hosted LLaMA stages operate under a jailbreak embedded at the platform level, not applied by the operator and not visible to the customer. Stage 1 frames the model as an “authorized red team security analyst” conducting “sanctioned penetration tests”; Stage 2 upgrades to “senior red team analyst.” Prompts direct the model to reference real email threads, mask payment changes behind “plausible business reasons”, imitate sender style, and generate emails “realistic enough to fool a trained employee.” This is security bypass at SaaS scale: write the jailbreak once, ship it as a feature, and it’s inherited in every customer session.

The original EvilTokens advertising posts reveal additional features, including a Calendar Invite module which sends fake meeting invitations that appear as legitimate Outlook and Gmail meeting requests, with built-in Sender Spoofing (Organizer Identity). In a BEC context, this is used to apply timing pressure on finance personnel: a fake “urgent review meeting” appears on the target’s calendar shortly before a wire-transfer request lends the request a sense of pre-authorized context. Combined with the AI-generated email and the SMTP Sender, this completes a full BEC social engineering toolkit covered end-to-end by a single PhaaS offering.

EvilTokens’ Telegram channel announced additional AI-based features after Sekoia’s disclosure. The platform did not go offline and accelerated its AI feature development through April 2026.

The Vulnerability Race: AI on Both Sides of the Patch Window

AI-assisted vulnerability research has become a category in its own right and is now commercialized at both major frontier labs simultaneously on two tiers: a restricted research-grade capability and a productized defender tool.

At the frontier, Anthropic’s Claude Mythos, released through Project Glasswing, reportedly demonstrated a systematic, rapid mechanism to search for vulnerabilities and revealed a very large number of vulnerabilities, some long-buried zero-days in core infrastructure. These include a 27-year-old OpenBSD TCP/SACK bug found at roughly $20,000 in compute, a 16-year-old FFmpeg H.264 codec flaw, and a FreeBSD NFS remote code execution vulnerability in software that was analyzed for decades. The capability jump within a single generation is steep: on the same Firefox test set, Opus 4.6 produced 2 successful exploits and Mythos produced 181. Anthropic notes that this capability was not explicitly trained for but “emerged as a downstream consequence of general improvements in code, reasoning, and autonomy.” The productized tier is wider and more accessible: Claude Security (running on the public Opus 4.7 model) entered public beta for Enterprise customers, and OpenAI’s Codex Security, in research preview since early March, has had 14 CVEs assigned during the preview window on OpenSSH, GnuTLS, libssh, PHP, and Chromium.

The same capability curve is reaching attackers at the commodity tier, faster than defenders can patch. A researcher using a standard Claude API subscription identified CVE-2026-34197, a 13-year-old Apache ActiveMQ remote code execution vulnerability, and attributed roughly 80% of the work to Claude and the remainder to his refinement. LMDeploy SSRF (CVE-2026-33626) was exploited within 12 hours of the advisory publication, with no public proof-of-concept available. This time-frame compression is consistent with attackers building working exploits directly from advisory text. GenAI is accelerating this workflow.

Vendors are using AI to find vulnerabilities that sat undiscovered in core infrastructure for decades while attackers are using AI to find and weaponize newly-disclosed vulnerabilities within hours of publication. The patch window, the period between disclosure and exploitation, is being compressed on both sides. Vendors and customers need to adjust to a new high rate of patch development, delivery and deployment. The side that reacts the fastest will gain the most from recent AI developments.

Enterprise Adoption and Exposure

Corporate environment data collected by Check Point in March – April 2026 shows enterprise GenAI usage continuing to scale while the associated risk profile remains stable. Approximately one in every 28 prompts (3.6%) posed a high risk of sensitive data exposure, a modest increase from the January–February baseline of 3.2%, observed across 91% of organizations actively using GenAI tools (compared with 90% in the previous period). The proportion of prompts containing potentially sensitive information rose from 16% to 18%.

The average employee generated 78 prompts during March – April, up from 69, with organizations using an average of 10 GenAI tools. Interaction volume is rising while risk ratios remain stable, producing a proportional increase in absolute exposure events.

The consistency of these metrics across two reporting periods indicates a maturing adoption pattern: data exposure is not an episodic incident category but a continuous operational risk requiring sustained monitoring and policy enforcement.

Conclusion

Our findings converge on a small number of structural observations.

• AI now operates as an attack component, not just as a development aid. The Mexican breach illustrates this at government-breach scale, and Bissa at mass-exploitation scale. The same commercial Claude Code architecture appears independently across criminal operations with different motivations and geographies, and in state-sponsored espionage. The convergence is operational consensus, not coincidence.
• The techniques aren’t new but the performance envelope is. Network scanning, credential spraying, lateral movement, BEC drafting, and vulnerability research all predate AI. What’s changed is the speed (working exploits generated from advisory text alone within 12 hours of disclosure), scale (one operator reaching the operational footprint of an advanced team), and breadth of knowledge (cross-domain expertise on demand lowers the entry requirement for sophisticated multi-vector campaigns). Defences calibrated to human attack tempo and human team throughput are not equipped for the AI equivalents.
• The AI attribution gap is structural. All the operations we documented in this report were discovered through attacker OPSEC failures or LLM provider monitoring, not through victim-side controls. AI-executed commands resemble skilled human activity closely enough to evade current behavioral controls. Operations that do not fail at OPSEC, or that route through stolen credentials or self-hosted models, remain unclassified.

The post AI Threat Landscape Digest March-April 2026 appeared first on Check Point Research.

Key Takeaways

• Sensitive data shared with ChatGPT conversations could be silently exfiltrated without the user’s knowledge or approval.
• Check Point Research discovered a hidden outbound communication path from ChatGPT’s isolated execution runtime to the public internet.
• A single malicious prompt could turn an otherwise ordinary conversation into a covert exfiltration channel, leaking user messages, uploaded files, and other sensitive content.
• A backdoored GPT could abuse the same weakness to obtain access to user data without the user’s awareness or consent.
• The same hidden communication path could also be used to establish remote shell access inside the Linux runtime used for code execution.

What Happened

AI assistants now handle some of the most sensitive data people own. Users discuss symptoms and medical history. They ask questions about taxes, debts, and personal finances, upload PDFs, contracts, lab results, and identity-rich documents that contain names, addresses, account details, and private records. That trust depends on a simple expectation: data shared in the conversation remains inside the system.

ChatGPT itself presents outbound data sharing as something restricted, visible, and controlled. Potentially sensitive data is not supposed to be sent to arbitrary third parties simply because a prompt requests it. External actions are expected to be mediated through explicit safeguards, and direct outbound access from the code-execution environment is restricted.

Our research uncovered a path around that model.

We found that a single malicious prompt could activate a hidden exfiltration channel inside a regular ChatGPT conversation.

The Intended Safeguards

ChatGPT includes useful tools that can retrieve information from the internet and execute Python code. At the same time, OpenAI has built safeguards around those capabilities to protect user data. For example, the web-search capability does not allow sensitive chat content to be transmitted outward through crafted query strings. The Python-based Data Analysis environment was designed to prevent internet access as well. OpenAI describes that environment as a secure code execution runtime that cannot generate direct outbound network requests.

OpenAI also documents that so called GPTs can send relevant parts of a user’s input to external services through APIs. A GPT is a customized version of ChatGPT that can be configured with instructions, knowledge files, and external integrations. GPT “Actions” provide a legitimate way to call third-party APIs and exchange data with outside services. Actions are useful for enterprise workflows, access to internal business systems, customer support operations, and other integrations that connect ChatGPT to external services, including simpler use cases such as travel or weather lookups. The key point is visibility: the user sees that data is about to leave ChatGPT, sees where it is going, and decides whether to allow it.

In other words, legitimate outbound data flows are designed to happen through an explicit, user-facing approval process.

From One Message to Silent Exfiltration

From a security perspective, the obvious attack surfaces looked strong. The ability to send chat data through tools not designed for that purpose was strictly limited. Sending data through a legitimate GPT integration using external API calls also required explicit user confirmation.

The vulnerability we discovered allowed information to be transmitted to an external server through a side channel originating from the container used by ChatGPT for code execution and data analysis. Crucially, because the model operated under the assumption that this environment could not send data outward directly, it did not recognize that behavior as an external data transfer requiring resistance or user mediation. As a result, the leakage did not trigger warnings about data leaving the conversation, did not require explicit user confirmation, and remained largely invisible from the user’s perspective.

At a high level, the attack began when the victim sent a single malicious prompt into a ChatGPT conversation. From that moment on, each new message in the chat became a potential source of leakage. The scope of that leakage depended on how the prompt framed the task for the model: it could include raw user text, text extracted from uploaded files, or selected model-generated output such as summaries, medical assessments, conclusions, and other condensed intelligence. This made the attack flexible, because it allowed the attacker to target not only original user data, but also the most valuable information produced by the model itself.

That attack pattern fits naturally into ordinary user behavior. The internet is full of websites, blog posts, forums, and social media threads promoting “top prompts for productivity,” “best prompts for work,” and other ready-made instructions that supposedly improve ChatGPT’s performance. For many users, copying and pasting such prompts into a new conversation is routine and does not appear risky, because the prevailing expectation is that AI assistants will not silently leak conversation data to external parties, and that this boundary cannot be changed through an ordinary prompt. A malicious prompt distributed in that format could therefore be presented as a harmless productivity aid and interpreted as just another useful trick for getting better results from the assistant.

A broader campaign could use an even more convincing lure: prompts advertised as a way to unlock premium capabilities for free. Claims about enabling Pro-level behavior, hidden modes, or advanced features on a lower-tier account would give the attacker a natural pretext for including unusual instructions, long text blocks, or opaque fragments that might otherwise seem suspicious. Because the user already expects a nonstandard sequence, those elements can easily be perceived as part of the promised “hack.” A carefully crafted prompt could then create the appearance of enhanced functionality while quietly turning the conversation into a source of exfiltrated data.

Once the malicious prompt was placed into the chat, the conversation effectively became a covert collection channel. From that point on, summaries of subsequent user messages could be silently transmitted to an attacker-controlled server. As shown in Video 1, this took place without any warning, approval request, or other visible indication of external data transfer.

Malicious GPTs

The same attack pattern becomes even more dangerous when embedded inside a custom GPT.

GPTs allow developers to package instructions, knowledge files, and external integrations into a reusable assistant that other users can interact with. From the user’s perspective, the interaction looks like a normal ChatGPT conversation with a specialized tool.

In that scenario, the attacker no longer needs to rely on the victim copying a prompt from an external source. The malicious logic can be embedded directly in the GPT’s instructions and files. A user only needs to open the GPT and begin interacting with it as intended.

This changes the threat model significantly. Officially, GPT builders do not have access to individual user conversations with their GPTs. However, a GPT designed to exploit the vulnerability could still cause selected information from those conversations to be transmitted to an attacker-controlled server. From the user’s perspective, the interaction would remain indistinguishable from an ordinary session with a specialized assistant.

To demonstrate the practical impact of the vulnerability, we built a proof of concept around a sensitive scenario: a GPT acting as a personal doctor.

In the demonstration, the user uploaded a PDF containing laboratory test results. The document also contained personal information, including the patient’s name. The user then described symptoms and asked the GPT to help interpret the results.

From the user’s perspective, the interaction looked completely ordinary. The GPT analyzed the document and produced a medical assessment based on the provided information.

When asked directly whether the uploaded data had been sent anywhere, ChatGPT answered confidently that it had not, explaining that the file was only stored in a secure internal location. At the same time, the user saw no approval prompts or warnings about external data transfer, unlike the confirmation dialogs that normally appear when a GPT Action sends information to a third-party service.

Meanwhile, the attacker’s server received highly sensitive data extracted from the conversation: the patient’s identity taken from the uploaded document together with the model’s medical assessment.

This illustrates an important aspect of the attack. The attacker does not necessarily need to steal entire documents. Instead, the prompt could instruct the model to transmit the most valuable information it produces. In the medical scenario, that meant the patient’s identifying details together with the model’s assessment. In other contexts, it could mean financial conclusions, contract summaries, or strategic insights extracted from long documents.

From Data Exfiltration to Remote Shell

The same communication channel could be used for more than silent data exfiltration.

Once a reliable bidirectional channel existed between the execution runtime and the attacker-controlled server, it became possible to send commands into the container and receive the results back through the same path. In effect, the attacker could establish a remote shell inside the Linux environment that ChatGPT creates to perform code execution and data analysis tasks.

This interaction happened outside the normal ChatGPT response flow. When users interact with the assistant through the chat interface, generated actions and outputs remain subject to the model’s safety mechanisms and checks. However, commands executed through the side channel bypassed that mediation entirely. The results were returned directly to the attacker’s server without appearing in the conversation or being filtered by the model.

DNS Tunneling in an AI Runtime

The side channel that enabled both data exfiltration and remote command execution relied on DNS resolution.

Normally, DNS is used to resolve domain names into IP addresses. From a security perspective, however, DNS can also function as a data transport channel. Instead of using DNS only for ordinary name resolution, an attacker can encode data into subdomain labels and trigger resolution of those hostnames. Because DNS resolution propagates the requested hostname through the normal recursive lookup process, the resolver chain can carry that encoded data outward.

In our case, this mattered because the ChatGPT execution runtime did not permit conventional outbound internet access, but DNS resolution was still available as part of the environment’s normal operation. Standard attempts to reach external hosts directly were blocked. DNS, however, still provided a narrow communication path that crossed the isolation boundary indirectly through legitimate resolver infrastructure.

To exfiltrate data, content could be encoded into DNS-safe fragments, placed into subdomains, and reconstructed on the attacker’s side from the incoming queries. To send instructions back, the attacker could encode small command fragments into DNS responses and let them travel back through the same resolution path. A process running inside the container could then read those responses, reassemble the payload, and continue the exchange.

This effectively turned DNS infrastructure into a tunnel between the isolated runtime and an attacker-controlled server. The tunnel create in this way is sufficient for two practical goals: silently leaking selected data from the conversation and maintaining command execution inside the Linux environment created for code execution and data analysis.

Conclusion

Check Point Research reported the issue to OpenAI. OpenAI confirmed that it had already identified the underlying problem internally, and the fix was fully deployed on February 20, 2026.

The broader lesson, however, goes beyond this specific case. AI systems are evolving at an extraordinary pace. New capabilities are constantly being introduced, enabling assistants to solve complex mathematical problems, analyze large datasets, generate and execute scripts, and automate multi-step tasks that previously required dedicated development environments. These capabilities bring enormous benefits. At the same time, every new tool expands the system’s attack surface and can introduce new security challenges for both users and platform providers.

Modern AI assistants increasingly operate as real execution environments. They read files, run code, search in the web while processing highly sensitive information such as medical records, financial data, legal documents, and other personal or organizational data. Protecting these environments requires careful control over every possible outbound communication path, including infrastructure layers that users never see.

As AI tools become more powerful and widely used, security must remain a central consideration. These systems offer enormous benefits, but adopting them safely requires careful attention to every layer of the platform.

The post ChatGPT Data Leakage via a Hidden Outbound Channel in the Code Execution Runtime appeared first on Check Point Research.

KEY FINDINGS

AI-assisted malware development has reached operational maturity.
VoidLink framework, which is modular, professionally engineered, and fully functional, was built by a single developer using a commercial AI-powered IDE within a compressed timeframe. AI-assisted development is no longer experimental but produces deployment ready output.

AI-assisted development is not always obvious from the final product.
VoidLink was initially assessed as the work of a coordinated team based on its architecture and implementation quality. The development method was exposed not from analyzing the malware but through an operational security failure. AI-assisted development should be considered a possibility from the outset, not as an afterthought.

Adoption of self-hosted, open-source AI models is growing but still limited in practice.
Actors of varying skill levels are investing in self-hosted and unrestricted models to avoid commercial platform restrictions. However, underground discussions consistently reveal a gap between aspiration and capability: local models still underperform, finetuning remains aspirational, and commercial models remain the productive choice even for actors with explicit malicious intent.

Jailbreaking is shifting from direct prompt engineering toward agenticarchitecture abuse.
Traditional copy-paste jailbreaks are increasingly ineffective. The misuse of AI agent configuration mechanisms, specifically project files that redefine agent behavior, is a more significant development as it represents a qualitative shift from manipulating a
model’s responses to abusing its operational architecture.

AI is showing early signs of deployment as a real-time operational component. Beyond its use as a development aid, AI is beginning to appear as a live element in offensive workflows as autonomous agents performing security research tasks, and
LLMs classifying and engaging targets at scale within automated pipelines.

Enterprise AI adoption is itself an expanding attack surface.
GenAI activity across enterprise networks shows that one in every 31 prompts risked sensitive data leakage, impacting 90% of GenAI-adopting organizations.

INTRODUCTION

During January-February 2026, cyber crime ecosystems continue to adopt AI in a widespread but uneven pattern. Throughout 2025, legitimate software development began shifting from promptbased AI assistance to agent-based development. Tools such as Cursor, GitHub Copilot, Claude Code, and TRAE introduced a common paradigm: developers write structured specifications in markdown files, and AI agents autonomously implement, test, and iterate code based on those instructions. This agentic model, in which markdown is the operative control layer, is now starting to appear across the threat landscape.

The critical differentiator in what we observed is AI methodology combined with domain expertise. Across cyber crime forums, the dominant pattern of AI use remains unstructured prompting: actors request malware or exploit code from AI models as if entering a query in a search engine. VoidLink (detailed below) on the other hand, is the first documented case of AI producing truly advanced, deploymentready malware. The developer combined deep security knowledge with a disciplined, spec-driven
workflow to produce results indistinguishable from professional team-based engineering. Forum activity, which constitutes the bulk of observable evidence, primarily consists of actors who have not yet adopted structured AI workflows and whose efforts remain relatively unsophisticated. The more capable actors, those who combine domain expertise with disciplined AI methodology, leave far fewer traces in open forums, making the true scope of this shift harder to measure.

VOIDLINK: THE STANDARD WE MEASURE AGAINST

In January 2026, Check Point Research (CPR) exposed VoidLink, a Linux-based malware framework featuring modular command-and-control (C2) architecture, eBPF and LKM rootkits, cloud and container enumeration, and more than 30 post-exploitation plugins. The framework is highly sophisticated and professionally engineered, so much so that the initial assessment was that VoidLink was likely the product of a coordinated, multi-person development effort conducted over months of intensive development.

Operational security (OPSEC) failures by the developer later exposed internal development artifacts that told a different story. These materials revealed that VoidLink was authored by a single developer using TRAE SOLO, the paid tier of ByteDance’s commercial AI-powered IDE. Instead of unstructured prompting, the developer used Spec Driven Development (SDD), a disciplined engineering workflow, to first define the project goals and constraints, and then use an AI agent to generate a comprehensive architecture and development plan across three virtual teams (Core, Arsenal, and Backend). The resulting plan included sprint schedules, feature breakdowns, coding standards, and acceptance criteria, all documented as structured markdown files. The AI agent implemented the framework sprint by sprint, with each sprint producing working, testable code. The developer acted as product owner, directing, reviewing, and refining, while the AI agent did the actual work.

The results were striking. The recovered source code aligned so closely with the specification documents that it left little doubt that the codebase was written to those exact instructions. What normally would have been a 30-week engineering effort across three teams was executed in under a week, producing over 88,000 lines of functional code. VoidLink reached its first functional implant around December 4, 2025, one week after development began.

THIS CASE ESTABLISHES TWO PRINCIPLES:

• AI-assisted development now produces operationally viable, deployment-ready malware: it has crossed the threshold from experimental to functional.
• The AI involvement was invisible until it was exposed by an unrelated OPSEC failure. For analysts and defenders, this means AI involvement in malware development should be treated as a default working assumption, even when there are no visible indicators

The ramifications of VoidLink’s methodology go beyond this individual case. Its workflow, in which structured markdown specifications direct an AI agent to autonomously implement, test, and iterate, is the same paradigm that defined the agentic AI revolution in legitimate software development throughout 2025. The cyber crime ecosystem is not developing its own AI capability. It is adopting the same tools and architectural patterns as legitimate technology, with the additional goal of trying to overcome the protective limitations built into these systems. This is more important than which model or platform the attackers use.

The same architectural pattern repeatedly appears across the cases highlighted in our report: markdown skill files that transform a coding agent into an autonomous offensive security operator, and configuration files abused to override agent safety controls. In each case, the operative control layer is not code but structured documentation that determines what the AI agents build, how they behave, and what constraints they observe or ignore. This is in direct contrast to the underground forum activity, where the dominant approach remains unstructured prompting.

MODELS: COMMERCIAL, SELF-HOSTED, AND INFORMAL SERVICES

SELF-HOSTED OPEN-SOURCE MODELS

Across cyber crime forums, actors at all skill levels are actively exploring self-hosted, open-source AI models as alternatives to commercial platforms. Their motivations are consistent: to avoid moderation, prevent account bans, and maintain operational privacy.

Users with malware and hacking backgrounds are installing uncensored model variants such as wizardlm-33b-v1.0-uncensored and openhermes-2.5-mistral, and prompt them with comprehensive malicious wishlists spanning ransomware, keyloggers, phishing kits, and exploit code.

More established actors are conducting structured cost-benefit analyses, evaluating not only hardware requirements and GPU costs but whether locally hosted models produce reliable output (or hallucinate to the point of being operationally useless), and whether AI-generated malware meets the quality bar of current evasion techniques.

SELF-HOSTED MODELS: LIMITATIONS IN PRACTICE

Self-hosted models consistently show a gap between aspiration and capability. Community advice on improving local model output focuses on basic optimizations, such as switching to English-language prompts and increasing quantization levels, while references to more advanced techniques such as LoRA fine-tuning remain aspirational rather than operational.

Cost estimates range from $5,000 to $50,000 depending on the desired performance, with training timelines of 3–12 months and frank admissions that models “hallucinate a lot” without extensive investment.

Most tellingly, an active offensive tools vendor, advertising C2 setups, EDR bypass services, and red team tooling, concluded that local deployment is currently “more of a burden than something productive,” while acknowledging that commercial models remain useful despite increasing restrictions.

COMMERCIAL PLATFORMS AND INFORMAL ACCESS SHARING

Rather than migrating to self-hosted infrastructure, users are comparing what the prevailing workarounds among commercial models provide. Participants recommended specific providers they view as less restrictive, shared experiences with account enforcement on multiple platforms, and refined prompt-splitting techniques to incrementally bypass safeguards, such as requesting explanations before progressing toward executable code.

Some early signs of informal access sharing have been observed, with operators of local models offering to generate restricted outputs for others on request. However, given the historical precedent of “dark LLM” services that largely failed to deliver on their promises, it remains to be seen whether these will develop into durable service models.

JAILBREAKING AS ARCHITECTURAL ABUSE

Traditional jailbreaking, the practice of circulating copy‑paste prompts designed to trick models into producing restricted output, is becoming increasingly difficult to utilize. In some forum discussions, users seeking Claude jailbreaks were told that easy public prompts are no longer available, platforms have been cracking down on abusers, dedicated subreddits have been banned, and developing new jailbreaks is costly because the accounts are eventually terminated. Single‑prompt jailbreaking is becoming less attractive as model providers invest in safety enforcement.

ABUSING AGENT ARCHITECTURE

A more significant development is the emergence of jailbreaking techniques that target the architecture of AI agent systems rather than the model’s conversational safeguards. A packaged “Claude Code Jailbreak” distributed on forums illustrates this shift.

Claude Code is designed to read a CLAUDE.md file from a project’s root directory as configuration. Legitimate developers use this mechanism to define the project context, coding standards, and agent behavior. The jailbreak abuses this by placing override instructions in the CLAUDE.md file that suppresses safety controls and redefines the agent’s role. When Claude Code initializes in the directory, it reads these instructions as authoritative project configuration and follows them. The screenshots below claim successful generation of a RAT (Remote Access Trojan) using this method.

This is not prompt injection in the traditional sense, but manipulation of the agent’s instruction hierarchy, the same architecture used for agentic AI tools in legitimate development. The CLAUDE. md file occupies the same functional role as VoidLink’s markdown specification files or RAPTOR’s skill definitions: a structured document that determines what the agent does, how it behaves, and what constraints it observes.

FROM DEVELOPMENT TOOL TO OPERATIONAL AGENT

The preceding sections document AI as a development aid (as seen by VoidLink), a resource actors struggle to access on their own terms (self-hosted models), and as a system whose restrictions they attempt to bypass (jailbreaking). Now let’s look at AI deployed as a real-time operational component, performing offensive tasks autonomously within live workflows.

RAPTOR: AGENT-BASED OFFENSIVE ARCHITECTURE VIA MARKDOWN SKILLS

RAPTOR’s own data provides an additional data point on the commercial versus self-hosted question we discussed earlier. An evaluation of exploit generation across multiple model providers found that commercial frontier models (Anthropic Claude, OpenAI GPT-4, and Google Gemini) consistently produce compilable C code at approximately $0.03 per vulnerability, while locally hosted models via Ollama were marked as “often broken” and unreliable for exploit generation. This reinforces the conclusion reached independently by experienced actors in underground forums: commercial models remain significantly more capable than self-hosted alternatives for operational tasks.

Discussions on criminal forums indicate that threat actors are aware of this architecture. The combination of a proven architectural pattern, open source availability, and documented criminal interest suggests that similar configurations, whether directly based on RAPTOR or just replicating its approach, are likely being developed and tested privately.

AI AS ATTACK SURFACE: ENTERPRISE EXPOSURE

The preceding sections document how threat actors engage with AI as an offensive tool. But the same wave of AI adoption is simultaneously creating exposure from the defensive side. As enterprises integrate generative AI into daily workflows, the volume of sensitive data flowing through these tools introduces a distinct category of risk: instead of AI weaponized against organizations, AI is adopted by organizations in ways that outpace security controls.

In January – February 2026, corporate use of generative AI tools continued to expand at scale. Analysis of GenAI activity across enterprise networks shows that one in every 31 prompts (approximately 3.2%) posed a high risk of sensitive data leakage, including the potential sharing of confidential business information, regulated data, source code, or other sensitive corporate content with external GenAI services.

Critically, this risk is broadly distributed across the enterprise landscape rather than limited to a small number of outliers. High-risk prompt activity impacted 90% of organizations that use GenAI tools on a regular basis, indicating that nearly all GenAI-adopting enterprises encounter meaningful data leakage risk through everyday AI usage. Beyond these clearly high-risk events,16% of prompts contained potentially sensitive information, reflecting a wider pattern of questionable data-handling behavior that can still translate into compliance exposure or IP loss.

Adoption trends further amplify the challenge. Over the last couple of months, organizations used 10 different GenAI tools on average, reflecting multi-tool environments. At the user level, an average employee generated 69 GenAI prompts per month. As prompt volume grows, the possibility of data exposure events scales accordingly, reinforcing the need for security policies, visibility, and real-time prevention controls.

The post AI Threat Landscape Digest January-February 2026 appeared first on Check Point Research.