CVE-2025-58765: wabac.js Reflected XSS Vulnerability

CVE-2025-58765 Overview

A Reflected Cross-Site Scripting (XSS) vulnerability has been identified in wabac.js, a full web archive replay system that uses Service Workers to implement "wayback machine" functionality. The vulnerability exists in the 404 error handling logic of wabac.js v2.23.10 and below, where the requestURL parameter (derived from the original request target) is directly embedded into an inline <script> block without proper sanitization or escaping.

This flaw allows an attacker to craft a malicious URL that executes arbitrary JavaScript in the victim's browser when they visit a specially crafted link. The potential impact may be limited by CORS policies depending on the deployment context of wabac.js.

Critical Impact

Attackers can execute arbitrary JavaScript in victim browsers through crafted malicious URLs, potentially leading to session hijacking, credential theft, or further attacks on users of wabac.js-powered archive replay systems.

Affected Products

• wabac.js v2.23.10 and earlier versions
• Web archive replay systems using vulnerable wabac.js versions
• Applications implementing wabac.js Service Worker functionality

Discovery Timeline

• 2025-09-09 - CVE CVE-2025-58765 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-58765

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), specifically a Reflected Cross-Site Scripting flaw. The root issue stems from the 404 error handling code path in wabac.js that directly interpolates user-controlled URL data into HTML output without adequate encoding or sanitization.

When wabac.js encounters a 404 error condition, it constructs an error page that includes the original request URL (requestURL) directly within an inline <script> block. Since the URL parameter originates from user input and is not sanitized before inclusion in the HTML response, an attacker can inject malicious JavaScript code that will execute in the context of the victim's browser session.

The attack requires user interaction—the victim must click on or navigate to a malicious link. However, once executed, the injected script runs with the same origin privileges as the wabac.js application, potentially enabling session token theft, DOM manipulation, or redirection to attacker-controlled resources.

Root Cause

The vulnerability originates from insufficient input validation in the error handling logic. The requestURL parameter, which reflects the original request target, is embedded directly into HTML content containing inline JavaScript without proper escaping. This violates secure coding practices for handling untrusted input in web contexts, as the data passes through to the browser as executable code rather than inert text.

Attack Vector

The attack leverages the network-accessible nature of wabac.js deployments. An attacker constructs a URL containing JavaScript payload within the request path or parameters. When a victim navigates to this crafted URL and triggers a 404 error condition, the malicious script executes in their browser.

The attack scenario typically involves:

1. Attacker crafts a malicious URL targeting a wabac.js instance
2. Victim clicks the link (via phishing, social engineering, or embedded link)
3. The wabac.js 404 handler reflects the malicious payload into the error page
4. JavaScript executes in victim's browser with same-origin privileges

The security patch demonstrates the fix by removing raw HTML embedding in the error response:

       if (await handleAuthNeeded(e, this.config)) {
         return notFound(
           request.request,
-          '<p style="margin: auto">Please wait, this page will reload after authentication...</p>',
+          "Please wait, this page will reload after authentication...",
           401,
         );
       }

Source: GitHub Commit 25feb4a

Detection Methods for CVE-2025-58765

Indicators of Compromise

• Unusual URL patterns containing JavaScript code or script tags targeting wabac.js endpoints
• HTTP requests with encoded script payloads in the URL path (e.g., %3Cscript%3E or javascript: sequences)
• 404 error logs showing suspicious URL patterns with potential XSS payloads
• User reports of unexpected browser behavior when accessing archive links

Detection Strategies

• Monitor web application logs for 404 responses containing suspicious URL patterns with script-like content
• Implement Web Application Firewall (WAF) rules to detect and block reflected XSS payload patterns
• Deploy browser-based Content Security Policy (CSP) violation reporting to identify attempted XSS exploitation
• Review HTTP request logs for URLs containing encoded JavaScript or HTML tags

Monitoring Recommendations

• Enable detailed logging for wabac.js Service Worker requests and 404 error handling
• Configure alerting for CSP violations in browsers accessing wabac.js-powered archives
• Monitor for anomalous patterns in referrer headers that may indicate phishing campaigns distributing malicious links
• Implement real-time log analysis for URL patterns matching known XSS attack signatures

How to Mitigate CVE-2025-58765

Immediate Actions Required

• Upgrade wabac.js to version 2.23.11 or later immediately to patch this vulnerability
• Audit any custom implementations or forks of wabac.js for similar input handling issues
• Implement Content Security Policy headers to restrict inline script execution as a defense-in-depth measure
• Review deployment configurations for additional CORS restrictions where applicable

Patch Information

The vulnerability has been fixed in wabac.js version 2.23.11. The fix addresses the XSS attack surface by modifying how templated HTML content handles user-controlled data in error responses. The patch removes raw HTML interpolation in favor of safer text-only messaging.

For detailed patch information, refer to:

• GitHub Security Advisory GHSA-w765-jm6w-4hhj
• GitHub Release v2.23.11
• Security Patch Commit

Workarounds

• Deploy a Web Application Firewall with XSS filtering rules to block malicious requests before they reach the application
• Implement strict Content Security Policy headers disabling inline scripts (script-src 'self' without 'unsafe-inline')
• Consider temporarily restricting public access to wabac.js instances until patching is complete
• Monitor for exploitation attempts and block suspicious IP addresses at the network level

# Example: Add CSP headers to mitigate inline script execution
# For nginx configuration
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';" always;

# For Apache configuration
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';"