CVE-2025-66021

What it actually does

The OWASP Java HTML Sanitizer does not sanitize CSS when HtmlPolicyBuilder allows both noscript and style elements and permits text inside style via allowTextIn. Untrusted markup can therefore retain tags and constructs that are not in the declared HTML policy, so applications that treat sanitizer output as safe HTML can still emit content that browsers execute as script (cross-site scripting).

Why it matters to the business

In SUSE Manager / Spacewalk 3.2 web consoles this can let an attacker run code in an operator’s browser and abuse a logged-in management session (view or change managed systems, configurations, or credentials). CVSS is 8.1, but EPSS is very low and flat (~0.0025 over 30 days), the issue is not in CISA KEV, it is not associated with ransomware, exploit maturity is none, and it has been public for about 307 days without known mass exploitation—so opportunistic risk is limited, while residual risk remains for unpatched 3.2 management servers and proxies that still render untrusted HTML through this sanitizer.

How an attack unfolds

An attacker who can submit HTML that is processed by a permissive HtmlPolicyBuilder (noscript and style allowed, with text permitted inside style) sends markup whose CSS or nested content is not stripped. The sanitizer returns HTML the application stores or reflects. When an authenticated operator opens the affected page, the browser runs the injected content in that origin, which can steal session material or perform actions as that user in the management UI. No named threat actors or campaigns are associated with this CVE, and there is no public exploit maturity.

How to fix it

Patch SUSE Manager 3.2 / Proxy 3.2 packages to the listed fixed versions: spacewalk-web 2.8.7.12-3.16.12 (Server and Proxy); python-susemanager-retail 1.0.1544459934.07229ad-2.9.13; saltboot-formula 0.1.1546527519.591e925-3.9.13; spacecmd 2.8.25.8-3.12.13; spacewalk-branding 2.8.5.13-3.13.14; spacewalk-java 2.8.78.18-3.21.1; spacewalk-setup 2.8.7.6-3.13.13; spacewalk-utils 2.8.18.4-3.6.13; susemanager 3.2.15-3.16.13; susemanager-docs_en 3.2-11.15.12; susemanager-schema 3.2.16-3.16.13; susemanager-sls 3.2.20-3.18.1; susemanager-sync-data 3.2.12-3.14.2; tika-core 1.20-3.6.13; spacewalk-backend 2.8.57.8-3.10.14 (Server and Proxy); spacewalk-client-tools 2.8.22.4-3.3.13 (Server and Proxy); spacewalk-proxy-installer 2.8.6.4-3.6.13; branch-network-formula 0.1.1545038754.c983fa6-3.6.13; netty 4.1.8.Final-2.7.4; py26-compat-salt 2016.11.10-6.18.14; smdba 1.6.3-0.3.6.13; spacewalk-admin 2.8.4.3-3.3.13. Independently, do not allow noscript together with style plus allowTextIn; use a strict allow-list HtmlPolicyBuilder and do not treat unsanitized CSS as safe. If you cannot patch immediately, stop rendering untrusted HTML in those UIs and restrict who can submit HTML into management consoles.

How to confirm the fix worked

Confirm installed RPM versions match or exceed the fixed versions above (rpm -q on each listed package). Review application HtmlPolicyBuilder configuration and ensure noscript is not allowed with style text. After upgrade, submit benign HTML that contains noscript and style elements into the same fields and verify they are removed or CSS is escaped with no leftover executable markup. Re-scan web dependencies for the OWASP Java HTML Sanitizer and confirm the SUSE 3.2 stack is fully updated.

Typical attack path

1. Find a SUSE Manager / Spacewalk (or other) feature that sanitizes untrusted HTML with OWASP Java HTML Sanitizer under a policy that allows noscript and style with text inside style.
2. Submit HTML that depends on that policy gap so disallowed tags or script-bearing CSS survive sanitization.
3. Have a privileged user view the stored or reflected page (or lure them to it).
4. Run script in the victim’s browser origin to steal session tokens or act as that operator.
5. Use the hijacked management session to inspect or alter managed infrastructure.

How to detect it

There is no public exploit and no named actor activity, so look for attempts rather than known malware. Review application and reverse-proxy logs for POST/PUT bodies or query parameters that include both noscript and style markup destined for pages that render sanitized HTML. Inspect stored HTML in comments, descriptions, branding, and similar fields for those tag combinations. On the client side, look for unexpected script execution or new outbound requests immediately after an operator opened user-supplied HTML. Correlate with anomalous management-API or UI actions from that operator’s session. Web access logs, WAF logs, application audit logs, and browser-related EDR telemetry are the primary sources.

• <noscript>
• </noscript>
• allowTextIn("style")
• HtmlPolicyBuilder
• <style>

What your security team should do

• Prioritize patching internet-facing and admin-console SUSE Manager 3.2 Server and Proxy hosts to the exact fixed package versions.
• Inventory HtmlPolicyBuilder (and equivalent sanitizer) policies and remove noscript plus style/allowTextIn combinations.
• Limit who can submit HTML into management UIs until patches are confirmed.
• Hunt historically for stored HTML containing both noscript and style in user-controlled fields, then rotate sessions of operators who viewed that content.
• Track EPSS/KEV; there is no current KEV or ransomware flag, but reassess if exploit maturity changes.