El 6 de agosto el proyecto WordPress publicó una versión de seguridad con una instrucción poco habitual por lo directa. Textual: «Because this is a security release, it is recommended that you update your sites immediately» — como se trata de una versión de seguridad, se recomienda que actualices tus sitios de inmediato.

Al día siguiente empezaron a aparecer, en el registro público de GitHub, repositorios con código para atacar exactamente esa falla. Al cierre de esta nota, el 13 de agosto, son veintiuno.

Esa es la mitad que ya circula. La otra casi nadie la está contando, y es la que decide si tu sitio está adentro o afuera del problema: este parche no se está empujando a la fuerza. El de julio sí.

¿Qué es XSS2Shell y por qué WordPress pidió actualizar de inmediato?

El propio aviso describe la falla más seria en una línea: «Pre-auth reflected cross-site scripting (XSS) on the login screen with potential to lead to PHP code execution», reportada por el equipo de pwn.ai. El nombre de la cadena se lo pusieron ellos, y así la están publicando los medios de seguridad.

Vale la pena desarmar la frase, porque cada pedazo dice algo:

Pre-auth significa que el atacante no necesita cuenta, contraseña ni permiso alguno. Le basta la pantalla de acceso de tu sitio, que por definición es pública y está abierta a todo internet.

Reflected XSS significa que consigue que esa página devuelva código que el navegador de quien la abre va a tratar como si fuera tuyo. No es que el atacante entre a tu servidor: es que tu propia página le presta la voz.

Con potencial de derivar en ejecución de código PHP es la parte que hay que leer despacio. El aviso dice potential to lead to. Potencial. No dice que esté ocurriendo, y el mismo aviso aclara que la cadena requiere interacción explícita de la víctima: alguien con sesión de administrador abierta tiene que hacer clic en algo que le mandaron. Esta falla no entra sola. Entra por la persona con más permisos y menos sospecha del equipo.

Estirar ese potencial hasta «te van a tumbar el servidor» sería vender miedo. El hecho real ya alcanza: la falla existe, está corregida desde el 6 de agosto, y desde el día siguiente hay código público que se presenta como prueba de concepto para explotarla.

¿Por qué tu sitio puede seguir expuesto aunque WordPress ya lo haya corregido?

Aquí está el detalle que cambia todo, y son dos frases de dos avisos distintos del mismo proyecto.

En julio, cuando salió la versión anterior, WordPress escribió: «Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions». Por la severidad, se activaron actualizaciones forzadas.

Este mes, la única frase sobre el tema es otra: «Sites that support automatic background updates will begin updating shortly». Los sitios que soportan actualizaciones automáticas empezarán a actualizarse en breve.

Los que las soportan. No todos. Los que las tienen prendidas.

Hay una puerta en tu oficina que se cierra sola. Tiene un brazo hidráulico arriba, nadie la piensa, nadie la administra. Hasta el día en que a alguien le molestó el golpe y le puso un tope de hule. El tope funcionó: dejó de sonar. También dejó de cerrarse la puerta.

En julio, WordPress hizo el equivalente a pasar por el pasillo y quitar el tope: cerró la puerta por ti, aunque tú no supieras que estaba abierta. Este mes no pasó nadie. Si tu sitio trae tope de hule, ahí sigue.

Si tu sitio corre La versión corregida que le toca Qué hacer En cuánto tiempo
7.0.0 a 7.0.2 7.0.3 Respaldo y actualizar el núcleo desde el panel Hoy
Cualquier 6.x (6.0 a 6.9) La última de tu rama: 6.9.6, 6.8.7, 6.7.6… Respaldo y actualizar; si el sitio lo aguanta, subir a 7.0.3 Hoy
Cualquier 5.x, o 4.7 a 4.9 La última de tu rama, hasta 4.7.34 Respaldo, actualizar, y agendar la conversación de migración El parche hoy; la migración, este trimestre
Anterior a 4.7 No hay Ese sitio quedó fuera del alcance de las correcciones del proyecto Migración, no parche
Cualquiera con las actualizaciones automáticas apagadas La que le toque de arriba Actualizar a mano: esta vez no se está forzando Hoy

Fuentes: rango afectado (4.7.0 a 7.0.2), versiones corregidas y puntaje CVSS de 8.9, del aviso de seguridad de WordPress para CVE-2026-64638, publicado el 6 de agosto de 2026. Que las versiones anteriores a la 4.7 quedan fuera del rango de retroporte, en la cobertura de The Hacker News del 7 de agosto de 2026.

¿Cómo veo en treinta segundos en qué versión está mi sitio?

Entra al panel —normalmente tudominio.com/wp-admin— y ve a Escritorio → Actualizaciones. Arriba de todo, WordPress te dice en qué versión estás. Compárala con la tabla y ya sabes si estás adentro o afuera.

Si no tienes usuario del panel, ese es el primer hallazgo del día y es más importante que la versión: significa que no puedes ni mirar. Pídelo hoy.

Y si no eres tú quien entra ahí, esta pieza entera cabe en un mensaje que le mandas ahorita a quien te lleva el sitio:

> ¿En qué versión de WordPress estamos y están prendidas las actualizaciones automáticas?

Si te contesta hoy, con el número y con un sí o un no, tienes proveedor. Si te contesta «lo reviso y te aviso», tienes sitio.

¿Y si las actualizaciones automáticas están apagadas?

En esa misma pantalla, WordPress te dice en una línea si el sitio se actualiza solo con las versiones de mantenimiento y seguridad. Si dice que no, alguien lo apagó. Se pudo apagar en tres lugares distintos: el archivo de configuración del sitio, un complemento de mantenimiento, o el propio hosting. Quien administra el sitio sabe cuál es.

Los tres se vuelven a prender. Lo que no se resuelve solo es la pregunta de atrás: quién lo apagó y por qué.

Casi siempre hay una razón buena. Una actualización tumbó el sitio un viernes en la tarde. Una plantilla comprada dejó de ser compatible. El desarrollo está modificado a mano y las actualizaciones pisaban los cambios. El proveedor anterior se fue y el que quedó prefirió no mover nada.

Ninguna de esas decisiones fue tonta. Todas fueron el tope de hule: resolvían el golpe de hoy a cambio de dejar la puerta abierta el resto del año. Y ninguna quedó escrita en ningún lado, porque el día que se toman no se sienten una decisión, se sienten un ajuste.

Si esa razón sigue viva, actualizar puede romper algo. Por eso el orden correcto es respaldo, actualización, revisión — y no «lo dejamos así». Un sitio viejo que se rompe al actualizar ya estaba roto; solo no se había enterado. Quién responde cuando eso pasa es, al final, la misma pregunta que decide con quién trabajas.

[EXPERIENCIA PENDIENTE: ¿Kynoz revisó los sitios WordPress que mantiene tras el aviso del 6 de agosto? ¿Cuántos son, cuántos tenían las actualizaciones automáticas prendidas y cuántos ya estaban en la versión corregida sin que nadie tocara nada? Una sola cifra real convierte esta pieza en la única del tema con dato propio.]

¿Qué reviso si sospecho que ya entraron?

Cuatro cosas, en el panel, en diez minutos: usuarios administradores que no reconozcas, contraseñas de aplicación que nadie recuerda haber creado, complementos activos que nadie instaló, y archivos nuevos con extensión .php dentro de la carpeta de subidas.

Si aparece algo, no lo borres todavía. Cambia contraseñas, cierra todas las sesiones abiertas y llama a alguien que sepa. Borrar la evidencia es lo primero que uno quiere hacer y lo único que después hace falta.

Una nota sobre la fecha que está arriba

La cobertura del 7 de agosto —la misma que citamos abajo— decía que no había prueba de concepto pública. Era cierto cuando se escribió. Un día después, el registro público de GitHub dice otra cosa.

Nadie se equivocó: esto se mueve en horas. Por eso las piezas de seguridad llevan fecha visible, y por eso lo honesto es decir hasta dónde llega lo que verificamos. Abrimos los dos avisos del proyecto y consultamos la búsqueda de repositorios de la API de GitHub. Lo que no hicimos fue ejecutar ese código ni comprobar que funcione: lo verificado es que existe, que es público y que se presenta como prueba de concepto. Y lo que sigue sin estar documentado, al día de hoy, es explotación en sitios reales.

WordPress hizo su parte, y la hizo bien: alguien reportó la falla de forma responsable, el proyecto la corrigió y llevó la corrección hacia atrás hasta ramas de hace casi una década. Lo único que el proyecto no puede hacer es entrar a tu sitio a quitar el tope de hule. Esa parte es de este lado del pasillo.

Si tienes equipo técnico, hoy te toca una sola pregunta y ya está escrita arriba. Si no lo tienes, escríbenos por el formulario de contacto o por WhatsApp y revisamos en qué versión corre tu sitio, sin costo: te decimos qué encontramos, trabajemos juntos después o no.

Preguntas frecuentes

¿Qué es exactamente un pre-auth XSS y por qué preocupa tanto?

«Pre-auth» quiere decir que el atacante no necesita cuenta ni contraseña: dispara la falla desde la pantalla de acceso, que es pública. «XSS» quiere decir que logra que esa página devuelva código que el navegador de quien la abre trata como si fuera del sitio. Lo que sube la gravedad es lo que viene después: el aviso oficial habla de potencial de derivar en ejecución de código PHP en el servidor. Potencial, y la palabra la puso el proyecto, no nosotros.

¿Ya hay ejecución remota de código en sitios reales?

No documentada. Al 13 de agosto, ni el aviso del proyecto ni la cobertura que abrimos reportan explotación en el mundo real. Lo que sí es público es el código de prueba, y esa distinción es justamente lo que hace que actualizar hoy salga barato: se está corrigiendo un riesgo, no un incidente.

¿Cuánto tarda actualizar y quién debería hacerlo?

En un sitio sano, el respaldo y la actualización del núcleo se hacen en una sola sesión de trabajo, sin cerrar el sitio al público. Lo debe hacer quien lo administra, no el dueño del negocio desde el celular: si algo truena, hay que saber devolverlo. Si nadie tiene ese papel asignado hoy, ese es el problema que la falla acaba de sacar a la luz.

¿Actualizar puede romper mi sitio?

Puede, sobre todo si la plantilla o algún complemento están modificados a mano. Por eso el orden es respaldo, actualización, revisión. Lo que no es una opción es quedarse sin actualizar de forma indefinida: el riesgo no se queda quieto mientras tú te decides.

Mi sitio no es WordPress, ¿me toca algo?

Esta falla en particular, no. La pregunta de fondo, sí: cualquier gestor de contenidos, tienda en línea o sistema a la medida tiene versiones, actualizaciones y cuentas de administrador. Cambia el nombre del tablero, no la conversación.

¿Conviene migrar a otra cosa por esto?

No por esto. Migrar por una falla puntual es cambiar de puerta en vez de quitarle el tope. Se justifica cuando el sitio dejó de ser un folleto —cuando ya cobra, agenda, factura o guarda datos de clientes— y el gestor empieza a estorbar más de lo que ayuda.

Fuentes