I will admit, as this is my personal blog, that I’m not the biggest LLM fan. I do not believe the hype that this is going to further revolutionize cybersecurity in the sense that I think it has furthered automation and that’s it, to me, that’s not really a praxis change.

However as a hacker I also believe it is important to adapt to tools and help in understanding how they can be attacked, and its adoption is undeniable. Please do not take this as the naive view of “AI is not THAT important”, but as a (I hope) informed bias disclosure for whomever it may concern.

Anyhow this post is meant to describe and approach a concept I first became familiar with 3 years ago in web hacking called HTTP Request Padding or sometimes called Junk Data Injection. Not from an academic standpoint - as I’m not an academic - but from a curiosity point of view. If it’s of any use to anybody else then this would have been a great use of my time. If you have anything you’d like to discuss or want to build from here please do let me know ideally via LinkedIn.

So what’s the point I’m trying to make

I do believe there’s a real analogy between WAF bypasses via HTTP Request Padding and Classifier bypasses. In this post I’ll try to prove why the current techniques indicate that this is an attack class worth adding to/ considering when creating taxonomies.

Basic introduction to HTTP Request Padding

This technique which from now on we will call HTRP is a WAF bypass mechanism that’s based on the assumption that cloud-based WAFs have an inherent cost-based CPU usage, and in sending increasingly bloated HTTP requests we can get the WAF to simply choose not to analyze that request in full either be it completely or just reading the first N bytes and then stopping.

If this drop goes according to our interest it will go through the WAF into the final endpoint instead of being dropped. In many cases I’ve observed this to be the case.

The manner in which we inject data into our HTRP adapted requests is via simply writing literal junk data into their body in such a manner that the request does not fall into malformation. This is oftentimes trivially done in both new and old web stacks.

Determinism of the attack

Like any WAF attacks determinism is based on the assumption that we are referring to a web based attack. However because we are actively bypassing a security measure most analysts would choose to employ CVSS4.0 modifiers like AC:H to any attack employing this technique.

However request padding works in such a manner that we can oftentimes accurately calculate how many bytes of junk data we will need to insert into a request to get it to bypass the WAF.

Calculating Padding Sizes

The original NoWafPls plugin simply provided a general list of bytes to insert into the request in order to bypass Cloud-based WAFs according to vendor and tier type.

I was dissatisfied with this as it was - forgive me for the pedantics - unelegant. And so developed a now forgotten WAF bypass tool called Caliper.py that could do binary searches based on request matching and response codes. It indeed pulled a very close number to the byte read limit I set on my WAF and that was that.

I also had the chance to use the tool in some pentests I performed during my career, but in most cases where HTRP worked other payload-based WAF bypass vectors emerged that were trivial to exploit in comparison.

Why I pivoted padding techniques to prompts

When doing CTFs aided to learn new techniques I sometimes work in conjunction with LLMs like Claude Opus 4.8 or 5 to spot what I may be missing in my writeups and getting tailored clues that don’t spoil the exercise.

As I’m on Anthropic’s Cyber Verification Programme it is rare for me to get cyber warnings asking me to edit prompt, but when I do they oftentimes brick the whole instance causing any subsequent messages to also be flagged as dangerous.

This is a nuisance.

I once tried to then paste a whole (extremely lengthy) Active Directory writeup into the edit box and send the message, to my surprise the chat begun replying again without those lengthy classifier pauses it used to have before.

Now I can certainly not prove this was a classifier bypass, so I’m not gonna claim it was one.

This led me into a bit of a rabbit hole to try and research if those attacks I had grown fond of in Web were also applicable on LLM hacking.

Here I’ll share some of what I found for whoever cares.

As disclosure, along with Google I did use LLMs to help find the applicable sources and also aid structure the techniques into specific slotted mechanisms for the sake of coming back to this easier when interested.

Padding Techniques on LLM Classifiers

Let’s begin with some decent previous reads:

And logically as usual I take inspiration in most LLM attacks reasoning from Jason Haddix’s Arcanum Sec.

A Mechanisms: Coverage Evasion

These are attacks on classifier coverage: the classifier never evaluates the malicious span at all. They are deterministic just like WAFs that are byte-limited. This category the closest structural equivalent to HTRP.

A1. Input truncation

Deployed guardrails are frequently small models with short, fixed input windows that discard anything past the limit.

Small context windows with truncation enabled are observable in the wild. Whatever falls beyond the limit is evaluated as though it were absent.

Truncation is itself a different issue: I found a documented case of head-only truncation, where a payload with a benign opening and a malicious tail was scored entirely on its opening. Padding the front to displace the malicious span past the limit, or exploiting the reverse condition where truncation is tail-side, reproduces the HTRP primitive of overrunning a WAF body-inspection limit.

Sources:

A2. Sliding-window scoring and its threshold economics

The standard remediation for A1 is to slide the classifier across the entire input in overlapping windows and flag if any window scores high, which is max-pooling.

This closes the naive truncation hole but reintroduces it economically. (!- I consider this another case for this type of vector being paid more attention to.)

Because the decision is a maximum taken over many windows, each additional window is another opportunity for a false positive, and false positives compound with window count as the input grows. (Somewhat realated to many-shot jailbreaks.)

I do not believe, however, that furthering the payload with generic data will in practice realistically create false positives in such a manner that matters when performing probabilistic testing.

Sources:

A3. Cost-gated inspection

At scale, not every request is subjected to the expensive classifier. Pipelines may use a cheap pre-filter, sample a fraction of traffic, or scan only inputs that appear suspicious to deep inspection.

A large, unremarkable wrapper can suppress whatever low-cost signal decides escalation, such that the expensive check is less often started. (We may compare this to a simple WAF governing wether or not a request warrants deep packet inspection.)

This is the most faithful to HTRP in spirit and the least represented in the formal literature as far as I know.

Sources:

B Mechanisms: Attention Dilution

These are attacks on classifier attention rather than coverage, they have no meaningful web analog.

The classifier reads the malicious section but distributes its attention across the whole content, so a small adversarial region inside a large benign one is under-weighted.

This category is probabilistic: padding raises the probability of evasion, it does not guarantee it. (!! This is the first real mention of probabilistic bypasses via padding.)

B1. Positional dilution

Attention is spread more thinly as the sequence lengthens, and content positioned in the middle competes with the greatest number of neighbours for weight, so it is attended least.

Measured accuracy drops are reported when the target span is moved from the edges to the middle of the context. Anecdotically I’ve experienced this during LLM Hacking challenges.

Padding exploits this by relocating the payload into that low-attention interior.

Sources:

B2. Length-induced safety degradation

The strongish result in recent work is that the padding need not be adversarial in content. (In fact I’d argue it’s logically better if it’s not.)

Two papers that mention this are Ninja, from Jailbreaking in the Haystack, reasons context length as the variable and demonstrates that refusal rates decline rapidly as benign context grows (again very much the point of this article), outpacing the very notable decline in general capability, and that innocuous padding is harder to detect than the injection of harmful examples.

Sources:

B3. Cognitive overload

A demanding, unrelated task is placed ahead of the malicious request.

The decoy consumes the model’s effective attention so that moderation is not meaningfully applied to the payload that follows.

This belongs to the same family as B1 and B2, being an attention misallocation, but it’s complexity based instead of length based. We may see further mention of these techniques as Agentic LLM usage increases.

Sources:

C Mechanisms: Padding as Force-Multiplier

In this category padding is not the whole attack.

C1. Payload splitting

A blocklisted term or instruction is fragmented into individually benign pieces, optionally with padding interposed between them, and the model is relied upon to reassemble the whole.

Classifiers that score fragments independently, or that inspect only the last N turns, will not read the reassembled intent.

The corresponding defence is to decode and concatenate prior to classification.

In RAG this generalises to splitting an instruction across separately-scanned documents that recombine at retrieval time.

Sources:

C2. Token-boundary and character injection

The surface text is modified so that the classifier’s tokeniser observes something harmless while the model still infers the intent. Junk characters joined to trigger words, as in TokenBreak, or homoglyphs, zero-width and invisible characters, and emoji-based smuggling.

Recently as of 28/09/2026 there has been a trend of employing norse runes for DAN prompts. I am yet to see this technique be as effective as other researchers claim.

In isolation these are said to reach very high evasion rates, in some cases approaching 100% against several commercial guardrails, while still beign legible to the model.

Volume padding should then make the malformed region less suspicious.

Sources:

Other applications

I do believe that we will soon see application of these techniques regarding LLM writing detectors, not to bypass classifiers but to hide LLM written sections.