Payload & Polyglot Lists

Found a payload that doesn't work? Please open an issue with the payload, target context, and what you expected to happen. Pull requests with fixes or new payloads are always welcome.

Research is ongoing. This project is under active development and will be updated regularly with new payloads, vulnerability classes, and validation improvements.

Disclaimer: These payloads are provided for authorized security testing, education, and research purposes only. The authors assume no responsibility or liability for any misuse or downstream effects. Use entirely at your own risk. By using this project you accept full responsibility for your actions.

License: MIT - see LICENSE

1,353 validated injection payloads covering 20 vulnerability classes, 31 deserialization frameworks, and 14 template engines. Every payload produces a detectable signal. Zero theoretical payloads.

Validation: 1,353 tested / 1,353 fire / 0 failures / 0 skipped against 35 Docker testbed stacks. Strict validation proves actual exploitation (server-side computation, real parser errors, measured timing delays, OOB callbacks from target containers) -- not string matching.

Concept

The Problem with Traditional Payload Lists

Most publicly available payload lists are organized by vulnerability type: one list for SQL injection, another for XSS, another for command injection, and so on. A tester picks the list they think matches the target, loads it into an intruder tool, and runs it against a parameter. If they guess wrong about the vulnerability class, the entire scan produces nothing. If the backend is an uncommon database, a non-standard template engine, or a language the list didn't account for, the payloads silently fail. The tester moves on thinking the parameter is clean.

This approach has two fundamental problems. First, it requires the tester to know what vulnerability exists before they've found it. Second, most payloads in circulation are theoretical -- copied between projects and blog posts without ever being tested against a real parser. They look right. They might even be syntactically valid. But they don't actually trigger a detectable response from the target.

Polyglot-First, Signal-Guaranteed

This project takes a different approach. The primary unit of work is the polyglot -- a single payload string engineered to be valid (or meaningfully invalid) across as many injection contexts as possible simultaneously. One polyglot breaks out of single quotes, double quotes, parentheses, block comments, HTML attributes, template delimiters, and backtick contexts all at once. Instead of needing to know what the vulnerability is, the tester fires polyglots at every parameter and watches for signals.

Every payload in this collection is built around detection pillars -- observable responses that confirm a vulnerability exists without requiring access to server logs, source code, or filesystem:

• Error: the payload causes the backend to throw an exception, parser error, or stack trace visible in the response.
• Math: the payload includes an arithmetic expression like 7*191 that evaluates to 1337. If that number appears in the response and the payload only sent 7*191 (not the literal 1337), the backend computed the expression -- proof of code execution.
• Timing: the payload forces a delay (5+ seconds). If the response is slow, the backend executed a sleep or CPU-intensive operation.
• OOB (Out-of-Band): the payload forces the backend to make an outbound HTTP, DNS, LDAP, or TCP connection to a callback server the tester controls. Confirms execution even when the response is completely opaque.

If a payload doesn't produce at least one of these signals when tested against its target context, it doesn't belong in the list. Every one of the 1,353 payloads here has been validated against purpose-built Docker testbeds with strict proof of exploitation. Zero are theoretical.

Built-ins Over Shell Commands

Traditional OOB and timing payloads rely on shell commands: curl, nslookup, ping, sleep. These break constantly. They depend on the target OS, the available PATH, which shell interprets the command, and whether the process has permission to spawn subprocesses. A curl-based OOB payload that works on Ubuntu fails on Alpine (no curl), fails on Windows (no curl), and fails inside a restricted container (no outbound process execution).

This project replaces shell commands with language-native built-ins wherever possible. Python payloads use urllib.request.urlopen() and time.sleep(). Java payloads use java.net.URL.openStream() and Thread.sleep(). Ruby uses Net::HTTP.get() and Kernel.sleep. PHP uses file_get_contents() and sleep(). These functions exist in every standard installation of their respective language -- no PATH lookup, no subprocess, no OS dependency.

Where even standard library imports might be blocked (sandboxed eval, restricted exec), the payloads fall back to import-free alternatives: CPU spin loops for timing (sum(range(500000000)) in Python, Atomics.wait() in Node) and raw socket connections for OOB (__import__('socket').create_connection(), fsockopen(), TCPSocket.new()).

Where Polyglots Don't Reach

Not everything can be a polyglot. Template engines use fundamentally incompatible syntax -- {{}} in Jinja2 means nothing to ERB's <%= %>, and neither parses as Freemarker's ${}). Deserialization formats are binary or structured data specific to one framework. For these categories, the project uses per-engine payloads organized under the same detection pillar system, covering 14 template engines and 31 deserialization frameworks across 7 languages.

The result is a single corpus where polyglots handle the contexts they can (SQLi, OS command injection, XSS, code injection) and purpose-built per-engine payloads handle the rest, all validated, all producing detectable signals, all ready for line-by-line injection tools.

Minimal List (82 Payloads)

83 payloads covering all 35 testbed stacks, all 55+ endpoints, and all 4 detection pillars per category. Validated: 83 FIRE / 0 NO-FIRE / 0 SKIPPED.

Every injection category gets error + math + timing + OOB coverage where architecturally possible. Deserialization frameworks that support code execution (Pickle, PyYAML, jsonpickle, node-serialize, XMLDecoder, .NET Json.NET) get full multi-pillar coverage. Frameworks limited to probing (PHP unserialize, Ruby Marshal, SnakeYAML, etc.) get error-based detection. Fire this at every parameter before switching to full category lists for depth.

83 requests instead of 1,353. Use ready/minimal/payloads-only.txt for Burp Intruder.

Picking the Right Payload for a Target

See HOWTOUSE.md for the full operator guide. It turns "I'm looking at a parameter, what do I throw at it?" into a repeatable workflow:

1. Parameter and context profiling - 5 questions (value shape, stack fingerprint, response visibility, OOB availability, WAF) that prune categories before you fire a single payload.
2. Category-by-category "when to suspect it" - exhaustive, production-focused hints for all 20 categories. Each category lists real SaaS feature types (low-code platforms, BI/reporting, monitoring, workflow automation, SSO, SSRF fetchers, eval sinks, email template builders, etc.), visual and behavioral cues (7*7 returning 49 as the eval giveaway, {{name}} rendering as "Alice" confirming SSTI, ping output leaking from a diagnostic field, User-Agent strings in OOB logs naming the fetcher library), modern-stack ORM footguns (Prisma $queryRaw, Rails .order(), Hibernate JPQL concat, Mongoose findOne(req.body)), and cheap probes to confirm suspicion before burning the full list.
3. Dangerous serialization byte fingerprints - raw magic bytes and base64 prefixes for 31 frameworks across Python, PHP, Java, .NET, Node, Ruby, and Perl (rO0AB = Java, AAEAAAD///// = .NET BinaryFormatter, BAg = Ruby Marshal, gASV = Python pickle P4, / = PHP unserialize, etc.) with a 16-entry quick-reference cheat-card and disambiguation heuristics. Fingerprint the blob before firing so you load 5-15 matching payloads instead of all 232.

Use HOWTOUSE.md before you run payloadctl prepare. Fingerprint first, minimal list second, category drill-down third - not a shotgun of 1,353 payloads at every parameter.

Quick Start

# 1. Prepare payloads with your callback domain
#    Replaces {domain} placeholder in all OOB payloads with your server
./tools/payloadctl prepare YOUR_CALLBACK.oastify.com

# 2. Load into Burp Intruder, ffuf, or any line-by-line injection tool
#    All output goes to ready/ (gitignored, contains your domain)

After running prepare, your ready-to-use files are in ready/full/ and ready/minimal/ with matching structure:

The ready/minimal/ directory mirrors the same structure (by-category, by-pillar, encoded) with the minimal payload set.

Custom output directory:

./tools/payloadctl prepare YOUR_CALLBACK.oastify.com -o /path/to/engagement/payloads

Raw templates with {domain} placeholder (for scripted substitution) are in payloads/lists/full/ and payloads/lists/minimal/.

Detection Pillars

Every payload produces at least one of these signals. Grep for these in your responses:

Canary values: 1337 (primary, from 7*191) and 7331 (secondary). Detection is a simple grep.

Payload Coverage

By Vulnerability Class

13 of 20 categories have all 4 pillars. The 7 that don't (XSS, XSLT, Format String, Prototype Pollution, CRLF, XXE, CouchDB) have architectural reasons -- you can't do timing-based CRLF or OOB format strings. Where cross-pillar IS possible, the polyglots section covers it.

Encoded Variants

7 encoding formats, each with all 1,353 payloads:

Design Principles

Minimum payloads, maximum context coverage. See SPEC.md for the full technical specification with per-engine pillar tables and exact payload syntax.

1. Polyglots first. One payload breaks out of ', ", ), */, -->, backticks, and template delimiters simultaneously. Polyglot sections lead the master list.

2. Per-engine where polyglots can't reach. SSTI delimiters and deserialization formats are fundamentally incompatible across engines.

3. Built-in over shell. OOB and timing payloads use language-native libraries:

CLI Tool (payloadctl)

# USAGE: prepare payloads for an engagement
./tools/payloadctl prepare abc123.oastify.com          # output -> ready/
./tools/payloadctl prepare abc123.oastify.com -o /tmp/payloads  # custom dir

# DEVELOPMENT: build, distribute, validate, generate
./tools/payloadctl build              # sources/ -> payloads/full.txt
./tools/payloadctl dist               # full.txt + minimum.txt -> payloads/lists/full/ + lists/minimal/
./tools/payloadctl validate           # test all 1,353 payloads against 35 testbed stacks
./tools/payloadctl validate <file>    # test a specific wordlist (e.g. lists/minimal/master.txt)
./tools/payloadctl generate           # regenerate computed payloads (deser, ssti, sqli, misc)
./tools/payloadctl generate deser     # deserialization only
./tools/payloadctl generate ssti      # SSTI only

Typical Development Workflow

# 1. Edit source files
vim payloads/sources/sqli.txt

# 2. Rebuild
./tools/payloadctl build       # rebuild full.txt from sources
./tools/payloadctl dist        # regenerate lists/full/ + lists/minimal/

# 3. Validate (requires Docker testbeds running)
cd testbed && ./testbed up sqli-sqlite && cd ..
./tools/payloadctl validate    # expect: N FIRE / 0 NO-FIRE / 0 SKIPPED

# 4. Prepare for use
./tools/payloadctl prepare YOUR_CALLBACK.oastify.com

Repository Structure

.
├── README.md                          # This file
├── HOWTOUSE.md                        # Operator guide: context profiling + category selection matrix
├── SPEC.md                            # Technical spec - per-engine pillars, payload syntax, coverage
│
├── tools/                             # CLI and generators
│   ├── payloadctl                     # CLI entry point
│   ├── cmd_build.py                   # Build full.txt from source files
│   ├── cmd_dist.py                    # Generate lists/ directory
│   ├── cmd_validate.py                # Validate payloads against testbeds
│   ├── cmd_validate_strict.py         # Strict validation (proves actual exploitation)
│   ├── cmd_generate.py                # Run payload generators
│   ├── cmd_prepare.py                 # Prepare payloads with callback domain
│   ├── generate-deser-final.py        # Deserialization generator (31 frameworks)
│   ├── generate-ssti-missing.py       # SSTI generator (14 engines)
│   ├── generate-sqli-code-missing.py  # SQLi and code injection generator
│   └── generate-misc-missing.py       # XXE, XSS, SSRF, path traversal generator
│
├── payloads/
│   ├── full.txt                       # Master list (1,353 payloads, with ## headers)
│   ├── sources/                       # Source files (edit these, all validated)
│   │   ├── minimum.txt                # 83-payload minimal list (validated, all pillars)
│   │   ├── polyglots-condensed.txt    # Cross-context polyglots (first in master)
│   │   ├── sqli.txt                   # SQL injection (204)
│   │   ├── ssti.txt                   # Template injection (168)
│   │   ├── deserialization.txt        # Deserialization (116, 31 frameworks)
│   │   ├── os-cmd-injection.txt       # OS command injection (116)
│   │   ├── code-injection.txt         # Code injection (112, includes Groovy)
│   │   ├── ssrf.txt                   # SSRF (117)
│   │   ├── path-traversal.txt         # Path traversal (98)
│   │   ├── xss.txt                    # XSS (49)
│   │   ├── format-string.txt          # Format string (33)
│   │   ├── nosql.txt                  # NoSQL (26)
│   │   ├── el-injection.txt           # Expression language (26, includes MVEL)
│   │   ├── header-crlf.txt            # CRLF/header (14)
│   │   ├── prototype-pollution.txt    # Prototype pollution (10)
│   │   ├── xxe.txt                    # XXE (8)
│   │   ├── ldap-injection.txt         # LDAP injection (30)
│   │   ├── xslt-injection.txt         # XSLT injection (25)
│   │   ├── elasticsearch-injection.txt # Elasticsearch (25)
│   │   ├── cypher-injection.txt       # Neo4j/Cypher (22)
│   │   └── couchdb-injection.txt      # CouchDB (4)
│   └── lists/                         # Generated (don't edit, use payloadctl dist)
│       ├── full/                      # Full payload set
│       │   ├── master.txt             # 1,353 payloads with ## headers
│       │   ├── payloads-only.txt      # Raw lines for Burp Intruder
│       │   ├── by-category/           # 20 category files
│       │   ├── by-pillar/             # 5 pillar files (with -payloads-only variants)
│       │   └── encoded/               # 7 encoding variants
│       └── minimal/                   # Minimal payload set (same structure)
│           ├── master.txt             # 83 payloads with ## headers
│           ├── payloads-only.txt      # Raw lines for Burp Intruder
│           ├── by-category/           # 20 category files
│           ├── by-pillar/             # 5 pillar files (with -payloads-only variants)
│           └── encoded/               # 7 encoding variants
│
├── ready/                             # Output from payloadctl prepare (gitignored)
│
└── testbed/                           # Docker validation infrastructure
    ├── testbed                        # CLI: ./testbed up <stack>
    ├── docker-compose.oob.yml         # OOB callback catcher (HTTP 9999, TCP 9998, DNS 5353)
    ├── shared/oob-catcher/            # HTTP + LDAP/binary + raw TCP + DNS callback server
    └── stacks/                        # 35 vulnerable application stacks

Adding Payloads

Add a payload to an existing category

1. Edit the source file in payloads/sources/. One payload per line under a ##Header## section.
2. Every payload must produce a detectable signal (error, math 1337, timing >4.5s, OOB, reflection).
3. Rebuild and validate:
   root@kitploit:~

   ./tools/payloadctl build && ./tools/payloadctl dist
   ./tools/payloadctl validate    # 0 NO-FIRE required
   

Add a new vulnerability category

1. Create payloads/sources/<category>.txt with ## headers for each pillar (error, math, timing, OOB).
2. Add the file to tools/cmd_build.py SOURCE_FILES and tools/cmd_dist.py CATEGORY_SOURCES.
3. Create a testbed stack in testbed/stacks/<category>/ (Dockerfile + server exposing POST /<endpoint> with input=<payload> returning {"output": "...", "error": "...", "time_ms": N}).
4. Add endpoint routing in tools/cmd_validate.py (ENDPOINTS dict and _get_endpoints() function).

Add a new deserialization framework

1. Edit tools/generate-deser-final.py - add a function that outputs payloads (error, math, timing, OOB).
2. Run ./tools/payloadctl generate deser && ./tools/payloadctl build
3. Add testbed endpoint and routing if needed.

Add a new SSTI engine

1. Edit payloads/sources/ssti.txt - add ##EngineName (Language) - Pillar## sections. Use language built-ins for timing/OOB.
2. Add testbed endpoint in the matching ssti-<language> stack.
3. Add routing in tools/cmd_validate.py ENGINE_MAP.

Payload format rules

• One payload per line (multi-line YAML uses literal \n)
• {domain} placeholder for OOB callback URLs
• 1337 canary for all math payloads
• ##Header## sections group by category and pillar
• No duplicates (build step deduplicates automatically)

Validation

The validator tests every payload against real vulnerable applications:

# Start testbeds (Docker required)
cd testbed
./testbed up sqli-sqlite
./testbed up ssti-python
./testbed up deserialization-java
# ... (35 stacks total)

# Run validation
cd ..
./tools/payloadctl validate
# Output: 1,353 FIRE / 0 NO-FIRE / 0 SKIPPED / 1,353 TOTAL

How it works:

1. Reads the payload file and routes each ## section to matching testbed endpoint(s)
2. POSTs input=<payload> to endpoint(s), checks response for signals
3. A payload fires if ANY endpoint returns: real parser/interpreter error, server-computed 1337 (from 7*191), >4.5s delay, OOB callback from target container, file-read content (root:x:0:0), or reflected input in a valid context (XSS, CRLF)

Strict validation (tools/cmd_validate_strict.py) additionally verifies:

• Math payloads prove server-side computation (payload sends 7*191, not literal 1337)
• OOB callbacks originate from testbed container IPs
• Error messages contain real parser/interpreter signatures, not generic HTTP errors
• Timing delays fall within expected range (~5 seconds)

Testbed stacks (35 total)

OOB catcher on port 9999 (HTTP + LDAP/binary detection) and 9998 (raw TCP catch-all), with DNS on 5353/UDP. Detects HTTP callbacks, LDAP/ASN.1 binary connections (JNDI), DNS queries, and raw TCP connections. Every endpoint accepts POST /<sink> with input=<payload> and returns {"output": "...", "error": "...|null", "time_ms": N}.

Credits

Payloads researched and developed by Grom Hacks. Built on work from the security research community including PayloadsAllTheThings, HackTricks, PortSwigger Web Security Academy, and individual researchers. All payloads validated against real vulnerable applications.