Viernes, seis menos cuarto de la tarde

WordPress publicó una versión de seguridad el 17 de julio de 2026 que cubría dos vulnerabilidades del núcleo. El equipo de investigación de Searchlight Cyber, que descubrió la más grave de las dos, le puso el nombre wp2shell. Los identificadores asignados son CVE-2026-63030, una confusión de rutas en el endpoint de lotes de la API REST combinada con inyección SQL, y CVE-2026-60137, una inyección SQL alcanzable a través del parámetro author__not_in de WP_Query.

A las 17:45, hora del Este, el mismo día del parche, Rapid7 publicó su análisis y dejó constancia de dos cosas. Los detalles técnicos del exploit todavía no se habían publicado y no le constaba explotación confirmada públicamente. Si usted leyó esa valoración el viernes, tenía todos los motivos para pensar que disponía de una semana laboral normal para programar la actualización.

No la tenía. PatchStack empezó a informar de explotación de ambos CVE poco antes de las 19:00, hora del Este, esa misma tarde, alrededor de una hora después de la foto fija de Rapid7. Para el domingo 19 de julio, VulnCheck había verificado más de dos docenas de exploits de prueba de concepto distintos dirigidos contra el fallo.

Dos fallos, y su versión tiene dos respuestas distintas

Casi toda la cobertura trata esto como un único suceso con un único nombre. Son dos vulnerabilidades con alcance distinto, y esa diferencia decide lo que usted tiene que hacer de verdad. Equivocarse en cualquiera de los dos sentidos le cuesta un fin de semana o le deja un agujero abierto.

CVE-2026-63030, la cadena de ejecución remota de código, afecta a WordPress de la 6.9.0 a la 6.9.4 y de la 7.0.0 a la 7.0.1. Está corregida en la 6.9.5 y la 7.0.2, y en la línea beta 7.1 desde la Beta 2. CVE-2026-60137, la inyección SQL de WP_Query, llega más atrás. Afecta de la 6.8.0 a la 6.8.5 además de los mismos rangos 6.9 y 7.0, y la corrección para la rama antigua es la 6.8.6.

La consecuencia práctica es que un sitio que sigue en 6.8.x lee los titulares sobre wp2shell, comprueba si está en el rango 6.9 o 7.0, concluye que no le afecta y ahí se detiene. Ese sitio no está expuesto a la cadena completa de ejecución de código sin autenticar, pero sí lo está a la inyección SQL, y aun así tiene que pasar a la 6.8.6. Las comprobaciones de versión hechas contra el CVE equivocado son la vía más probable por la que una organización se equivoque esta semana.

La red de seguridad cubre los sitios que menos importan

Los mantenedores de WordPress respondieron forzando la actualización en las instalaciones afectadas que tenían activadas las actualizaciones automáticas. Es la decisión acertada y habrá protegido a un número muy grande de sitios durante el fin de semana sin que nadie tuviera que tocarlos.

Fíjese en qué sitios no protegió. Las actualizaciones automáticas se desactivan a propósito, y los motivos son siempre los mismos: un proceso de control de cambios, un plugin que se rompió con una versión menor anterior, una cadena de preproducción a producción, un contrato de agencia que asigna la responsabilidad de actualizar a una persona, un régimen de cumplimiento que prohíbe cambios sin revisar en producción. Cada uno de esos motivos delata una instalación que alguien considera lo bastante importante como para gestionarla.

Así que la red de seguridad automática guarda una correlación inversa con la criticidad para el negocio. El blog de aficionado se actualizó solo el viernes por la noche. El portal de clientes, el sistema de reservas y el sitio que cobra los pagos se quedaron en la versión vulnerable durante un fin de semana en el que el código de ataque funcional pasó de no existir a superar las dos docenas. Si su organización desactivó las actualizaciones automáticas como medida de madurez, este es el fin de semana en el que esa decisión le pasó factura.

Qué mide en realidad la curva del fin de semana

El número útil aquí no es una puntuación CVSS, y además los proveedores no coinciden del todo sobre la gravedad. Rapid7 registra CVSS 7.5 para la cadena de ejecución remota mientras que el aviso correspondiente la considera crítica, y VulnCheck sitúa la inyección SQL como la crítica de la pareja. Discutir qué cifra poner en el ticket es un mal uso del tiempo que le queda.

La cifra que importa es el intervalo entre el parche y la conversión en arma. Aquí se midió en horas para los primeros informes de explotación y en unos dos días para la disponibilidad pública amplia de exploits. Ese es el nivel de servicio real que su proceso de parcheo tiene que cumplir, y la política declarada de casi ninguna organización lo cumple. Una ventana de subsanación de treinta días, habitual en los marcos de cumplimiento, no es una política de parcheo para un fallo como este. Es la descripción de cuánto tiempo estuvo usted expuesto.

Hay un segundo detalle en los exploits posteriores que cierra la salida de emergencia habitual. VulnCheck informa de que, para el domingo, habían aparecido implementaciones adicionales de ejecución remota de código que eluden por completo la autenticación de administrador. Los equipos que pensaban apoyarse en cuentas de administrador blindadas, páginas de acceso restringidas o doble factor en wp-admin como control compensatorio deberían entender que esas medidas no están en la ruta de este ataque.

Cuatro cosas que conviene hacer hoy

Primero, inventarie antes de parchear. Localice todas las instalaciones de WordPress que su organización posee realmente, incluidos los micrositios de marketing, las páginas de aterrizaje de campañas, el sitio del congreso de hace dos años y cualquier cosa que construyera una agencia que ya se fue. La instalación vulnerable casi nunca es la que figura en el inventario de activos. Es aquella de la que nadie recordaba que seguía sirviendo tráfico.

Segundo, compruebe cada una contra el CVE que le corresponde. Todo lo que esté en 6.8.x pasa a la 6.8.6. Todo lo que esté en 6.9.x pasa a la 6.9.5. Todo lo que esté en 7.0.x pasa a la 7.0.2. No deje que una única suposición sobre el rango de versiones cubra todo el parque.

Tercero, trate cualquier instalación sin parchear que estuviera expuesta a internet durante el fin de semana como potencialmente comprometida y no como simplemente vulnerable, y busque las evidencias en lugar de dar por supuesta su ausencia. Parchear cierra la puerta. No echa a quien ya esté dentro. Cuarto, y este es el que dura, anote cuál fue el tiempo real hasta el parche de su organización en este caso y compárelo con la cifra que publica en su política. La distancia entre esas dos cifras es lo que hay que arreglar, porque la próxima vulnerabilidad del núcleo correrá con el mismo reloj.

Leer a continuación: El parche de nginx ya está, el exploit llega en agosto  |  ServiceNow parcheó su nube primero y a usted 103 días más tarde