Reconstructing JavaScript from HTML Tag Names: An XSS and WAF Blocklist Evasion Technique

1. Basic Information

• Article Title: What's in a tag name? JavaScript, apparently
• Published By: PortSwigger Research
• Publication Date: 2026-08-25 14:24 UTC
• Original Source: PortSwigger Research
• Related Sources: None
• Related Malware, Attack Groups, CVEs, Products: XSS, Web Browsers, WAF, HTML Sanitizers
• Severity: Medium

2. One-Sentence Summary

An XSS technique that places a string with JavaScript meaning into an HTML tag name, extracts that string from the browser-generated DOM using localName or similar properties, and reconstructs it into an event handler. This can bypass WAFs and blocklists that only look at typical script tags or event attribute payloads.

3. Attack Flow

Basic Form of Reconstructing Tag Names into JavaScript

1. An attacker embeds a string with JavaScript meaning into an unusual HTML tag name, and inputs an HTML fragment that combines onfocus, autofocus, tabindex, etc.
2. The application outputs this input into an HTML context, and it reaches the browser with the required tag names and event attributes still present.
3. The browser takes the tag name into the DOM as an element, and can retrieve the tag name as a lowercase string using localName.
4. When onfocus triggers, it moves the string obtained from localName or elsewhere into an event handler value or another DOM property, reconstructing it into executable JavaScript.
5. The reconstructed event handler is called, and JavaScript runs in the target page's origin.

PortSwigger shows variants that use textContent, nodeValue, getAttributeNode, part, classList, setHTMLUnsafe, and others, in addition to attributes[0].value.

Role of WAFs and Sanitizers

The main point of this article is that normal XSS signatures and blocklists may miss syntax that "turns tag names back into JavaScript at runtime." This does not mean it proves the bypass of a specific HTML sanitizer product. If a sanitizer removes unknown elements or event attributes, this attack chain does not work.

4. Attacker Position and Execution Location

The attacker is in a position where they can cause attacker-controlled strings to reach the HTML context, such as through a CMS, rich text, comments, stored content, or reflected input. The final execution location is the victim browser's target web origin.

5. Visibility for Victims and Administrators

• Victim: If autofocus works, the focus event can trigger without an explicit click.
• Administrator: Typical <script> tags or known XSS strings may not exist in attribute values, making it hard to determine intent using simple string signatures.

Passing through a WAF is different from executing JavaScript in the browser. Determining success requires execution evidence such as browser-side reproduction or CSP reports.

6. Conditions for Success and Failure

Conditions for Success

• Attacker input reaches the browser as HTML, not plain text.
• Tag names, event attributes, and focus-related attributes needed for the attack remain in the DOM.
• The focus event triggers, and CSP or other controls do not block the execution of the reconstructed event handler.

Conditions for Failure

• Input is context-specifically encoded upon output, and attacker input is not interpreted as HTML.
• An allowlist-based HTML sanitizer removes unknown elements or event attributes.
• A strict CSP rejects inline event handlers.
• The element does not receive focus, and the event does not trigger.

7. What Happens Upon Success

JavaScript executes with the permissions of the same web origin as the target page. Depending on application state and victim permissions, this can lead to DOM manipulation, access to information readable within the same origin, or authenticated actions. If established as stored XSS, it can affect multiple viewers.

8. Observable Logs

• Email: Usually not directly related.
• Proxy/SWG/DNS: HTTP requests and responses containing crafted HTML. Syntax may not be visible unless URL encoding or compression in the body is restored.
• Endpoint/EDR: General EDRs have a hard time observing event triggers inside the DOM directly. External communication or abnormal browser behavior after XSS can serve as supporting evidence.
• Identity/IdP: Unlikely to be direct evidence of XSS itself. Correlate timestamps if authenticated actions occur after an administrator views the content.
• SaaS/Cloud: CMS or application post/edit audits, and CSP report-uri / report-to if available.
• Network: Bodies containing unusual tag names closely followed by onfocus, autofocus, tabindex, localName, etc., are candidates for hunting. However, this alone does not confirm malice.

9. Determining Attack Success

• Attack Attempt Observed (Success Unconfirmed): Found matching syntax in requests or stored content, but no evidence of browser execution.
• Initial Execution Confirmed: Confirmed event triggering and JavaScript execution via a test browser, browser instrumentation, or CSP reports.
• Data Theft or Session Compromise Confirmed: Confirmed post-XSS data retrieval, external transmission, or authenticated actions.

10. Investigation Playbook

• Trigger: Detect unusual combinations of tag names and onfocus / autofocus / localName, etc., or related CSP violations.
• Initial Check: Preserve raw requests/responses or stored data, and inspect them in a decoded HTML state. Identify whether the attack is reflected or stored, and who viewed it.
• Endpoint: Reproduce DOM structure, localName, event triggering, and CSP results in an isolated test environment. Investigate separately if the victim endpoint shows external communication.
• Authentication/Cloud: If a high-privilege user viewed the content, check for simultaneous setting changes, data access, or token usage.
• Follow-up Actions: Check for external transmission, DOM manipulation, account actions, and the display range of stored content.
• Containment: Delete malicious content, and stop or sanitize vulnerable output paths. Fix output encoding/sanitization, and review CSP as a secondary defense.
• Classification: Record WAF detection/bypass, browser execution, and subsequent impact separately.

11. Defense and Detection Ideas

• Single Event: Unnatural combinations of unknown tag names and onfocus, autofocus, tabindex / contenteditable, localName, etc.
• Time-Series Correlation: Behavior where the same sender repeatedly inputs similar HTML while changing tag names or DOM properties.
• Hunting: Search stored content for onfocus, localName, attributes[0], new onfocus, setHTMLUnsafe, etc., and check the actual DOM context.
• Log Gaps: WAF logs alone cannot confirm whether DOM transformation and JavaScript execution succeeded. CSP reports or secure browser reproduction help fill the gap.
• Priority Countermeasures: Context-specific output encoding, allowlist-based sanitization that keeps only necessary HTML, removal of event attributes, and strict CSP.

12. Facts / Inference / Hypothesis

Facts

• A vector was shown that uses localName to get a tag name as a lowercase string and moves that string into an execution path.
• A basic form using autofocus and onfocus to proceed to execution without user clicks was demonstrated.
• Variants using multiple DOM properties were shown in the PortSwigger article.
• The article does not report browser CVEs or active exploitation campaigns.

Inference

• WAF rules and blocklists centered on attribute values may miss this if they do not account for the concept of reconstructing strings embedded in tag names at runtime.
• Regarding HTML sanitizers, this is a defensive inference that if a configuration leaves the elements and attributes needed for the attack intact, it can succeed, rather than a proof of bypassing a specific product.

Hypothesis

• WAF/sanitizer bypass rates for specific products and versions cannot be generalized from the article alone.

13. MITRE ATT&CK Mapping

Because this article does not show active campaigns or specific attacker behavior, MITRE ATT&CK tags are not forced. Do not directly tie this to attacker TTPs such as T1059.007 solely based on the technical fact that JavaScript is executed.

14. Unknowns and Additional Investigation

The reproducibility of individual WAF and HTML sanitizer products under default settings, detailed test matrices by browser and version, and the presence of active exploitation cannot be confirmed from this article alone. The premise is that the application side can output attacker input as HTML, and this is not a browser vulnerability itself.

15. Impact on SOCs and General Organizations

Features that permit user input as HTML—such as rich text, comments, email rendering, and CMS posts—should be primary targets for validation. Do not equate failing to block an attack at the WAF with a successful compromise; instead, verify stored or reflected HTML, DOM transformation, browser execution, and subsequent actions step by step.

16. Summary by Role

• For SOCs: Hunt for unusual tag names and focus-related attributes, and evaluate WAF bypass and browser execution separately.
• For Administrators: Output user input as plain text whenever possible. Where HTML is required, apply allowlist-based sanitization and remove event attributes. Use CSP as a secondary defense.
• For Users: This is a technique that abuses web application input processing, and users cannot prevent it entirely on their own. Report any suspicious behavior.