CVE-2025-69993: Leaflet bindPopup() XSS Vulnerability

CVE-2025-69993 Overview

A Cross-Site Scripting (XSS) vulnerability has been identified in Leaflet, a popular open-source JavaScript library for interactive maps. Leaflet versions up to and including 1.9.4 are vulnerable to XSS via the bindPopup() method. This method renders user-supplied input as raw HTML without sanitization, allowing attackers to inject arbitrary JavaScript code through event handler attributes. When a victim views an affected map popup, the malicious script executes in the context of the victim's browser session, potentially leading to session hijacking, credential theft, or further malicious actions.

Critical Impact

Attackers can inject malicious JavaScript through unsanitized popup content, enabling session hijacking, credential theft, and unauthorized actions on behalf of authenticated users viewing affected maps.

Affected Products

• Leaflet versions up to and including 1.9.4
• Web applications using vulnerable Leaflet versions with user-controlled popup content
• Any implementation passing unsanitized user input to the bindPopup() method

Discovery Timeline

• 2026-04-14 - CVE-2025-69993 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2025-69993

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), commonly known as Cross-Site Scripting (XSS). The root issue lies in how the Leaflet library handles HTML content passed to the bindPopup() method, which is used to attach interactive popups to map markers and other map elements.

The bindPopup() method accepts HTML content as a parameter and directly renders it in the Document Object Model (DOM) without performing any input sanitization or encoding. This design decision, while enabling flexible HTML-based popup customization, creates a significant security risk when user-controlled data is passed to this method.

An attacker can craft a malicious payload using HTML elements with JavaScript event handlers. For example, an <img> tag with an invalid src attribute combined with an onerror handler can execute arbitrary JavaScript when the popup is displayed and the image fails to load.

Root Cause

The vulnerability stems from the lack of input sanitization in the bindPopup() method implementation. The method was designed to accept arbitrary HTML content for maximum flexibility in popup customization, but this approach inherently trusts all input data. When applications pass user-controlled content to this method without implementing their own sanitization, the unsanitized HTML is rendered directly in the browser, allowing script injection through event handler attributes or other JavaScript-executing HTML constructs.

Attack Vector

The attack requires network access and user interaction. An attacker must be able to inject malicious content into a data source that populates map popups (such as a database, API response, or URL parameter). The attack executes when a victim user interacts with the map and triggers the popup display.

A typical attack scenario involves:

1. The attacker identifies an application using Leaflet where popup content is derived from user-controllable input
2. The attacker submits malicious HTML content containing JavaScript event handlers (e.g., <img src=x onerror="alert('XSS')">)
3. The application stores or reflects this content without sanitization
4. When a victim user clicks on the affected map marker, the popup renders and the malicious script executes in the victim's browser session

The scope is changed (S:C in the CVSS vector), meaning the vulnerability can impact resources beyond its security scope, affecting the user's browser session and potentially other applications sharing the same origin.

Detection Methods for CVE-2025-69993

Indicators of Compromise

• Unusual HTML tags or JavaScript event handlers appearing in map popup data sources
• Network requests containing XSS payloads targeting popup functionality
• Reports of unexpected JavaScript execution or browser behavior when viewing maps
• Suspicious modifications to database fields storing popup content

Detection Strategies

• Implement Content Security Policy (CSP) headers to detect and block inline script execution attempts
• Monitor application logs for requests containing common XSS payload patterns such as onerror, onload, or <script> tags in popup-related parameters
• Deploy Web Application Firewalls (WAF) with rules to detect XSS payloads in request parameters
• Conduct regular security audits of code paths that pass user input to bindPopup()

Monitoring Recommendations

• Enable browser security headers reporting to capture CSP violations
• Monitor client-side error logging for unexpected script execution patterns
• Review and audit all data sources that feed into Leaflet popup content
• Implement anomaly detection for unusual characters or encoding in map-related database fields

How to Mitigate CVE-2025-69993

Immediate Actions Required

• Audit all code using Leaflet's bindPopup() method to identify instances where user-controlled data is passed
• Implement server-side input sanitization for all content destined for map popups
• Deploy client-side HTML sanitization libraries (such as DOMPurify) before passing content to bindPopup()
• Consider using the bindPopup() text-only option or implement a whitelist-based HTML sanitizer

Patch Information

At the time of publication, organizations should monitor the Leaflet Official Website and the GitHub Security Advisory CVE-2025-69993 for official patch releases and updated guidance from the Leaflet development team.

Workarounds

• Sanitize all user input before passing it to bindPopup() using a trusted HTML sanitization library like DOMPurify
• Use the textContent property or create DOM elements programmatically instead of passing raw HTML strings
• Implement a strict Content Security Policy (CSP) that blocks inline scripts and eval()-style execution
• Restrict popup content to a predefined set of safe HTML elements using a whitelist approach

# Example: Implementing Content Security Policy headers
# Add to your web server configuration (nginx example)
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline';" always;

# For Apache, add to .htaccess or server config
# Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';"