WordPress vuelve a dejar una advertencia muy útil para desarrolladores, autores de plugins y administradores de sitios: tocar HTML con expresiones regulares puede salir caro. Un análisis publicado por el investigador Stealthcopter ha vuelto a poner el foco en una clase de vulnerabilidades que, aunque no son nuevas en esencia, sí están empezando a describirse con más claridad dentro del ecosistema web. El punto de partida es simple: una regex pensada para “limpiar” atributos HTML puede acabar rompiendo el marcado y facilitando una inyección XSS.
La idea parece técnica, pero sus consecuencias son muy prácticas. En vez de eliminar un atributo concreto de una etiqueta, una expresión regular mal planteada puede empezar a coincidir dentro del valor de otro atributo, desplazarse más de la cuenta y dejar tras de sí un HTML alterado que convierte texto controlado por el atacante en nuevos atributos ejecutables. En algunos casos, eso basta para activar un onfocus, un onerror o un enlace con comportamiento peligroso.
Lo relevante para la comunidad WordPress es que no se trata de una hipótesis académica. Uno de los casos públicos citados en este tipo de investigaciones afectó al plugin Schema & Structured Data for WP & AMP, donde una sustitución con preg_replace aplicada a comentarios de usuarios no autenticados terminó derivando en un Stored XSS. Es decir, un fallo que no exigía acceso previo al panel y que podía aprovecharse desde una entrada pública del sitio.
Una de las partes más interesantes de este tipo de fallos es que muchas veces aparecen después de una primera fase de sanitización. El desarrollador cree que el contenido ya está controlado, pero añade una segunda pasada con regex para quitar atributos concretos como itemprop, itemscope o similares. Y es ahí donde se abre la grieta.
La razón es bastante sencilla: una expresión regular no entiende el árbol HTML. Solo ve texto. No sabe dónde empieza realmente una etiqueta, qué comillas pertenecen a qué atributo o si una coincidencia está atravesando los límites lógicos del documento. Por eso una sustitución aparentemente inocente puede terminar eliminando más de lo previsto y dejando un payload activo donde antes solo había un valor de atributo.
En WordPress esto importa especialmente porque durante años muchos plugins y snippets rápidos han recurrido a preg_replace como una forma cómoda de retocar HTML. Funciona rápido, ocupa pocas líneas y da la sensación de resolver el problema. El inconveniente es que también introduce fragilidad, especialmente cuando el contenido procede de comentarios, bloques, campos personalizados, shortcodes o salidas transformadas por varios filtros.
La buena noticia es que WordPress no obliga a seguir usando ese enfoque. Desde hace tiempo, el core ofrece herramientas pensadas precisamente para trabajar con HTML de forma estructurada, sin tratarlo como una simple cadena de texto. En este contexto, la referencia más importante es WP_HTML_Tag_Processor, una clase que permite recorrer etiquetas y eliminar atributos concretos de manera mucho más segura y comprensible.
La diferencia es clave: mientras una regex intenta adivinar el HTML a base de patrones, el procesador de etiquetas trabaja con la estructura real del documento. Eso evita que el desarrollador tenga que jugar con comillas, cuantificadores y reemplazos ambiguos. También mejora la mantenibilidad del código, porque una llamada como remove_attribute() resulta mucho más clara que una cadena de preg_replace() encadenadas y difíciles de auditar.
Para un medio especializado en WordPress, esta historia deja un mensaje bastante útil: parte del riesgo no viene de grandes técnicas de explotación, sino de malas decisiones de implementación cotidiana. A veces el problema no está en un sistema complejo, sino en una línea de PHP escrita con prisas para “limpiar” algo que ya parecía casi resuelto.
Este tema además gana peso en un momento en el que cada vez más desarrolladores usan asistentes de código o autocompletado para resolver tareas rutinarias. Es relativamente fácil que una herramienta de IA sugiera una regex razonable a primera vista para modificar HTML. El problema es que ese tipo de solución puede parecer correcta en un ejemplo simple y ser insegura en escenarios reales con entradas maliciosas.
Para el ecosistema WordPress, donde miles de plugins pequeños y medianos resuelven problemas concretos con código práctico y rápido, esta combinación es especialmente delicada. Un snippet que “funciona” no siempre es un snippet seguro. Y cuando hablamos de comentarios, formularios o contenido generado por usuarios, esa diferencia importa mucho.
La lección de fondo es clara: si un plugin necesita manipular atributos HTML, eliminar marcas concretas o transformar etiquetas, lo sensato no es seguir apostando por regex, sino apoyarse en las APIs que WordPress ya pone sobre la mesa. No solo por seguridad, sino también por claridad, mantenimiento y compatibilidad a largo plazo.
El caso documentado por Stealthcopter sirve así como recordatorio para toda la comunidad WordPress: el viejo consejo de no parsear HTML con regex sigue plenamente vigente. Y en 2026, con más automatización, más código asistido por IA y más presión por desarrollar rápido, probablemente sea más importante que nunca.
¿Qué tipo de fallo se puede producir al usar regex sobre HTML en WordPress?
Puede aparecer un XSS si la expresión regular elimina o reemplaza atributos de forma incorrecta y acaba rompiendo el contexto del HTML, permitiendo que parte del contenido del atacante se convierta en un nuevo atributo ejecutable.
¿Qué plugin de WordPress se vio afectado por un caso público de este tipo?
Uno de los casos más comentados fue el de Schema & Structured Data for WP & AMP, donde se documentó un Stored XSS no autenticado ligado a este patrón de manipulación de atributos.
¿Qué alternativa recomienda WordPress frente a preg_replace() para modificar HTML?
La opción más recomendable es usar WP_HTML_Tag_Processor o las APIs HTML del core, porque entienden la estructura del documento y permiten operar sobre atributos reales sin depender de coincidencias frágiles.
¿Este problema afecta solo a plugins antiguos?
No necesariamente. Puede aparecer en cualquier plugin, tema o snippet personalizado que siga usando regex para limpiar o reescribir HTML, especialmente si trabaja con contenido generado por usuarios.
vía: REGEXSS
