Zero-Interaction Stored XSS
via Filter Bypass

Introduction

Intigriti's monthly XSS challenges test creative exploitation skills under real-world constraints. The May 2026 challenge presented a retro arcade-themed web application with a custom server-side filter.

While there was an intended solution path, I identified a stored XSS vulnerability in the profile display name field — an unintended attack surface the challenge authors confirmed after submission.

Vulnerability Analysis

The root cause is in loadTestimonials() inside /js/app.js. The function renders both the testimonial content and the author display name, but handles them inconsistently:

app.js// loadTestimonials() — /js/app.js
data.forEach(t => {
    let nameDiv = document.createElement('div');
    nameDiv.className = 'user-name';
    nameDiv.innerHTML = t.user_name;  // ← no sanitization — XSS sink

    let textDiv = document.createElement('div');
    textDiv.className = 'user-text';
    textDiv.innerHTML = DOMPurify.sanitize(t.content);  // ← safe

    card.appendChild(nameDiv);
    card.appendChild(textDiv);
    container.appendChild(card);
});

The testimonial body is protected with DOMPurify. The display name is not. Any HTML stored in user_name executes in every visitor's browser when the testimonials page loads.

Filter Bypass

The server's custom "Advanced SCA Shield" blocked these characters and keywords:

Technique 1 — Semicolon-free Numeric Entities

HTML numeric entities like &#40 don't require a trailing semicolon when followed by a non-digit character. The browser decodes them correctly; the server's string-matching filter sees no blocked character.

Technique 2 — Partial Keyword Encoding

Encoding only the first character of a blocked keyword breaks pattern matching. &#97 decodes to a and the parser stops at l (non-digit), producing alert in the DOM — a string the server filter never matched.

Technique 3 — Auto-firing Event Handler

All common event handlers were blocked. The remaining candidates each had a problem:

ontoggle was the answer — completely absent from the blocklist. Combined with <details open>, it fires the toggle event the instant the element connects to the DOM, requiring zero user interaction. The <details> tag itself is a plain HTML5 element with no suspicious keywords, making it invisible to signature-based filters.

Final Payload

Combining all three techniques, the payload set as the display name field:

Steps to Reproduce

payload<details ontoggle=&#97lert&#40&#100ocument&#46domain&#41 open>

urlhttps://challenge-0526.intigriti.io/challenge#testimonials

Execution Flow

Remediation

• ✓
  Use textContent for plain-text fields. Bypasses the HTML parser entirely — the correct approach when HTML rendering is not needed.

  jsnameDiv.textContent = t.user_name; // no HTML parsing

• ✓
  Apply DOMPurify to all user-supplied fields. The inconsistency between how content and user_name were handled was the core mistake.

  jsnameDiv.innerHTML = DOMPurify.sanitize(t.user_name);

• ✓
  Replace blocklists with allowlist validation. Custom blocklists are inherently bypassable. This write-up demonstrates three independent bypass techniques against a single filter. Server-side output encoding with an allowlist-based approach is the correct path forward.

Conclusion

This challenge illustrates how inconsistent sanitization creates real vulnerabilities. The testimonial content was handled correctly — but one overlooked innerHTML assignment on an adjacent field was enough to compromise every user on the platform simultaneously.

The filter bypass required no exotic tooling — only an understanding of how browsers decode HTML entities before parsing event handler attributes, and awareness of which event handlers auto-fire on DOM insertion.

Special thanks to ayoub__intigriti and the Intigriti team for a well-constructed challenge.

Follow me on X: @hasn0x