Dos veces este año, los atacantes comenzaron a explotar una falla crítica del núcleo WordPress pocas horas después de que la solución se hiciera pública: las fallas de shell wp2 en julio y CVE-2026-87902 el 22 de septiembre, el día WordPress 7.1.2 enviado. Si sus sitios esperan una ventana de mantenimiento mensual, su política de parches es lo primero que debe cambiar.
¿Qué pasó con wp2shell en julio?
Dos fallas, rastreadas como CVE-2026-60137 (inyección SQL) y CVE-2026-63030 (ejecución de código arbitrario), se pueden encadenar para ejecutar código en un servidor WordPress sin iniciar sesión. Searchlight Cyber informó que afectan WordPress 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1, incluso en una instalación estándar sin complementos. WordPress publicó correcciones en las versiones 6.9.5 y 7.0.2.
Las empresas de seguridad informaron de los primeros ataques pocas horas después de la divulgación, y poco después aparecieron exploits de prueba de concepto de otros investigadores. Automattic le dijo a TechCrunch que WordPress.com, Pressable, WPVIP y WP.cloud estaban protegidos antes de que los parches fueran públicos, por lo que los sitios autohospedados que no se actualizaban automáticamente presentaban el mayor riesgo.
Lo que pasó de nuevo en septiembre 22
El 22 de septiembre, WordPress envió la versión 7.1.2 con una solución para CVE-2026-87902, una falla crítica en la forma en que el núcleo resuelve las plantillas de página. Los informes que citan el anuncio de WordPress.org lo califican como 9.2 en CVSS 4.0 y dicen que afecta las versiones del 4.7.0 al 7.1.1 a menos que se haya aplicado un backport de seguridad. WordPress también respaldó la solución a ramas más antiguas, incluidas 7.0.6 y 6.9.9.
Patchstack registró el primer intento de explotación a las 11:49 UTC del mismo día, según los informes. Nuestro 7.1.2 lista de verificación de actualizaciones de seguridad cubre qué verificar en un sitio.
Qué cambia la IA y qué no está demostrado
Benjamin Harris de WatchTower, citado por Techzine después de wp2shell, dijo que el código de prueba de concepto solía aparecer aproximadamente un día después de una divulgación y ahora aparece en cuestión de horas, en parte porque las herramientas impulsadas por IA ayudan a los investigadores y atacantes a analizar y automatizar más rápido.
Los vendedores de modelos se están moviendo en la misma dirección. Google dice que su nuevo Gemini 4 Argon puede encontrar, validar y parchar de forma autónoma vulnerabilidades críticas de software, y está brindando acceso temprano a los ciberdefensores confiables primero. OpenAI enumera modelos separados centrados en lo cibernético en su página de precios.
Nada de esto prueba que la IA haya causado un ataque en particular. El punto práctico es más limitado: planificar menos tiempo entre un aviso público y la explotación.
Una política de parches que puedes adoptar
Estos objetivos son un punto de partida, no un estándar. Ajústelos a su riesgo y a la rapidez con la que pueda realizar las pruebas.
Pon estas ideas en práctica.
Desde una mejora puntual hasta una web completa, te ayudamos a definir el alcance y llevarlo a cabo.
Hablemos de mi webSoluciones avanzadas de seguridad de WordPressCuéntanos tus objetivos. Solemos responder en menos de 4 horas con preguntas y próximos pasos prácticos.
Cinco pasos para implementarlo
- Sepa lo que ejecuta. Enumere las versiones principales, de complementos y de temas para cada sitio. Con WP-CLI:
Versión de wp core Actualización de verificación de wp core Lista de complementos de wp --update=disponible lista de temas de wp --update=disponible- Mire las fuentes correctas. Siga las noticias de WordPress.org y los avisos de seguridad de su anfitrión, y asigne a una persona para que los lea diariamente.
- Utilice la puesta en escena, pero limite el tiempo. Pruebe la actualización crítica en una copia, verifique los recorridos clave y luego implemente. Si las pruebas se detienen, parchee la producción y pruebe después.
- Cubra el espacio con una capa protectora. Un firewall de aplicaciones web puede bloquear patrones de explotación conocidos antes de que termine de parchear. Cloudflare activó reglas de detección adicionales para wp2shell, según Techzine. Un firewall reduce el riesgo. No reemplaza la actualización.
- Verificar y registrar. Tenga en cuenta la versión instalada, quién comprobó qué y qué sigue abierto.
Nuestro guía de clasificación de parches de seguridad Cubre el orden de decisión con más detalle.
Si estuvieras atrasado en un parche crítico
Trate un sitio que ejecutó una versión afectada sin actualizar como posiblemente comprometido. Busque nuevas cuentas de administrador, archivos principales modificados y archivos PHP desconocidos:
lista de usuarios de wp --role=administrador sumas de verificación de verificación del núcleo de wpSi algo parece estar mal, deja de hacer cambios y busca ayuda. Nuestro servicio de recuperación de emergencia para sitios hackeados puede ayudarle a contener el problema y solucionarlo.
Preguntas frecuentes
¿Qué tan rápido debo parchear una vulnerabilidad crítica WordPress?
Apunte a 24 horas y no más de 72. Realice una clasificación en cuestión de horas y luego actualice la producción una vez que los recorridos clave pasen una prueba rápida.
¿Las actualizaciones automáticas hacen innecesaria una política de parches?
No. Las actualizaciones automáticas ayudan, pero no todos los sitios las tienen habilitadas y los complementos y temas a menudo se actualizan por separado. Una política le indica quién verifica, con qué rapidez y qué sucede cuando falla una actualización.
¿La IA hace que WordPress sea menos seguro?
Nada en las fuentes que revisamos muestra que WordPress se debilite. Lo que describen las fuentes es la rapidez con la que se analizan y explotan las fallas después de su divulgación.
¿No está seguro de que sus sitios estén cubiertos?
corremos mantenimiento de WordPress y seguridad trabajo que incluye seguimiento de parches, pruebas de preparación y monitoreo. Envíanos tu lista de sitios y te diremos dónde están los huecos.
