After the DOMPurify Patch: Hardening Rich Content Rendering Against CVE-2026-65898

+Patching DOMPurify to 3.4.11 or later closes the known shared-allowlist defect. It does not by itself prove that every rich-content workflow is safe. Applications can still share sanitizer state across trust domains, grant attributes too broadly, or rely on browser controls to compensate for unsafe output. CVE-2026-65898 is a useful point to review those assumptions.
+## Vulnerability overview
+DOMPurify through 3.4.10 can retain an attribute added by an uponSanitizeAttribute hook on the setConfig() path. The upstream advisory describes stored XSS when a trusted render pollutes the allowlist and a later untrusted render inherits the dangerous attribute. The patched upstream versions are 3.4.11 and later.
+Splunk Enterprise fixed the bundled component in 9.4.16, 10.0.11, 10.2.8, and 10.4.4 or later. The advisory says the dashboard-studio package now uses DOMPurify 3.4.14. It does not report a real-world Splunk exploitation campaign.
+## Separate sanitizer state by trust domain
+The clean design uses a sanitizer instance with a policy that is appropriate to one trust domain. Administrative content, imported content, and ordinary user content may need different policies or no HTML at all. If they share an instance, the lifetime of a hook mutation becomes the lifetime of the shared policy.
+Use per-call configuration when it fits the workflow. When a persistent policy is required, create separate instances and make the boundary explicit in code. Avoid a shared instance whose allowlist changes based on a marker that an attacker might influence. The marker should not be the only thing separating a trusted attribute from an untrusted one.
+data.keepAttr = true can allow an attribute for the current element without writing into the shared allowlist, according to the upstream mitigation guidance. clearConfig() can reset state between trust domains, but relying on every caller to reset the same global instance is harder to verify than giving the domains separate instances.
+## Keep the allowlist narrow
+CVE-2026-65898 is most damaging when the polluted attribute is executable. Review the attributes that the application permits. Remove event handlers, URL-bearing attributes, and rich markup that the interface does not need. A sanitizer cannot protect a policy that intentionally accepts executable attributes.
+Do not add a broad compatibility exception because a widget failed to render. Define the allowed tags and attributes for the feature, test the resulting HTML, and keep the exception local to the component that needs it.
+## Make the browser defense independent
+A Content Security Policy can reduce the effect of injected script. It does not fix sanitizer state. Deploy CSP as a separate control, monitor violation reports, and test the application with the production policy. Nonces and hashes should be managed so a legitimate widget update does not silently weaken the page.
+Cookie attributes, token storage, and response authorization also shape the impact of stored XSS. Review whether sensitive browser APIs and administrative actions are available from the pages that render user-controlled content. This review is broader than the vendor patch and should include product owners.
+## Establish a release gate
+The deployment gate should verify the fixed Splunk release and the named DOMPurify asset. For custom applications, require a package version and a browser regression test. The test should display a trusted element that exercises the hook, then an untrusted element that should lose the same attribute.
+Record the test result with the build hash and browser version. If the application does not expose the dynamic hook, record that finding and explain how the code was reviewed. NOT_APPLICABLE should be supported by evidence, not inferred from the vendor severity.
+## Monitor the stored-content path
+Monitor the application routes that render rich content and the sources that can create it. Capture authorization changes, unexpected modifications, and security events around the page. Preserve the raw stored value when investigating a report, because a rendered screenshot may omit the attribute that caused the issue.
+Application owners should know which groups can create content, which groups can view it, and what the page can do in the browser. That information turns a generic XSS advisory into a concrete exposure decision.
+## Exposure context
+ZoomEye app="Splunk" returned 47,695 product-fingerprint matches on November 3, 2026. The CVE filter returned zero. The number supports asset discovery and patching scope. It does not prove a vulnerable release, a reachable hook, or an active compromise.
+## Practical end state
+Upgrade the platform, verify the bundled package, isolate sanitizer instances by trust domain, narrow the allowed attributes, and test stateful rendering behavior. Keep the policy and test evidence with the application release. The program should be able to explain why a rich-content path is safe after the dependency update, not only that the dependency version changed.
+## References
+- DOMPurify GHSA-cmwh-pvxp-8882
+- Splunk SVD-2026-1009
+- Red Hat CVE-2026-65898