🌐 También en: English · Deutsch · Français
Hace unos días, “wp2shell” corrió como la pólvora: una cadena RCE sin autenticación en WordPress, apañada a partir de una inyección SQL (CVE-2026-60137) y un bypass de validación en el endpoint REST
batch (CVE-2026-63030). 🩸 Todo WordPress ≥6.8 estaba expuesto, y
upstream por fin lo arregló en 7.0.2. Durante un par de días de
morderse las uñas, este mismo blog funcionó con un bloqueo de emergencia en
nginx sobre /wp-json/batch/v1, porque la imagen Docker parcheada
simplemente se negaba a existir todavía. Un clásico. 🙃 Así que, como es lógico, una vez apagado el incendio hice lo que cualquier nerd
del homelab con un mínimo de amor propio hace a las 2 de la madrugada: me fui
de espeleología por mis propios logs de ingress. 🕵️♂️ Resulta que a internet
le da igual que hayas parcheado. Internet sigue llamando a la puerta.🔍 Las pruebas del log de acceso
En la primera pasada por los logs, creía tener un puñadito ordenado de peticiones. Luego volví con un grep mejor (resulta que las líneas simples del log de acceso de nginx no repiten el nombre de host, así que mi primer filtro por dominio se estaba comiendo en silencio peticiones reales; hasta los nerds del homelab tenemos días malos 🤦) y descubrí que era mucho más que un puñado.- 🌊 La avalancha inicial, 18–19 de julio: el día en que
salió la CVE, mis logs se iluminaron con docenas de peticiones, casi todas del
mismo User-Agent maravillosamente poco sutil,
wp2shell.com scanner, que rotaba por un pequeño ejército de IP detrás de Cloudflare y casi siempre obtenía un 207 (procesado, antes de la mitigación). Básicamente, los investigadores de seguridad de internet (o “investigadores” 🧐) dando una vuelta de honor sincronizada en el momento en que la vulnerabilidad se hizo pública. - 😂 Bis del mismo UA de escáner el 20 de julio: 403, bloqueado por mi regla de emergencia. 💪 Y otra vez el 21 de julio, con la regla desactivada justo un momento: 207, pasó como si nada. 🎯 (La CVE de fondo ya estaba parcheada para entonces, así que… un chasco para ambos.)
- 🕵️ Mi favorito personal: una máquina EC2 en AWS
Tokio (
ec2-*.ap-northeast-1.compute.amazonaws.com, sí, hice la búsqueda de DNS inverso, sí, me sentí muy listo) que llevaba un User-Agent de Chrome falso como un disfraz barato de Halloween. 🎭 Pidió/, esperó exactamente un (1) segundo y luego fue directa al endpoint del exploit. Nada de CSS. Nada de JS. Nada de favicon. Ningún ser humano navega así: un Chrome de verdad carga recursos equivalentes a una novela corta por cada página vista. Buen intento, robot. 🤖 - 🆕 Actualización mientras aún escribía este artículo: llegó uno nuevo desde Google Cloud (
*.bc.googleusercontent.com), dos peticiones, con un segundo de diferencia, ambas 207, y este hasta se molestó en etiquetarse con su propio parámetro de seguimiento,&_w2s=347b2f52/&_w2s=b58fad1b. Por lo visto, la herramienta de escaneo de alguien ya numera sus propios intentos. ¡Eficiencia! 📊 Tercer gran proveedor de nube detectado hasta ahora (detrás de Cloudflare, AWS y ahora GCP): este bicho tiene amigos en todas partes.
🤔 Vale, pero ¿quién está haciendo esto en realidad?
Buena pregunta, y merece la pena explicarlo para quien no se pasa el rato mirando logs de servidor por diversión: no todo el que toquetea una vulnerabilidad conocida es un delincuente. Aquí hay un espectro real, y las pistas importan. 🔬- 😇 El extremo de buena fe: empresas de investigación en
seguridad y servicios de escaneo (piensa en Shodan, Censys, proyectos al estilo
de GreyNoise) barren internet constantemente en busca de CVE conocidas, a
veces para alimentar feeds públicos de threat intelligence, a veces para que
los dueños de sitios afectados puedan buscar su propio sitio y decir “ay, no”. Una
herramienta que en su propio User-Agent se llama literalmente
wp2shell.com scannerencaja bien en este perfil: no tiene motivos para esconderse, y decir bien alto quién eres es justo lo que hacen los escáneres legítimos (y a menudo lo que esperan las normas de divulgación responsable). - 😈 El extremo de mala fe: atacantes que lanzan exactamente el mismo tipo de comprobación, solo que el objetivo no es “avisar a alguien”, sino “encontrar una puerta por la que todavía pueda colarme”, para dejar una webshell, un inyector de spam, un criptominero o simplemente añadir la máquina a una botnet. Estos son los que tienen todos los incentivos para pasar desapercibidos.
curl, las que lancé para confirmar que el bloqueo
funcionaba de verdad, están en ese mismo archivo de log, varias veces, porque
al parecer no era capaz de comprobarlo solo una vez. 😅 Así que, técnicamente,
yo también soy “una dirección IP sondeando el endpoint vulnerable”. Culpable de
todos los cargos, señoría. 👨⚖️ Y no es solo paranoia mía, por cierto: Golem.de también cubrió exactamente esta
oleada de intentos de explotación en curso: “Lücken in WordPress: Laufende Schadcode-Attacken gefährden Millionen von Websites”,
así que no es ninguna teoría conspirativa aislada de un blog de homelab. 📰
Es un fenómeno que afecta de verdad a todo internet.🕸️ Ronda extra: los scrapers con gabardina
Mientras estaba en el fondo de la mina de logs buscando wp2shell, tropecé con algo mucho más grande y, sinceramente, más interesante: 765 direcciones IP distintas, repartidas en al menos 530 bloques de red /16 diferentes (o sea: por todas partes, no un solo centro de datos), cada una apareciendo para hacer exactamente una o dos peticiones y luego desaparecer para siempre. 👻 Todas y cada una presentaban un UA de navegador de escritorio de aspecto perfectamente normal: Chrome o Edge, Windows o Mac, el lote completo. Nada que te llamara la atención a simple vista. Pero ponlas todas en fila y la máscara se cae al instante: solo visitaban mis ~31 páginas de archivo por etiqueta, categoría y fecha (/tag/ansible, /category/devsecops, /2025/05, etc.), recorriendo la
lista de forma metódica, y ni una sola descargó después un solo archivo CSS,
archivo JS o imagen. 🖼️🚫 Una pestaña de Chrome de verdad carga un par de
docenas de recursos por página vista sin que muevas un dedo. Estas no cargaron
ninguno. Esa es la firma de una botnet de scraping con proxies
residenciales: en lugar de machacar el sitio desde una sola IP (con lo
que te limitan o te banean en unos cuatro segundos), alquilas unos cuantos
cientos de miles de IP residenciales reales y lanzas desde cada una exactamente
una petición educada de “soy-una-persona-de-verdad-lo-juro”. Muerte por mil
cortes de papel, salvo que los cortes son indistinguibles de lectores reales a
menos que te alejes lo suficiente para ver el patrón. 🔎 Dado el objetivo
(recorrer sistemáticamente cada página de archivo, es decir, el índice completo
de contenido del sitio, no solo la portada), apuesto por scraping de contenido
a gran escala: puede ser el clásico robo de contenido para SEO o alguien
montando un conjunto de datos de entrenamiento para IA. En cualquier caso: 765
“visitantes” que leyeron cero palabras y cargaron cero fuentes nunca fueron
visitantes. 🤖🕶️🎬 Conclusión
El agujero en sí lleva un tiempo tapado (aquí funciona7.0.2 desde
el primer día en que fue posible). Pero el escaneo de una CVE recién anunciada
no se detiene solo porque alguien, en algún lugar, haya publicado un parche. 📡
Los bots de escaneo no leen changelogs. Si tienes un WordPress expuesto al
público, este tipo de tráfico es simplemente ruido de fondo: una buena excusa
para echar un vistazo de verdad a tus logs de acceso de vez en cuando, en lugar
de dar por hecho que “parcheado == terminado”. 🛡️
