wp2shell: Cómo una sesión de IA de $ 25 afecta a millones de sitios de WordPress

Imagínese sentado relajado durante el café, teniendo su modelo de IA favorito abierto, arrojando $ 25 en crédito API y 10 horas más tarde sosteniendo una ejecución remota de código (RCE) no autenticada para el CMS más utilizado del mundo en sus manos. ¡Sí!

Esto es exactamente lo que Adam Kues (Analista de seguridad en Searchlight Cyber) está sucediendo. El resultado escucha el nombre suave wp2shell y es una cadena de explotación activamente explotada que actualmente recorre millones de instancias de WordPress. Security-Insider.de ya lo ha hecho Informado detalladamente el 27.7.

Si está ejecutando WordPress y no se ha actualizado desde mediados de julio, ahora El momento de guardar el café y abrir la terminal.

La institución está en llamas: ¿Qué es wp2shell?

En el caso de: wp2shell Esto no es solo un simple error, sino un Cadena de explotación Dos vulnerabilidades en el núcleo de WordPress. Juntos permiten ECA no autenticada, lo que significa que un atacante no necesita ninguna credencial o estado especial en su sitio. Una solicitud HTTP preparada es suficiente para ejecutar cualquier código PHP y hacerse cargo del servidor por completo.

Los atacantes no pierden el tiempo: Ya 13 minutos Después de la publicación de la Parches de seguridad de WordPress en 17.7 Las empresas de seguridad como Defiant registraron las primeras sondas de inyección SQL automatizadas en la red.

La anatomía de la hazaña: Lo que sucede bajo la capucha

Para aquellos que quieran saber más sobre cómo funciona el conejo: Aquí, la interacción de las dos vulnerabilidades se simplifica:

[ Solicitud de autenticación ] │ ▼ [ REST API Batch-Endpoint ] (CVE-2026-63030: │ ├─ Bypass von Auth / Routing-Restrictions ▼ [ WP _Query Engine ] (CVE-2026-60137: A través de 'author __not _in') │ ├─ Undjusted parámetro aprovecha la desinfección SQL de ▼ [ Remote Code Execution / Webshell ] │ └─ File in /wp-content/cache/ with random hash name

Encontrarás todos los detalles técnicos en las contribuciones de Searchlight Cyber y wizz.io

El abridor de puertas: REST API Enrutamiento por lotes (CVE-2026-63030)

• Puntuación CVSS: 9.8 (Crítico)
• Versiones afectadas: WP 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

WordPress proporciona la capacidad de agrupar múltiples solicitudes en una sola llamada a través de su punto final de lote de API REST. Hubo un error lógico en el Mapeo de rutas. Esto permitió a los atacantes enviar solicitudes a puntos finales internos / protegidos que normalmente requerirían autenticación.

El proveedor de carga útil: Inyección SQL en WP _Query (CVE-2026-60137)

• Puntuación CVSS: 5.9 (medios)
• Versiones afectadas: WP 6.8.x (< 6.8.6), 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

El clásico: El parámetro __not _in autor en la clase de consulta central WP _Query No se ha desinfectado adecuadamente. Si este parámetro se alimenta con entradas no filtradas (por ejemplo, activadas por un plugin o la brecha REST API mencionada anteriormente), se crea una inyección SQL clásica.

La combinación: El principio de los dos pasos

Investigador de seguridad Johannes B. Ullrich (Instituto SANS) ilustrado con un ejemplo, cómo funciona la ola de ataques en la práctica:

1. Muestra / reconocimiento: El atacante envía una primera carga útil a través de SQLi para verificar si la base de datos es escribible y si la brecha está funcionando.
2. Cuentagotas de Webshell: Una webshell de PHP se introduce en el sistema de archivos a través de SQLi, normalmente en el directorio /wp-contenido/caché/ bajo un nombre MD5/SHA generado aleatoriamente (p. ej. a8f3b...php).
3. Mecanismo de sigilo: El nombre del archivo también sirve como token de autenticación. Si descarga la webshell sin el parámetro de URL apropiado, congelará una URL falsa. HTTP 404 no encontrado de vuelta. ¡Inteligente!

Una vez que el shell está en su lugar, los bots cargan plugins maliciosos, lea el wp-config.php desde (¡Hola credenciales de base de datos!), crear nuevos usuarios administradores o insertar código malicioso a través de scripts CDN manipulados.

AI en el juego bug bounty: El Joker de $25

Un detalle picante en el borde: Adam Kues calificó su artículo de provocativo:

«Los corredores explotadores pagan 500 000 $ para un RCE de WordPress. Tengo uno con GPT-5.6 Sol Ultra y 25 $ encontrado.»

Utilizó el Modelo de Lenguaje Grande específicamente para el análisis de código estático y el tamizado a través de commits diff del núcleo de WordPress. Lo que solía ocupar equipos de investigadores de seguridad durante semanas, una IA especializada lo hace hoy en unas pocas horas para el cambio.

Para los administradores, esto significa: El tiempo para explotar se está reduciendo enormemente. El tiempo entre la liberación del parche y los escaneos masivos totalmente automatizados está ahora en el rango de minutos.

Primeros auxilios: ¿Está usted afectado & qué hacer?

Verificación rápida a través del sitio web: https://wp2shell.com/

Etapa 1: Actualización (¡AHORA!)

WordPress lanzó la versión parcheada el 17 de julio de 2026 7.0.2 (o backports) 6.9.5 y 6.8.6) publicado. Si la actualización automática no funcionó: Brinde inmediatamente manualmente.

Etapa 2: IoC-Check (Indicadores de Compromiso)

Si desea saber si alguien ya se ha establecido con usted, verifique su caso para las siguientes anomalías:

1. /wp-contenido/caché/ Examinar: Cuidado con los frescos .phpArchivos con nombres crípticos en la carpeta de caché. Por lo general, las carpetas de caché deberían ninguno Contiene código PHP ejecutable.
   
2. Comprobar usuarios administradores: Echa un vistazo a la lista de patrones de WordPress (/wp-admin/users.php?role=administrador) a cuentas desconocidas. A los atacantes les gusta crear administradores discretos.
   
3. Análisis de archivos de registro: Filtre los registros de su servidor web (Nginx/Apache) en busca de solicitudes sospechosas admin-ajax.php, Llamadas desde /wp-json/wp/v2/batch y acceso a archivos PHP en el caché/directorio.

Etapa 3: Herramientas útiles

• Lo antes mencionado Searchlight CyberComprobador wp2shell«: Proporciona una comprobación remota rápida para su dominio.
• Panel de control en vivo de Macnica (Yutaka Sejiyama): Realiza un seguimiento de la tasa de parches global. Actualmente hay ~81.6 % de los sistemas examinados. Pero esto también significa: Casi uno de cada cinco ¡La página todavía está abierta para atacar!

Conclusión & Consejo para la práctica

wp2shell Una vez más, muestra de manera impresionante hacia dónde se dirige el viaje en el sector de la ciberseguridad: Cuando los análisis impulsados por IA democratizan el descubrimiento de los días 0, los defensores también necesitan actualizarse.

3 reglas de oro para su servidor WP:

1. Protección del directorio Upload/Cache: En tu configuración de Nginx/Apache, incluye una regla que .php-archivos en /wp-content/subidas/ y /wp-contenido/caché/ Está estrictamente prohibido (Ubicación ~* /wp-content/(sube |cache)/.*\.php$ Negar todo; }).
   
2. Uso de Fail2Ban / WAF: Configure un firewall de aplicaciones web (por ejemplo, Cloudflare, Wordfence o ModSecurity) para interceptar patrones de inyección conocidos en el borde.
   
3. Verifique las copias de seguridad: Si tenía una carcasa en el sistema, "reparar" a menudo ya no es suficiente. A continuación: Restaurar el sistema desde una copia de seguridad limpia antes del 17 de julio y restaurar todas las claves en el wp-config.php ¡Gíralo!

Manténgase seguro & feliz parcheo! ¿Qué hay de ti? ¿Ya ha parcheado todas las instancias o ya ha descubierto accesos sospechosos en el registro? ¡Entonces vámonos!