Loading story…
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.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
The vulnerability was fixed in a later CodiMD release through a referenced pull request.
A stored XSS flaw in the HackMD/CodiMD Markdown platform's handling of HTML comments allowed attackers to inject arbitrary HTML. HackMD's CSP was bypassed by loading AngularJS from an allowed cdnjs.cloudflare.com source and using client-side template injection to execute JavaScript in document viewers' browsers.
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.
3 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.
Web applications face significant risks from client-side attacks such as Cross-Site Scripting (XSS), where malicious scripts are injected into trusted websites and executed in users' browsers. Attackers exploit vulnerabilities by compromising third-party services, injecting code through adverts, or leveraging XSS to steal sensitive data like session tokens and credit card information. These attacks often bypass traditional security tools, which primarily monitor server-side activity and sanitized data, leaving organizations exposed to threats that manifest in the user's browser environment. Content Security Policies (CSPs) are commonly implemented as a baseline defense for client-side security, restricting the sources from which scripts can be loaded. However, CSPs cannot inspect the actual content of scripts or detect if a trusted script has been altered to become malicious. As a result, CSPs alone are insufficient for full compliance with standards like PCI DSS, which require monitoring for script changes. Organizations must recognize the limitations of both traditional security tools and CSPs, and consider additional measures to detect and prevent sophisticated client-side threats.
Jul 12, 2026
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
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