GromHacks Labs -- The payload lists they don't want you to have. 1,324 injection probes beamed down from the mothership to detect what's injectable across 20 vuln classes. We don't exploit, we just knock on the door and see who answers. Every payload tested against real parsers because the aliens demand proof. Trust no input. Question everything!
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 with new injection contexts, payloads, 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,618 unique payload strings across 37 security-test categories plus a cross-cutting polyglot set, 35 named deserialization formats, libraries, and sinks, and 20 template engines. The context-preserving master contains 1,760 payload-to-section assignments across 661 sections, so a shared string remains associated with every parser and insertion context where it applies. The 108-payload minimal list includes representative probes for GraphQL, HQL/JPQL, XPath, JSONPath, JSON construction, HTTP parameter pollution, XQuery, Firestore, SMTP/IMAP and email headers, Host headers, XML/SOAP structure, LDAP DN, HTML/CSS, CSV, logs, and LaTeX. Validation coverage varies by payload, parser, and insertion context.
The language matrix covers C, C++, C#, Dart, Elixir, Erlang, Go, Java, JavaScript, Kotlin, Lua, Objective-C, Perl, PHP, Python, Ruby, Rust, Scala, Swift, and TypeScript.
The general validator is a smoke check, not proof of exploitation: earlier results counted arbitrary errors and request timeouts as hits. The context regression covers nine live SQL dialects, including string, numeric, injected ORDER BY clause and direct sort-expression positions; GraphQL.js, Hibernate HQL/JPQL, direct XPath/XQuery/JSONPath, JSON construction and duplicate-parameter pollution, Firestore structured filters, SMTP/IMAP command and email-header injection, Host-header URL poisoning, XML and SOAP structure, LDAP filter and DN injection, HTML/CSS/XSS in Chromium, CSV formula-cell breakout, log forging, LaTeX source injection, POSIX shell quote/backtick/pipeline, $() and percent-decoded newline contexts, local SSRF/path/XXE fixtures, MongoDB/CouchDB/Redis/ArangoDB/DynamoDB PartiQL/Cassandra CQL/Couchbase SQL++/Elasticsearch/Neo4j, EL, XSLT, SSI, prototype pollution, and representative deserialization callbacks. Browser checks include unquoted attribute, attribute-fragment, HTML-comment, and </script> parser contexts. The language matrix checks math, errors, timing, OOB, and generated-source quote breakouts in all 20 requested languages; common alternate quote and backtick string contexts are tested where supported, alongside a shared arithmetic polyglot in all 20 and runtime format strings where applicable. See COVERAGE.md for the verified matrix and remaining engine-specific gaps.
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.
This project uses polyglots where one string can cover multiple related contexts. A payload's behavior still depends on how an application inserts it: a shell argument may be unquoted, single-quoted, or double-quoted; SQL string and numeric expressions differ; template engines use incompatible delimiters. The testbed needs to model those wrappers explicitly. No single string should be assumed to break out of every quote, comment, or parser.
Payloads are grouped around detection pillars -- observable responses that can provide evidence in a matching context:
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 target parser evaluated the expression. The result proves evaluation in that sink, which may be a query, template, expression language, or code runtime.These signals are useful only when checked in the payload's actual context. The general validator is a smoke test; a parser error, timeout, or reflected string alone does not prove that a payload executed. Use the context-specific Docker checks for stronger evidence.
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 come from the language runtime or standard library, so they avoid PATH lookup and subprocess dependencies. Runtime policy and configuration can still disable network access or individual APIs; the fixture matrix records the exact environment that was exercised.
Where standard library imports might be blocked, some payloads use import-free alternatives such as Atomics.wait() in Node and raw socket connections for OOB. Resource-heavy loops are excluded from the default corpus checks.
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 20 template engines and 35 named deserialization formats, libraries, and sinks across 11 runtime groups.