Loading story…
Research from Mitsui Bussan Secure Directions detailed how browser XSS filters in Chrome and Internet Explorer introduced exploitable behavior that let attackers steal information or trigger universal cross-site scripting, even when the target web application had no native XSS flaw. The write-up tied the issue to historical cases including CVE-2014-3197, CVE-2015-1285, CVE-2013-2848, CVE-2013-6656, CVE-2013-6657, CVE-2011-1992, and CVE-2009-4047, showing that request/response matching and response rewriting by the browser could create false positives that attackers then abused.
The attacks relied on detecting whether the filter activated through side channels such as URL changes, timing differences, CSP reports, or window.length, allowing low-entropy secrets to be inferred across origins. A related Chromium security issue documented an XSS-filter information leak, while the broader analysis concluded that neither normal mode nor block mode is universally safe because each creates different tradeoffs; the recommended priority is strong application-side XSS prevention and use of CSP, with disabling browser XSS filters considered for applications that already have robust native defenses.
See affected versions and whether adversaries are exploiting it.
11 events from the most recent confirmed update back to the earliest known activity.
The references state that Microsoft's December 2015 update for Kinugawa's reported Internet Explorer filter issues addressed only part of the reported methods. This left some concern that the remediation was incomplete.
Masato Kinugawa reported Internet Explorer UXSS issues CVE-2015-6144 and CVE-2015-6176, which the references say reproduced in normal mode rather than block mode. These findings reinforced the risk of partial response rewriting by browser XSS filters.
Gareth Heyes reported Chrome CVE-2015-1285, an information disclosure attack that inferred XSS filter activation through cross-origin reads of window.length. In the vulnerable behavior, filtered framed content became empty, making window.length drop to 0.
The references cite CVE-2014-6328 as an example of a pure Internet Explorer XSS filter bypass that Microsoft treated as a vulnerability. This is presented as evidence that some browser vendors formally tracked filter bypasses as security issues.
Takeshi Terada reported Chrome CVE-2014-3197, an information disclosure vulnerability that let attackers infer secret values from cross-origin pages by deliberately triggering false positives in Chrome's XSS filter. The Chromium issue reference was published on 2014-07-23, but the content anchors the event only to 2014.
NeeXEmil reported Chrome CVE-2013-6656 and CVE-2013-6657, which abused XSS filter behavior to steal POST parameter values rather than response content. These cases expanded the known impact of XSS-filter-based information leakage.
Egor Homakov reported Chrome CVE-2013-2848, an earlier information disclosure issue similar to later Chrome XSS filter leaks. The references say it exposed filter activation through a navigation change to about:blank.
Thomas Stehle reported Internet Explorer CVE-2011-1992, an information disclosure issue in which attackers could infer cross-domain or cross-zone content through trial and error. The attack relied on partial matches and timing differences in the filter's regex processing to recover secret characters.
Internet Explorer vulnerability CVE-2009-4047 showed that XSS filter response rewriting could create universal XSS even when the target application had no XSS flaw. The references say Microsoft introduced X-XSS-Protection: 1; mode=block after this issue to avoid partial rewriting.
Microsoft first implemented a browser XSS filter in Internet Explorer 8. The references anchor this introduction to 2008 and describe it as an early built-in, best-effort XSS defense.
Google fixed the Chrome CVE-2014-3197 issue by preserving the original page URL when the XSS filter triggered, preventing attackers from detecting activation through URL changes. The references also note Apple applied the same mitigation to a similar Safari bug.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
8 references tracked. Mallory keeps watching after this page renders.
mbsd.jp
Open sourcembsd.jp
Open sourcemksben.l0.cm
Open sourceblog.portswigger.net
Open sourcethespanner.co.uk
Open sourcecode.google.com
Open sourcehomakov.blogspot.com
Open sourcelcamtuf.coredump.cx
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Mozilla introduced `setHTML` in Firefox 148 as a safer alternative to `innerHTML`, using built-in HTML sanitization to reduce cross-site scripting (XSS) exposure when applications insert untrusted markup. The change aims to give developers a browser-native mechanism that avoids unsafe parsing and rendering patterns associated with direct HTML injection. Researchers also identified two XSS bypasses in Chrome 146's Sanitizer API implementation. One used SVG animation and the malformed namespaced attribute `xlink:href:x` to evade an attribute-blocking check; another allowed an invalid `javascript:` URL that GET-form URL rewriting converted into executable JavaScript. Chrome remediated both flaws in version 147, released April 7, 2026; organizations should ensure managed Chrome deployments are updated and treat browser sanitization APIs as defense-in-depth rather than a substitute for contextual output encoding and input controls.
Sep 3, 2026
A researcher disclosed a "universal code execution" attack pattern in browser extensions in which a malicious website sends crafted `window.postMessage` data to a content script that forwards it to a privileged extension background process. Extensions that inject content scripts broadly and fail to validate message origins can expose privileged capabilities to arbitrary websites, including cross-origin cookie access and same-origin policy bypasses. The impact can escalate to operating-system command execution when the extension relays attacker-controlled data through Chrome native messaging to an unsafe native host. The researcher identified the pattern through extension-manifest analysis and Semgrep taint tracking, and reported two censored, allegedly unpatched cases affecting large user populations; one smart-card extension with roughly two million users reportedly allowed a malicious DLL to be loaded through path traversal in a PKCS#11 library path. Organizations should assess extensions for strict content-script scope, origin and schema validation on message-passing interfaces, and hardened native-message handling.
Sep 3, 2026
Content Security Policy (CSP) can limit the impact of cross-site scripting, clickjacking, mixed content, and untrusted resource loading, but it is a defense-in-depth control rather than a replacement for input validation and output sanitization. Effective policies use per-response cryptographically random nonces or script hashes, narrowly define resource sources, set `object-src`, `base-uri`, `form-action`, and `frame-ancestors` explicitly, and can use Trusted Types to restrict dangerous DOM injection sinks such as `innerHTML`, `document.write()`, and `eval()`. Misconfigured policies can provide a false sense of security: `unsafe-inline`, `unsafe-eval`, `data:`, broad schemes, wildcards, and permissive third-party script allowlists can enable XSS bypasses. In HackMD/CodiMD 1.2.1, a stored XSS flaw in Markdown comment filtering allowed attackers to inject HTML; the platform's CSP still permitted exploitation because it trusted `cdnjs.cloudflare.com`, enabling an AngularJS client-side template-injection bypass. Organizations should deploy CSP first in `Content-Security-Policy-Report-Only` mode, collect violations through Reporting endpoints, and continuously test policies for regressions and risky third-party dependencies.
Sep 3, 2026