Resumen de la publicación
La semana pasada se publicó wp2shell (CVE-2026-63030 + CVE-2026-60137), una cadena de ejecución remota de código sin autenticación en el core de WordPress, con explotación activa confirmada y entrada al catálogo KEV de CISA. Como administro varios sitios WordPress (entre ellos el del MUG), esta vez la noticia no fue «otro CVE más»: fue personal.
Si administrás uno o varios WordPress, acá te cuento el checklist que apliqué de verdad después de la ventana de exposición, y por qué creo que el ciclo «instalá y olvidate» que domina este ecosistema es incompatible con administrar el CMS que corre el 40% de la web.
El 17 de julio me desayuné con el aviso de seguridad de WordPress y, mientras leía, sentí algo distinto a lo habitual. No era el enésimo plugin trucho con un agujero: era el core.
Yo administro varios sitios WordPress, entre ellos el del MUG, que es público y conocido. Así que esta vez la vulnerabilidad no me tocó la puerta en sentido figurado: me la tocó literal, porque los escaneos masivos arrancaron a las pocas horas del disclosure.
Qué es wp2shell, en dos minutos
La cadena se llama wp2shell y son dos vulnerabilidades encadenadas, como conté en detalle en la noticia que publicamos en el MUG. Ninguna de las dos alcanza sola, pero juntas son letales.
La primera (CVE-2026-63030) es un bug de confusión de rutas en el procesador batch de la REST API (/wp-json/batch/v1), introducido en WordPress 6.9: un fallo lógico que desincroniza los arrays de validación. La segunda (CVE-2026-60137) es una inyección SQL en el parámetro author__not_in de WP_Query.
Encadenadas, según el análisis de Rapid7, permiten a un atacante sin usuario ni contraseña crearse una cuenta de administrador, subir un plugin malicioso y ejecutar código en el servidor. De ahí el nombre: de WordPress a shell, sin escalas.
El alcance completo de la cadena afecta a WordPress 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1 (la rama 6.8 solo carga con la inyección SQL). Los parches salieron el mismo 17 de julio en las versiones 6.9.5, 7.0.2 y 6.8.6, según el anuncio oficial de WordPress.org.
Y acá el dato que a mí me define la gravedad mejor que cualquier CVSS: la explotación in-the-wild empezó a los pocos días y el 21 de julio CISA metió ambos CVEs en su catálogo KEV de vulnerabilidades explotadas activamente. Cuatro días entre parche y KEV. Esa es la ventana que tuvimos todos.
Cuando la falla no está en el plugin trucho sino en casa
Los que administramos WordPress hace años desarrollamos un reflejo mental: cuando sale una vulnerabilidad, lo primero que pensamos es «¿qué plugin fue esta vez?». Y casi siempre acertamos, porque el 95% de los problemas de seguridad de este ecosistema viven en plugins y themes de terceros.
Ese reflejo trae una tranquilidad implícita: «yo tengo pocos plugins, y de autores serios, así que estoy razonablemente bien». wp2shell me voló esa tranquilidad de un plumazo.
Porque acá no hay plugin que desinstalar ni autor dudoso al que culpar. El bug estaba en la REST API del core, esa que viene activada por defecto en cada instalación del planeta.
Lo que se siente, siendo honesto, es una mezcla de vértigo y humildad. Vértigo porque tu superficie de ataque ya no depende de tus decisiones de curaduría (podés tener el sitio más minimalista del mundo e igual estar expuesto). Y humildad porque te recuerda que el software que no escribiste vos siempre puede fallar, incluso el que mantiene una comunidad enorme desde hace más de veinte años.
El checklist que apliqué de verdad (no el de los papers)
No voy a dar detalles de configuración de los sitios que administro (regla básica: no publicar el plano de tu propia casa). Pero sí puedo contar, en general, qué hice y qué hago siempre, porque es un checklist corto y aplicable por cualquiera.
- Auto-updates del core, activados siempre. WordPress.org además forzó actualizaciones automáticas para las versiones afectadas, y esa decisión (polémica para algunos puristas) esta semana salvó a miles de sitios cuyos dueños ni se enteraron del problema. Yo no dependo de leer la noticia a tiempo: el core se actualiza solo.
- Revisar cuentas de administrador después de la ventana de exposición. Parchear no alcanza si te comprometieron antes del parche. La cadena de wp2shell crea admins nuevos, así que lo primero fue auditar la lista de usuarios con privilegios: cualquier cuenta que no reconozco es una bandera roja.
- Revisar plugins y archivos que no puse yo. El paso final del exploit es subir un plugin malicioso. Un vistazo a la lista de plugins instalados y a archivos PHP recientes fuera de lugar te dice bastante rápido si tuviste visitas.
- Backups probados, no backups «configurados». Un backup que nunca restauraste es una expresión de deseo. Si mañana descubro un compromiso, mi plan no es «limpiar» el sitio infectado (eso casi nunca termina bien): es restaurar a un punto anterior conocido y sano.
- Principio de mínima superficie: menos plugins es más seguridad. Cada plugin es código de un tercero corriendo con los permisos de tu sitio. Antes de instalar algo nuevo me pregunto si de verdad lo necesito, y una vez por trimestre repaso la lista buscando qué puedo borrar.
Nada de esto es sofisticado. Y ese es exactamente el punto: la diferencia entre un sitio comprometido y uno sano esta semana no fue tener un WAF carísimo, fue tener los deberes básicos hechos antes del incidente.
«Instalá y olvidate»: el ciclo que nos trajo hasta acá
Ahora, la reflexión de fondo. WordPress corre alrededor del 40% de la web: medios, tiendas, gobiernos, ONGs, comunidades como la nuestra. Con esa escala, es infraestructura crítica de facto.
Pero la cultura dominante alrededor de WordPress sigue siendo la del hobby: lo instala alguien un fin de semana, le carga quince plugins, lo deja andando y no lo vuelve a mirar hasta que se rompe. Vengo viendo ese patrón hace años en pymes, en instituciones educativas y hasta en empresas que facturan en serio.
El problema no es la herramienta: es la asimetría entre lo que WordPress representa y cómo lo tratamos. A un servidor de base de datos nadie se le ocurre dejarlo sin parches dos años; al WordPress corporativo, sí, porque «es solo la web».
wp2shell es el recordatorio de que «solo la web» es, muchas veces, la cara pública de tu organización, tu canal de ventas o tu base de datos de usuarios. Y de que los atacantes automatizaron el ciclo completo: sale el advisory, a las horas hay escaneos masivos, a los días hay PoC público y entrada en el KEV.
Contra ese nivel de industrialización del ataque, el modelo «instalá y olvidate» no tiene ninguna chance. La única respuesta razonable es tratar cada WordPress como lo que es: un sistema en producción, con dueño, con parches automáticos, con backups probados y con alguien que lo mira.
Desde mi punto de vista, esto también es una conversación de gestión, no solo técnica. Si tu organización tiene un WordPress y nadie puede responder «¿quién es el responsable de mantenerlo actualizado?», el problema no es el CVE de turno: es que el rol no existe.
¿Quién mira tu WordPress cuando vos no lo mirás?
Esta semana me tocó ser el que corre a verificar versiones, auditar admins y confirmar backups un jueves a la mañana. No fue divertido, pero fue corto, justamente porque los deberes estaban hechos de antes.
Te dejo la pregunta que me hice yo: de todos los WordPress que tenés a cargo (o que tu empresa tiene y nadie reclama), ¿cuántos tienen auto-updates activados, backups que probaste restaurar y una lista de plugins que podrías justificar uno por uno? Si la respuesta te incomoda, esta semana es un excelente momento para arreglarlo. Te leo en los comentarios.
