wp2shell no vino de un plugin. Vino de WordPress mismo.

El 17 de julio de 2026, WordPress publicó versiones de emergencia para dos vulnerabilidades encadenadas que los investigadores de seguridad bautizaron wp2shell. Juntas permiten que un atacante sin cuenta, sin contraseña y sin ninguna interacción del usuario ejecute su propio código en un sitio WordPress. En cuestión de días ya circulaba código de explotación público, y varias firmas de seguridad reportaban ataques reales.

Las vulnerabilidades graves en WordPress no son noticia — se catalogan miles cada año. Esta es distinta por una razón que merece más atención que los números de CVE: no vino de un plugin.

Qué pasó realmente

Dos fallas en el núcleo de WordPress, encadenadas. La primera, CVE-2026-63030, es un error de ruteo en el endpoint de lotes de la API REST: cuando una petición del lote falla al procesarse, la contabilidad interna se desalinea y una petición posterior termina atendida con la verificación de permisos equivocada. La segunda, CVE-2026-60137, es una inyección SQL alcanzable por un parámetro de consulta que solo limpiaba su entrada cuando esta llegaba en una forma particular.

Por separado, cada una es un bug. Encadenadas, llevan una petición anónima desde la puerta de entrada hasta la ejecución de código — saltándose la verificación de permisos, envenenando lo que el sitio cree sobre sí mismo, y terminando con una cuenta de administrador que el atacante controla. De ahí basta subir un plugin y el sitio es suyo.

Las versiones afectadas fueron WordPress 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1, con la inyección SQL alcanzando también la rama 6.8.x. Las correcciones son 6.8.6, 6.9.5 y 7.0.2. Si usas WordPress y hoy no has confirmado tu versión, deja de leer y ve a hacerlo — este texto seguirá aquí.

Por qué esta vez es distinto de cualquier otro aviso de WordPress

Durante años, la defensa estándar de la seguridad de WordPress ha sido razonable, y nosotros mismos hemos hecho una versión de ella: el núcleo lo mantiene gente seria, y el peligro vive en el ecosistema de plugins. Usa menos plugins. Elige los bien mantenidos. Parcha rápido. Haz eso, dice el argumento, y estarás bien.

wp2shell elimina ese argumento. Una instalación nueva de WordPress, sin plugins, sin personalización de tema y sin nada raro configurado, era explotable. El endpoint de lotes de la API REST viene activo por defecto. No hubo mala configuración a la cual culpar ni autor externo al cual señalar. Un dueño diligente que había seguido cada consejo estándar estaba exactamente igual de expuesto que uno descuidado.

Esa es la parte que vale la pena asimilar. La mitigación que todos recomiendan — reduce tu dependencia del código de otros — no sirvió de nada aquí, porque la dependencia que falló era WordPress.

La letra chica de “solo actualiza”

La respuesta de WordPress fue rápida y genuinamente buena. Salieron parches para tres ramas a la vez, y las actualizaciones automáticas se forzaron en las instalaciones que las tenían activadas. Crédito donde corresponde.

Pero “solo activa las actualizaciones automáticas” asume en silencio un sitio donde dejarlas encendidas es seguro. En un sitio de negocio real con un page builder, un plugin de formularios, una integración de reservas y un tema hijo, las actualizaciones del núcleo sin supervisión son justo lo que a los dueños les han enseñado a temer, porque una actualización que rompe el sitio a las 2 de la mañana es su propio tipo de caída. Así que muchísimos sitios autogestionados tienen ese interruptor apagado a propósito — y esos son los sitios que siguen expuestos ahora mismo, con código de explotación circulando en público.

Esa es la trampa. La complejidad de la plataforma es lo que lleva a los dueños a desactivar el mecanismo de seguridad, y desactivar el mecanismo de seguridad es lo que los deja vulnerables a las fallas de la plataforma. No puedes parchar tu salida de un problema estructural.

Este es el patrón, no la excepción

Ya hemos escrito sobre cómo la deuda de seguridad de un CMS se acumula y por qué apuntar la IA a WordPress para rescatarlo es la apuesta equivocada. wp2shell es cómo se ven esos argumentos cuando finalmente llegan.

El problema de fondo es la superficie de ataque. WordPress carga dos décadas de retrocompatibilidad, una API REST que debe atender a cada plugin jamás escrito, una capa de base de datos que debe aceptar cada forma de consulta que alguien alguna vez usó, y un modelo de permisos entretejido en todo ello. Cada uno de esos compromisos es una promesa de mantener funcionando código viejo, y cada promesa es un lugar donde una suposición puede dejar de ser cierta en silencio. Esa es exactamente la forma de ambos bugs de esta cadena.

Nadie fue descuidado. Esto es lo que le pasa a cualquier base de código a la que se le pide ser infinitamente extensible y permanentemente retrocompatible durante veinte años. Es una propiedad de la arquitectura, y la próxima vendrá del mismo lugar.

Es hora de dejar WordPress atrás

La pregunta honesta no es si WordPress puede asegurarse — con un equipo competente, un entorno de pruebas, monitoreo y un proceso real de parches, sí puede. La pregunta es si eso es algo razonable de pedirle a un negocio cuyo trabajo real es otra cosa por completo.

No lo es. La mayoría de los dueños no se apuntó a seguir anuncios de CVE, evaluar si una versión de emergencia del núcleo romperá su formulario de reservas, o enterarse por un cliente de que su página de inicio está sirviendo spam. Querían un sitio web. La carga de mantenimiento nunca fue parte del trato — se heredó de una decisión de plataforma tomada hace años, muchas veces por otra persona.

Un sitio pequeño y hecho a propósito no tiene nada de esto. No hay una superficie de API REST expuesta a internet para que un endpoint de lotes se confunda. No hay una capa de base de datos de plugins aceptando formas arbitrarias de consulta. No hay un login de administrador al cual escalar. La superficie de ataque no es menor por grado — en su mayoría simplemente no existe, porque el sitio no la necesita para mostrarle a tus clientes quién eres y dejar que te contacten.

Dónde entra SWATS

SWATS no construye sobre WordPress. Cada sitio que construimos es una propiedad limpia, rápida y hecha a propósito, sin lotería de plugins, sin ruleta de temas y sin fines de semana de parches de emergencia — y después un agente lo opera por ti. Cuando aparece algo como wp2shell, no hay nada que nuestros clientes tengan que revisar, porque no hay panel de control, ni versión del núcleo, ni superficie de administración expuesta que revisar.

Y la parte de operarlo es justo el punto de SWATS: nos cuentas de tu negocio una vez, nosotros construimos el sitio, y después actualizarlo es tan simple como enviar un correo. La parte que amas es la única parte que haces.

¿Quieres saber dónde está realmente tu sitio? Corre el SWATS Scorecard gratis y descubre si eres visible — o invisible — para la búsqueda con IA.

Este es el camino. 🤖

— Jenaro Diaz, Founder & CEO, SWATS AI