CVE-2026-3990: CesiumGS CesiumJS XSS Vulnerability

CVE-2026-3990 Overview

A Cross-Site Scripting (XSS) vulnerability has been discovered in CesiumGS CesiumJS versions up to 1.137.0. The vulnerability exists within the Apps/Sandcastle/standalone.html file, where manipulation of the c argument allows attackers to inject malicious scripts. This flaw can be exploited remotely without requiring authentication, potentially enabling attackers to execute arbitrary JavaScript in the context of a victim's browser session.

Critical Impact

Remote attackers can exploit this XSS vulnerability to inject malicious scripts through the c parameter in the Sandcastle demo application, potentially stealing session tokens, performing actions on behalf of users, or redirecting victims to malicious sites.

Affected Products

• CesiumGS CesiumJS up to version 1.137.0
• Sandcastle demo application (Apps/Sandcastle/standalone.html)

Discovery Timeline

• 2026-03-12 - CVE-2026-3990 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-3990

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), commonly known as Cross-Site Scripting. The flaw resides in the Sandcastle demo application's standalone.html file, which fails to properly sanitize the c argument before rendering it in the page context.

The attack requires user interaction, as the victim must navigate to a maliciously crafted URL containing the XSS payload. Once triggered, the injected script executes within the security context of the vulnerable application, allowing the attacker to access sensitive information, modify page content, or perform actions on behalf of the authenticated user.

It's worth noting that according to a related vulnerability disclosure (CVE-2023-48094), the vendor's position is that Apps/Sandcastle/standalone.html is demo code included in the CesiumGS/cesium GitHub repository but is not considered part of the production CesiumJS JavaScript library product. The vendor was contacted early about this disclosure but did not respond.

Root Cause

The root cause is insufficient input validation and output encoding of the c parameter in the standalone.html file. When user-controlled input is reflected back into the HTML page without proper sanitization, it creates an opportunity for attackers to inject and execute arbitrary JavaScript code. The application fails to implement adequate content security policies or input filtering mechanisms that would prevent the injection of script content.

Attack Vector

This vulnerability is exploitable via the network attack vector. An attacker can craft a malicious URL containing JavaScript code in the c parameter and distribute it through phishing campaigns, social engineering, or by embedding the link in web content. When a victim clicks the link or is redirected to the crafted URL, the malicious script executes in their browser within the context of the vulnerable CesiumJS Sandcastle application.

The attack does not require any privileges but does require user interaction (clicking the malicious link). The vulnerability allows an attacker to modify the integrity of the web page content within the victim's session.

For technical details regarding the exploit mechanism, refer to the GitHub Issue Discussion and VulDB entry #350473.

Detection Methods for CVE-2026-3990

Indicators of Compromise

• Suspicious HTTP requests to /Apps/Sandcastle/standalone.html containing encoded JavaScript payloads in the c parameter
• Web server logs showing URL patterns with script tags, event handlers, or JavaScript protocols in query strings
• Unusual outbound connections from user browsers after accessing CesiumJS demo pages

Detection Strategies

• Implement web application firewall (WAF) rules to detect XSS payloads in URL parameters targeting standalone.html
• Monitor HTTP access logs for requests containing common XSS attack patterns such as <script>, javascript:, or event handler attributes in the c parameter
• Deploy browser-based detection mechanisms to identify and block reflected XSS attempts

Monitoring Recommendations

• Enable detailed logging for all requests to the Sandcastle demo application directory
• Configure alerting for patterns matching XSS payload signatures in HTTP query strings
• Review Content Security Policy (CSP) violation reports if CSP is implemented

How to Mitigate CVE-2026-3990

Immediate Actions Required

• Remove or restrict access to the Apps/Sandcastle/ directory in production deployments
• Implement Content Security Policy (CSP) headers to prevent inline script execution
• Deploy web application firewall rules to filter XSS payloads in the c parameter
• Consider blocking direct access to standalone.html if the Sandcastle demo is not required

Patch Information

At the time of publication, no official vendor patch has been released. The vendor was contacted but did not respond to the disclosure. The vendor's stated position is that Apps/Sandcastle/standalone.html is demo code and not part of the production CesiumJS library. Organizations using CesiumJS should evaluate whether the Sandcastle demo application is necessary for their deployment and take appropriate protective measures.

For additional information, see the VulDB submission #769630 and VulDB CTI Incident #350473.

Workarounds

• Remove or delete the entire Apps/Sandcastle/ directory from production deployments if demo functionality is not required
• Implement server-side access controls to restrict access to the Sandcastle demo application to trusted internal networks only
• Add custom input sanitization at the web server level to filter potentially malicious input in the c parameter
• Deploy strict Content Security Policy headers that disallow inline scripts and restrict script sources

# Example nginx configuration to block access to Sandcastle demo
location /Apps/Sandcastle/ {
    # Option 1: Deny all access
    deny all;
    return 403;
    
    # Option 2: Restrict to internal networks only
    # allow 10.0.0.0/8;
    # allow 192.168.0.0/16;
    # deny all;
}

# Add Content Security Policy header
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';" always;