This article describes an interactive lab demonstrating how encoding-based jailbreaks bypass keyword filters protecting large language models. A filter matching only plaintext keywords fails to catch requests encoded in base64, hex, ROT13, or leetspeak that the underlying model can decode. The vulnerability matters because it exposes a fundamental mismatch between what a filter sees and what a model understands, making simple keyword filtering an unreliable security control.
- The core vulnerability: filter-model disagreementKeyword filters scan for plaintext jailbreak phrases and reject matches, but the LLM decodes common encodings including base64, hex, ROT13, and leetspeak. A request expressed in any encoding the model can reverse but the filter cannot normalise passes the filter as non-matching text, then gets decoded and executed by the model. The mismatch is the entire vulnerability.
- How the attack works in practiceThe attacker takes a plaintext request the filter blocks, encodes it in a format the model understands (such as base64 or leetspeak), and sends the encoded version. The plaintext filter finds no banned keywords in the encoded form and allows it through. The model then decodes the content and acts on the original instruction, completing the bypass.
- Why keyword filters alone failKeyword filters operate on raw character matching without understanding encoding schemes or normalizing input before analysis. They see base64 or leetspeak as harmless gibberish because the characters do not match the plaintext ban list. This fundamental design flaw makes them bypass-able by any encoding mechanism the underlying model can reverse.
- Defensive strategy: normalise before filteringThe article recommends decoding and normalising input—including common encodings, case variations, and homoglyphs—before any filtering occurs. Filtering should target intent and behaviour rather than literal keywords, and defences should layer input checks, output checks, and action gating together. Keeping secrets out of the model's reach ensures that even a bypassed filter has nothing to surrender.
- Classification in security frameworksThe article identifies encoding bypass as one of the most reliable ways around naive prompt filters and classifies it as a core OWASP LLM01 Prompt Injection technique under the OWASP Top 10 for LLM Applications (2025). This positions it as a recognised and established attack category in LLM security.
- Real-world applicabilityThe article states encoding bypass happens in real-world deployments and is commonly exploited against prompt filters. Input keyword-matching alone is explicitly identified as insufficient as a security control, implying widespread deployment of this weak pattern in production systems.
Bottom line: Keyword filters protecting LLMs are inherently inadequate because they operate on plaintext while models understand multiple encodings; any effective defence must normalise and decode input before filtering, then enforce rules on meaning and behaviour rather than surface strings. The lab demonstrates this gap is not theoretical—it is exploitable in minutes with common encoding schemes.
📋 In this walkthrough
What this lab teaches
Encoding bypass exploits the gap between a byte-level filter and a model that understands many encodings. A keyword filter matches plaintext; the model decodes base64, hex, ROT13, leetspeak and more. What the filter cannot read, the model can.
The lesson: a filter and the model do not share an understanding of the input. Any transformation the model can reverse but the filter cannot is a bypass.
How EncBot filters requests
EncBot's input filter scans for plaintext jailbreak keywords and rejects matches. The LLM, though, decodes common encodings, so a request expressed in base64 or leetspeak passes the filter as non-matching text and is understood by the model.
The attack approach
- Confirm the filter matches plaintext keywords only.
- Express the request in an encoding the model can decode but the filter does not normalise.
- Send the encoded form so the filter sees no banned words.
- Let the model decode and act on it.
Full walkthrough (spoiler)
If it is still blocked, the filter caught your encoding scheme — try another and open the steps.
Show the step-by-step solution
- Take the request the filter blocks in plain English and encode it (for example base64 or leetspeak).
- Send the encoded version; the plaintext filter finds no banned keywords.
- The model decodes the content and understands the original intent.
- It leaks the secret token and the lab marks you solved.
Why it works
The filter and the model disagree about what the input 'says'. The filter reads raw characters and finds nothing banned; the model reverses the encoding and reads the real instruction. The mismatch is the whole vulnerability.
Where this happens in the real world
Encoding bypass is one of the most reliable ways around naive prompt filters and is a core OWASP LLM01 Prompt Injection technique. It is why input keyword-matching alone is not a security control.
How to defend against it
- Decode and normalise input (common encodings, case, homoglyphs) before any filtering.
- Filter on intent and behaviour, not literal keywords.
- Keep secrets out of the model's reach so a bypassed filter has nothing to surrender.
- Layer defences — input checks, output checks and action gating together.
Try it, then go further
Reading about it is the easy part. Open the lab, try your own approach before peeking at the spoiler, and see how many attempts it takes.
