How to Bypass reese84 in 2026 (Imperva Incapsula)

In this post we’re going to look at reese84 - Imperva Incapsula’s sensor challenge - and how to get past it without running a browser.

reese84 is what sits between your scraper and a lot of Incapsula-protected sites. Hit one without a valid reese84 cookie and you don’t get the page, you get a “Pardon Our Interruption” block. So the job is simple to state: get a reese84 cookie the site will accept, then carry on. The rest of this post is how.

What reese84 actually is

reese84 is Incapsula’s client-side sensor. Load a protected page and the site runs an obfuscated script that collects a load of signals about your browser, then posts them back. If Incapsula is happy, it hands you a reese84 token - a cookie - and lets you through. No valid cookie, no access.

The script is heavily obfuscated, and they recently updated the script to use a custom bytecode JavaScript VM. The team actually did a fairly good job of implementing the VM, it isn’t your usual stack/register VM, it instead uses a series of thunks that evaluate when they become saturated. They also changed the payload format to be a flat binary stream, instead of a JSON object.

The VM is also dynamic, which means you need to disassemble it for each solve request you want to make.

How Incapsula decides you’re a bot

It’s not one check. It’s a stack of them, and they all have to line up:

TLS fingerprint. Your ClientHello has to match the browser you claim to be. A default Go or Python client doesn’t, and that’s an easy flag.
Headers and their order. Incapsula reads your headers and expects the order real Chrome sends them in.
The sensor data. The reese84 script collects browser-environment signals, and they have to agree with your headers and your TLS.
IP and behaviour. Datacenter IPs score badly, and requests that don’t look like normal browsing stand out.

The cookie is only half the story. A reese84 cookie you earned with one fingerprint won’t survive if the requests you send afterwards look like something else. Everything has to tell the same story.

Two ways past it

Once you’ve decided not to drive a full browser, there are two routes.

The first is to reverse the sensor script yourself. Pull it down, deobfuscate it, work out what it collects and how it encodes the payload, then rebuild the payload. Solving it yourself would involve writing a disassembler, a decompiler and a parser to extract out the information you need to build the payload.

The second is to hand the script to a solver that builds the payload for you, submit it, and take back a cookie. No browser, no script execution on your side. That’s disasm.dev, and it’s what the walkthrough below uses.

Here’s the flow end to end. The base URL is https://incap.antibotapi.com and your key goes in the x-api-key header.

Spot the block. A protected request comes back as the “Pardon Our Interruption” page instead of the content you asked for.
Find the reese84 endpoint. In that page, look for a script tag the site injected. Its src is a long, random-looking path on the same domain - something like /GEDIE-OF-MACBETH-king-Were-Throws-our-Chield-who/6913314970835659247?s=gLmE3ZfY. Join it to the site’s origin and that’s your incapsula_url.
Fetch that script and base64-encode it.
Send it to us. POST the page URL, the script URL, the encoded script and your user agent to /reese84:

curl -X POST https://incap.antibotapi.com/reese84 \
  -H "x-api-key: YOUR_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "page_url": "https://www.pokemoncenter.com/",
    "incapsula_url": "https://www.pokemoncenter.com/GEDIE-OF-MACBETH-king-Were-Throws-our-Chield-who/6913314970835659247?s=gLmE3ZfY",
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36",
    "script_b64": "<base64 of the script from step 3>"
  }'

Submit the solution. We return a solution. Post it to the site’s reese84 endpoint and you get a token back - that token is your reese84 cookie.
Store the cookie and retry. Drop it in your jar and replay the original request. You’re through.

There are two optional fields as well: language (the navigator.language to bake into the payload) and pow, which you won’t need unless support tells you otherwise. The full reference is in the reese84 guide.

The other Incapsula challenge: ___utmvc

Some Incapsula sites still use the older ___utmvc cookie, on its own or alongside reese84. It works the same way - find the utmvc script, fetch it, send it to our /utmvc endpoint, and get a cookie back. If you hit a site and reese84 isn’t there, check for this instead.

The part that decides whether it works

A correct payload from the wrong client is still a block. So before you blame the solver:

Match Chrome’s TLS fingerprint. Default Go, Python and Node stacks don’t, and Incapsula notices straight away. Use a client that reproduces it - we use httpcloak.
Send the same user agent everywhere. The UA you give us has to match the one you use on the real requests. If they differ, the cookie won’t hold.
Get your headers and their order right, and keep your requests looking like normal browsing - a real referer, a sensible path through the site.

Get those wrong and you’ll keep seeing the interruption page no matter how good the payload is.

In conclusion

So that’s reese84: an obfuscated sensor that scores your browser and your behaviour, hands you a cookie when it’s convinced, and blocks you when it isn’t. You get past it by building the sensor payload, submitting it for a cookie, and then sending everything afterwards from a client that looks like the browser you claimed to be.

And if you’d rather not maintain a sensor solver through every Incapsula change, that’s what disasm.dev is for - reese84 and ___utmvc from a single HTTP call. There’s a free trial, the guides are in the docs, and the Discord is there if you get stuck.

How to Bypass reese84 in 2026 (Imperva Incapsula)▋