Security1 distinct publisher2 min readPublished
A PortSwigger researcher turns a tag name into executed script by reading its lowercase copy from localName, a spot sanitizers and WAF signatures treat as inert. It reportedly works everywhere.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
The reason a scanner misses this is positional. Sanitizers normalise tag names and WAF signatures inspect attributes and the short list of elements everyone knows to fear, so the name itself is treated as a label rather than a place code can hide. Reading it back through localName defeats exactly that assumption [2].
The chain that does the reading is short. Any element can be made focusable with tabindex, an onfocus handler can be aimed at itself, and a string written to attributes[0].value is converted into a function that new then invokes [3][4]. A signature hunting for alert( inside a known tag or an on* attribute value has nothing to catch, because the executable text is sitting in the tag-name slot the filter was built to skip.
Blocklists that anticipate one property do not fare much better. If attributes[0].value is filtered, textContent and nodeValue reach the same handler [9]. The part attribute splits its value into an array that can be chained to overwrite the event and onfocus variables and pass the lowercase name to eval [11]. An opening angle bracket folded into the name, combined with the first attribute and written to innerHTML, produces fresh markup rather than a call [10]. Fuzzing the transformations showed alphabetic characters, slashes, whitespace and newlines get rewritten, while Unicode line and paragraph separators survive and are read as newlines by JavaScript, so the same payload can wear odd shapes [8].
The takeaway is a class of problem, not one element. Properties that look harmless, localName, part and classList among them, can carry payloads or perform transformations that no signature modelled [13]. Anything defending on a deny list of tag names and attribute strings is matching a surface the browser does not respect, which is why the dull answer, an allow list of elements and attributes with proper output encoding, is the one that survives a filter's obligation to enumerate every place a browser might stash runnable text.
Ranked by verification strength, evidence, and original report placement.
PortSwigger published the research post 'What's in a tag name? JavaScript, apparently' on Tuesday 25 August 2026 at 14:24 UTC.
The DOM property localName holds a lowercase copy of an element's tag name, even though the browser converts the tag name to uppercase in most other properties.
Any element can be made focusable using the tabindex attribute, and an onfocus event handler can be chained to reference itself.
A string written to attributes[0].value is converted into a function and can be called as a constructor using new.
The tag <alert(1) onfocus="attributes[0].value=localName,new onfocus" autofocus tabindex=1> executes the JavaScript contained in its own tag name.
The researcher states the technique works in every browser and functions as a WAF bypass.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed primary PoCs, single unverified source
The technique is documented with numerous concrete, self-contained proof-of-concept vectors and a clear mechanistic account of localName, focus/onfocus chaining, and the various sinks. Evidence is strong at the demonstration level but comes from a single originating source with no independent reproduction, and broad claims lack a browser-version or WAF test matrix.
No real-world exploitation or defensive uptake reported
The cluster describes a technique, not its adoption. There is no evidence of in-the-wild exploitation, WAF/sanitizer vendor responses, browser-vendor fixes, or defender uptake. The only usage signal is the author's disclosed use of an AI tool to find variants, which is not adoption of the vulnerability class.
Sweeping reach claims outrun evidence shown
The demonstrated vectors are concrete and credible, but the headline assertions that the technique 'works in every browser' and reliably bypasses WAFs are stated without a per-browser or per-WAF evidence matrix and rest on a single self-reporting source, producing a mild overstatement relative to what is actually verified.
Vendor research raising profile of a security firm
PortSwigger is a commercial web-security tooling vendor, and offensive research demonstrating WAF/blocklist bypasses supports its brand and product positioning. This is a moderate promotional incentive, tempered by the technical, reproducible nature of the content.
Rich detail but single self-reporting source
Confidence in the assessment is moderate: the writeup is internally detailed and self-consistent, but the entire cluster is one publisher who is also the researcher, with no independent verification, vendor confirmation, or adoption data to triangulate the broader claims.
build
One link, your session: F-RevoCRM XSS has no fix but 8.0.41 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 25, 2026