Loading story…
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.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
Chrome 147 was released with fixes for both Sanitizer API XSS bypasses: the malformed SVG `xlink:href` animation bypass and the invalid JavaScript form-action URL bypass.
A patch to the `ProtocolIsJavaScript` handling landed to address a second Sanitizer API bypass involving invalid JavaScript URLs that could become executable after GET-form URL rewriting.
Chrome patched the SVG animation bypass by using the SVG attribute parser instead of a direct string comparison when filtering animation attributes.
A bypass affecting Chrome 146's Sanitizer API was reported. It used an SVG animation element with a malformed `attributeName="xlink:href:x"` value to evade filtering and animate an SVG link to a `javascript:` URL.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map 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.
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.
Aug 15, 2026
Google Chrome addressed three **use-after-free** vulnerabilities tracked as `CVE-2026-7347`, `CVE-2026-7363`, and `CVE-2026-7344` in versions prior to `147.0.7727.138`. The bugs affect the **Chromoting**, **Canvas**, and **Accessibility** components, respectively, and all were classified under `CWE-416`. Two of the flaws were rated **critical**: `CVE-2026-7363` allows a remote attacker to execute arbitrary code inside the browser sandbox on Linux and ChromeOS by luring a user to a crafted HTML page, while `CVE-2026-7344` could let an attacker escape Chrome's sandbox on Windows after compromising the renderer process via crafted web content. The third issue, `CVE-2026-7347`, was rated **high severity** and affects Chromoting, where malicious network traffic could enable arbitrary code execution without privileges or user interaction. CVSS data added to the records shows network-based exploitation with high impact to confidentiality, integrity, and availability, with `CVE-2026-7363` and `CVE-2026-7344` carrying the vector `AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H`. The vulnerabilities were documented in Chrome and Chromium tracking references, underscoring the need for organizations to move affected browsers to `147.0.7727.138` or later.
Jun 29, 2026
A vulnerability tracked as **CVE-2026-44990** allows stored cross-site scripting in `sanitize-html` when applications use the library’s default configuration and later render sanitized user content as trusted HTML. The flaw affects versions prior to **2.17.4** and stems from the handling of the disallowed `xmp` element: because `htmlparser2` treats `xmp` as a raw-text tag, attacker-supplied markup inside it is preserved as text during sanitization but can be emitted back as active HTML or JavaScript under the default `disallowedTagsMode: 'discard'` behavior. GitHub’s advisory and the upstream patch say the bypass can let payloads such as `<script>`, `img` event handlers, and `svg`-embedded script content survive filtering and execute in a victim’s browser. The fix in **2.17.4** adds `xmp` to `nonTextTags` so content inside a disallowed `xmp` tag is dropped instead of re-emitted, and regression tests were added to confirm the malicious content is removed. The issue was reported by **Vincenzo Turturro** (`sushi-gif`), and users of affected `sanitize-html` deployments, including those in **ApostropheCMS**, were urged to update immediately.
Jun 29, 2026