WordPress 7.0.3 corrige XSS2Shell: cómo verificar una cartera

Respuesta corta: WordPress 7.0.3 es una actualización de seguridad y debe desplegarse cuanto antes. Corrige doce problemas, incluido CVE-2026-64638 —un XSS reflejado previo a la autenticación en la pantalla de acceso que puede terminar en ejecución de código si un administrador autenticado cae en un enlace preparado—. Para una agencia, cerrar el trabajo exige comprobar la versión corregida de cada sitio, revisar quién conserva privilegios de administración y tratar como no verificados los WordPress sin acceso o sin evidencia reciente.

Esta guía está dirigida a agencias, freelancers y equipos que mantienen varias instalaciones. La publica Vulnity. Los datos sobre versiones y vulnerabilidades proceden de WordPress.org y del investigador; la secuencia de priorización y cierre es criterio editorial para operar una cartera. No hay una fuente primaria que confirme explotación activa generalizada durante esta revisión.

Publicado y revisado el 12 de agosto de 2026.

Qué corrige WordPress 7.0.3

El anuncio oficial de WordPress 7.0.3, publicado el 6 de agosto, enumera doce correcciones de seguridad. Incluyen XSS reflejado y almacenado, elevación de privilegios en Multisite, divulgación de información, inyección CSS, elusión de confirmación de correo y SSRF hacia rangos link-local. WordPress recomienda actualizar inmediatamente.

El problema más sensible es CVE-2026-64638, divulgado por el equipo de pwn.ai como XSS2Shell. El punto de entrada está en wp-login.php y no necesita una cuenta. Sin embargo, la cadena hacia ejecución de PHP no significa que cualquier visita anónima comprometa automáticamente el servidor: el ataque descrito necesita inducir a una persona administradora ya autenticada a abrir una URL preparada y aprovechar su sesión para completar acciones privilegiadas.

Juicio editorial: la prioridad no se limita a «hay un XSS». El riesgo combina una superficie universal —la pantalla de acceso— con una frontera humana concreta —el navegador de una persona administradora—. Por eso la actualización y la higiene de accesos privilegiados son dos trabajos relacionados, no intercambiables.

Qué rama debe ejecutar cada sitio

La documentación oficial de la versión indica qué backports contienen las correcciones. Solo la rama más reciente recibe soporte activo; las versiones antiguas se corrigen como cortesía y no deberían convertirse en una estrategia permanente.

Rama observada	Versión con correcciones	Decisión operativa
7.0	7.0.3	Actualizar y verificar inmediatamente.
6.9	6.9.6	Aplicar el backport y planificar la actualización a una rama activa.
6.8	6.8.7	Aplicar el backport; esta rama recibe 8 de las 12 correcciones.
6.7 a 6.0	Backport específico de cada rama	Usar la tabla oficial, no asumir que el último decimal es igual en todas.
5.9 a 4.7	Backport específico de cada rama	Corregir la urgencia y abrir una decisión de modernización separada.
4.6 o anterior	Sin backport de esta publicación	Tratar como excepción crítica: aislar, migrar o retirar con un plan explícito.

WordPress.org detalla todas las versiones, desde 6.9.6 hasta 4.7.34. La tabla anterior resume la decisión; no sustituye la referencia cuando una cartera conserva ramas heredadas.

Una secuencia de respuesta para agencias

1. Mide cobertura antes de celebrar el despliegue

Obtén la versión real de cada sitio después de la actualización. Separa al menos cinco estados: corregido y comprobado, actualización pendiente, actualización fallida, sitio inaccesible y versión desconocida. Los dos últimos no son «probablemente seguros»; son huecos de cobertura.

Si la agencia usa actualizaciones automáticas, conserva la hora de verificación y no solo la política esperada. Un sitio puede quedar fuera por permisos, despliegue gestionado, falta de espacio, configuración o inventario incompleto.

2. Prueba funciones críticas, no toda la web

Tras actualizar, comprueba acceso administrativo, edición y publicación, formularios, compra o reserva cuando existan, tareas programadas e integraciones críticas. La política de hardening de la cartera debería definir qué prueba corresponde a cada clase de sitio y cuándo detener el despliegue.

3. Reduce la exposición de las cuentas administradoras

Como la cadena de XSS2Shell descrita necesita una sesión administrativa y una interacción dirigida, revisa quién mantiene ese privilegio, elimina o rebaja cuentas que ya no lo necesiten, invalida sesiones antiguas cuando proceda y recuerda al equipo que no abra enlaces de administración recibidos fuera del flujo habitual. No presentes la concienciación como sustituto del parche: una persona prudente no corrige código vulnerable.

Los cuatro XSS almacenados incluidos en 7.0.3 requieren nivel Contributor o superior. En sitios con autores invitados, colaboradores externos o equipos editoriales amplios, conviene revisar también qué cuentas conservan capacidad de contribuir y si siguen activas.

4. Revisa condiciones especiales sin generalizarlas

• Multisite: una de las correcciones afecta redes con registro de usuarios habilitado y permite a un usuario crear un sitio que no debería poder crear. No aplica igual a una instalación individual.
• Contenido privado: hay correcciones por comentarios de entradas protegidas, notas en feeds y enumeración de slugs. Revisa los sitios donde esa información tenga sensibilidad real.
• Entornos internos o cloud: la corrección SSRF alcanza rangos link-local. El impacto depende de la red y de los servicios accesibles desde el servidor.

5. Investiga por evidencia, no por el titular

Durante esta revisión, CVE-2026-64638 no figuraba en el catálogo CISA KEV y no encontramos una fuente primaria que demostrara explotación activa generalizada. Eso no reduce la necesidad de actualizar; evita afirmar que todas las instalaciones sin parche ya fueron atacadas.

Si aparece una señal —cuenta administrativa inesperada, nueva contraseña de aplicación, página o plugin no autorizado, archivo PHP ajeno al despliegue o actividad administrativa anómala—, conserva evidencia y trata el sitio como incidente. En ausencia de indicadores, documenta qué registros y periodo se pudieron revisar. «No observamos señales en las fuentes disponibles» es distinto de «sabemos que no ocurrió nada».

Qué debe demostrar el cierre de cartera

Pregunta	Evidencia mínima	Señal de rechazo
¿Está corregido cada WordPress?	Versión observada tras el despliegue y hora de comprobación.	«Las actualizaciones automáticas están activadas».
¿Sigue funcionando?	Prueba crítica según el tipo de sitio.	Solo comprobar que la portada responde.
¿Quién puede administrar?	Lista reciente de cuentas, roles y sesiones relevantes.	Conservar accesos antiguos por comodidad.
¿Hay una señal que investigar?	Fuente, periodo, hallazgo y decisión documentados.	Declarar «limpio» sin registros suficientes.
¿Qué queda fuera?	Sitios inaccesibles, ramas heredadas y responsable con fecha.	Excluir los desconocidos del porcentaje.

Dónde encaja Vulnity y dónde no

Vulnity ayuda a centralizar señales, actividad sospechosa, hardening, bloqueos de IPs maliciosas cuando corresponda e informes entre varios WordPress. Esa capa operativa puede reducir los saltos entre paneles al comprobar cobertura, asignar excepciones y seguir señales después de una actualización.

La limitación es explícita: Vulnity no detecta CVE-2026-64638 ni otras CVEs, y no identifica plugins, temas o versiones de WordPress vulnerables. Tampoco sustituye la actualización oficial, un WAF, un escáner de malware, backups y restauración, la seguridad del hosting ni una investigación forense.

Conclusión

WordPress 7.0.3 merece prioridad, pero el trabajo de agencia no termina con una orden de actualización. Termina cuando cada sitio tiene una versión corregida comprobada, las funciones críticas siguen operativas, los privilegios administrativos están justificados y las excepciones desconocidas tienen responsable. El parche cierra el fallo; la evidencia cierra la cartera.