Una de las ideas más repetidas en seguridad web es que no conviene usar expresiones regulares para parsear HTML. Sin embargo, el problema no es solo teórico. Un investigador conocido como Stealthcopter ha documentado una clase de fallos a la que llama informalmente REGEXSS: vulnerabilidades XSS que aparecen cuando una limpieza de HTML basada en regex, aparentemente inocente, termina rompiendo atributos y abriendo la puerta a inyecciones de código. Su artículo original, publicado en septiembre de 2025, explica cómo convirtió este patrón en varios hallazgos recompensados y cómo un error muy pequeño en una sustitución con preg_replace puede tener consecuencias reales.
Lo interesante del caso es que no se trata de un truco exótico ni de una técnica ligada a un lenguaje muy raro. El patrón aparece justo donde muchos desarrolladores buscan una “solución rápida”: eliminar o reescribir atributos HTML con regex en PHP, JavaScript u otros entornos. Según el investigador, el riesgo aparece cuando una expresión demasiado ambiciosa intenta borrar atributos dentro de HTML ya sanitizado, pero lo hace sin entender el contexto real del documento. El motor de regex trabaja sobre texto plano; no sabe qué es una etiqueta, dónde empieza un atributo o cómo se combinan las comillas dentro del marcado.
El fallo no está en HTML, sino en intentar “arreglarlo” con texto plano
El artículo describe varios errores clásicos de regex que pueden derivar en vulnerabilidades, desde patrones sin anclajes hasta coincidencias demasiado permisivas. Pero su foco está en otra cosa: reemplazos que usan fragmentos como .*? o clases de caracteres amplias dentro de atributos HTML. Aunque a primera vista parecen razonables, esos patrones pueden empezar a coincidir dentro del valor de un atributo y terminar más tarde de lo que el desarrollador esperaba, dejando atributos rotos o promocionando parte del contenido a nuevos atributos ejecutables, como onfocus o onerror.
En otras palabras, una rutina que supuestamente elimina un atributo puede acabar creando una condición de XSS. El ejemplo que usa Stealthcopter es muy gráfico: un preg_replace pensado para borrar data-target="..." puede, con una entrada manipulada, romper el HTML y convertir parte del texto en nuevos atributos activos dentro de una etiqueta <a> o <img>. El resultado no es solo un bypass de filtrado, sino una ejecución de JavaScript que no requiere autenticación previa si la entrada llega desde comentarios o formularios públicos.
Un caso real en WordPress terminó en CVE
La parte más relevante para el ecosistema WordPress es que esta técnica no se quedó en una prueba teórica. WPScan registró CVE-2025-9512 para el plugin Schema & Structured Data for WP & AMP en versiones anteriores a la 1.50. Según la ficha pública, el plugin no gestionaba correctamente ciertas modificaciones de atributos HTML, lo que permitía a atacantes no autenticados lanzar un Stored XSS a través de comentarios. El PoC publicado por WPScan coincide con el patrón descrito por el investigador: una cadena que inyecta comillas y atributos en un enlace para que la sustitución posterior convierta el contenido en un payload ejecutable.
La propia ficha de WPScan indica que el fallo fue verificado, que afectaba a versiones previas a la 1.50 y que su severidad CVSS alcanzó 8,8, una puntuación alta. También atribuye el hallazgo a Matthew Rollings, el investigador detrás de Stealthcopter. Más allá del caso concreto, el episodio deja una lección incómoda para muchos desarrolladores y administradores de WordPress: incluso cuando un plugin ya ha filtrado parte del HTML, una segunda pasada con regex puede empeorar la situación en lugar de mejorarla.
WordPress ya ofrece una alternativa más segura
La solución propuesta en el análisis va en la línea que WordPress lleva tiempo empujando con su HTML API. En lugar de manipular atributos con regex, el investigador muestra cómo se puede recurrir a WP_HTML_Tag_Processor para eliminar atributos concretos de forma estructurada. La documentación oficial de WordPress describe remove_attribute() como un método para quitar un atributo de la etiqueta actualmente seleccionada, y WordPress también mantiene una clase más avanzada, WP_HTML_Processor, que parsea y modifica HTML5 sin tratar el documento como una simple cadena de texto.
Ese detalle es importante porque cambia el enfoque técnico. Un parser entiende la estructura del HTML y trabaja sobre nodos y atributos reales; una regex solo ve caracteres. En el caso de WordPress, esa diferencia no solo ayuda a evitar XSS, sino que además puede simplificar bastante el código. El propio write-up de Stealthcopter subraya que el cambio de regex a WP_HTML_Tag_Processor no solo corrige la vulnerabilidad, sino que sustituye decenas de líneas frágiles por una implementación mucho más clara y mantenible.
La lectura de fondo es bastante clara: con el crecimiento del desarrollo asistido por IA, los “arreglos rápidos” con regex podrían multiplicarse, sobre todo cuando un autocompletado o un modelo genera una función aparentemente plausible para limpiar HTML. El problema es que este tipo de errores no siempre salta a la vista ni se detecta fácilmente con análisis estático. Y por eso la advertencia no afecta solo a cazadores de bugs o autores de plugins: también debería interesar a cualquiera que mantenga código PHP, WordPress o filtros HTML caseros en producción.
Preguntas frecuentes
¿Qué es REGEXSS exactamente?
Es un nombre informal usado por el investigador Stealthcopter para describir casos de XSS que nacen de errores en expresiones regulares usadas para limpiar o modificar HTML. No es una categoría oficial de CWE, pero sí una técnica real documentada con ejemplos prácticos.
¿Por qué usar regex para modificar HTML puede ser peligroso?
Porque las expresiones regulares no entienden la estructura del documento. Trabajan sobre texto plano y pueden empezar y terminar coincidencias dentro de atributos o etiquetas distintas, dejando HTML roto o creando atributos ejecutables.
¿Qué plugin de WordPress se vio afectado por este problema?
Uno de los casos públicos fue Schema & Structured Data for WP & AMP, afectado antes de la versión 1.50 por una vulnerabilidad Stored XSS no autenticada registrada como CVE-2025-9512.
¿Qué alternativa recomienda WordPress frente a regex para tocar HTML?
WordPress ofrece herramientas como WP_HTML_Tag_Processor y WP_HTML_Processor, diseñadas para modificar HTML de forma estructurada y mucho más segura que una sustitución con regex sobre cadenas.
vía: REGEXSS
