CVE-2025-58765: XSS Reflejado en Wayback Machine - Wabac.js
Análisis Rápido: XSS en Wayback Machine CVE-2025-58765
El equipo de research de
DeepSecurity ha identificado y reportado la vulnerabilidad
CVE-2025-58765, un caso de
Reflected Cross-Site Scripting (XSS) en la lógica de manejo de páginas 404 de
wabac.js, componente utilizado por paquetes como
@webrecorder/wabac,
@webrecorder/archivewebpage y
replaywebpage. La falla se origina porque el parámetro
requestURL
es insertado directamente dentro de un bloque
<script>
sin ningún tipo de escape, permitiendo a un atacante construir URLs maliciosas capaces de ejecutar código JavaScript arbitrario en el navegador de la víctima.
XSS reflejado en Javascript
En un XSS tradicional reflejado un valor no sanitizado controlado por el usuario, es usado para renderizar código javascript en el navegador de la víctima. Como ejemplo imaginemos una ruta que le da la bienvenida a un usuario tomando como valor el nombre del usuario de la variable GET name.
URL: https://vulnerabledomain.com/welcome?name=foobar1
HTML Ejemplo:
<h1> Bienvenido
</h1> foobar1
Si un atacante ingresara https://vulnerabledomain.com/welcome?name=<script>alert(1);</script> el código javascript se renderizaría y tendríamos un XSS reflejado clásico.
HTML Ejemplo:
<h1> Bienvenido
</h1> <script>alert(1);</script>
En el caso del XSS reflejado en javascript, siguiendo con el ejemplo de la bienvenida a un usuario, imaginemos la URL es:
https://vulnerabledomain.com/welcome?name=foobar1
el html referencial sería el siguiente:
<h1> Bienvenido
< /h1><div id="bienvenido">
</div>
< script
>
// Asignamos el texto de ?name= al div 'bienvenido'
document. getElementById
( "bienvenido"
). textContent
= "foobfar1"
;
</ script
>
En este caso, el código una vez renderizado en el navegador mostraría el valor foobar1 después de bienvenido, sin embargo, este escenario es ligeramente diferente al anterior porque el payload que podríamos usar ya no requeriría que usemos la etiqueta <script>, dado que el valor de la variable name, se muestra en el contexto de un tag <script>.
La URL con un payload de ejemplo sería algo como la siguiente:
https://vulnerabledomain.com/welcome?name=foobar1";alert(1);//
En este escenario se conseguiría el mismo efecto de mostrar una alerta en el browser de la víctima pero sin necesidad de usar en el payload el tag <script>. Desde un punto de vista ofensivo, es una ventajas que un XSS no requiera de caracteres especiales usados en los tags HTML.
CVE-2025-58765: Impacto de la vulnerabilidad
El XSS reportado en el CVE-2025-58765, afecta varias aplicaciones de forma indirecta, esto es debido a que hay WebApps open source y páginas web de instituciones, que usan wabac.js para generar versiones archivadas de ciertos recursos web. A continuación se detalla como era la explotación del XSS.
- Una aplicación web, integra la librería wabac.js para generar versiones archivadas de distintos sitios web.
- Un atacante construye una URL maliciosa que contiene un payload en la variable RequestURL, el cual es diseñado para ejecutar JavaScript en el navegador de una víctima.
- El link malicioso, es abierto en el navegador de la víctima y se ejecuta el JavaScript reflejado.
- El atacante puede robar cookies (si no están protegidas con HttpOnly/sameSite), realizar acciones CSRF encubiertas o cargar recursos externos de control del atacante.
Nota: no incluimos PoC ni payloads explotables en este post público — para evitar facilitar el abuso y seguir buenas prácticas de divulgación responsable páginas web. Entre las vulnerables expuestas en internet. es parte de la categoría antes mencionada, es reflejado en javascript. era tuvo tres puntos interesantes para mencionar en este write-up.
This is paragraph text. Click it or hit the Manage Text button to change the font, color, size, format, and more. To set up site-wide paragraph and title styles, go to Site Theme.
CVE-2025-58765: XSS en error 404
Dado que es una vulnerabilidad que afecta un número interesante de sitios,
Bypass CSP script-src 'nonce-{nonce}'
Tener una buena implementación de CSP, puede llegar a ser mucho más eficiente que implementar un WAF si se trata de mitigar riesgos. de la seguridad web, el nonce ayuda a prevenir ataques de inyección de scripts (como XSS), asegurando que solo se ejecuten los scripts que incluyan el token válido emitido por el servidor.
En el contexto de una
CSP (Content Security Policy), el término
“nonce” se refiere a un valor único generado aleatoriamente que se usa para autorizar la ejecución de scripts seguros en una página web. Este valor se agrega al encabezado HTTP y a las etiquetas
<script>
para indicar qué código es de confianza.
Al usar un nonce —especialmente en el contexto de una CSP (Content Security Policy)— hay dos reglas clave:
- Usarlo solo una vez por solicitud.
- Debe ser imposible de predecir, generado de forma totalmente aleatoria.
En resumen, un CSP nonce es un token aleatorio que se usa una sola vez para validar una petición.
