Bypassing Imperva Incapsula WAF with a Cookie Jar Overflow

Before we get into it — this vulnerability has been patched for quite a while now. I'm only disclosing this because Imperva have long since fixed the issue and this technique no longer works against current Incapsula deployments.

The Problem

Anyone who's dealt with Imperva's Incapsula WAF will know the pain of the reese84 token. It's generated client-side after a bunch of browser fingerprinting checks and in some cases a successful CAPTCHA solve. Without a valid reese84 cookie, your requests either get blocked or served a challenge page.

The usual flow goes something like this:

1. Client hits the protected site
2. Incapsula serves a JavaScript challenge
3. The browser runs the challenge, does its fingerprinting, and optionally throws up a CAPTCHA
4. A valid reese84 token gets generated and set as a cookie
5. Subsequent requests include this token and get let through to the origin

Generating a valid reese84 token programmatically is a nightmare. You either need a full browser environment or you're reverse engineering obfuscated JavaScript that Imperva rotates regularly. Neither option is fun.

The Discovery

I was poking around with different approaches to get past the reese84 check when I stumbled onto something interesting — a cookie jar overflow. The idea is simple: browsers and web servers have limits on how many cookies they'll store and how large a cookie header can be. By sending an absurdly large cookie value you can cause the server-side parser to behave in unexpected ways.

I found that by sending a massively oversized reese84 cookie value, Incapsula just... let me through. No valid token needed.

The Bypass

The implementation couldn't have been simpler. I just set the reese84 cookie to an extremely long repeated character:

request.Headers.Add("cookie", "reese84=" + new string('-', 4096) + ";");

That's it. The actual character didn't matter either — I tested with hyphens and question marks and both worked just fine. It likely would have worked with any character, the important part was the length. The value just needed to be long enough to exceed whatever size limit Incapsula was using.

With this cookie set, requests went straight through to the origin server as if I had a perfectly valid reese84 token. No browser fingerprinting, no CAPTCHA solving, no reversing obfuscated JavaScript. Just a very long string of repeated characters.

Why I Think It Worked

I believe the oversized cookie value exceeded a size limit in Incapsula's validation layer, causing it to skip the reese84 check entirely. Rather than rejecting the request when the cookie was too large to parse, the WAF appears to have fallen back to a permissive mode — effectively bypassing the entire bot detection mechanism.

It's a classic fail-open scenario. When the validation couldn't handle the input, instead of blocking the request it just waved it through.

Conclusion

And there we have it! This was one of those finds where the complexity of the protection was completely undermined by something trivial. Sometimes the bypass isn't a clever cryptographic attack — it's just sending more data than expected.

This highlighted the importance of:

• Validation logic failing closed — if a token can't be parsed, the request should be blocked, not allowed through
• Size limits on cookie values being enforced before any parsing logic runs
• Testing boundary conditions when you're up against a WAF — oversized values, empty values, and malformed encodings are always worth a shot