¡La ciberseguridad está de lo más caliente, mi gente! Se ha puesto en evidencia una ‘vaina’ que ha dejado a más de uno con los pelos de punta en el mundo de la tecnología. Y es que unas ‘Vulnerabilidades PHP’ críticas, agrupadas bajo el nombre de PHP2Shell, acaban de hacerse públicas. Lo más extraño, y lo que tiene a todo el mundo con el ‘klk’, es que alguien ya estaba intentando sacarles provecho cuatro días antes de que la información se hiciera del dominio público, según el reporte de Amazon Threat Intelligence.
Asegún Amazon, su red de honeypots MadPot —sistemas señuelo diseñados para atraer ataques— registró un intento de explotación el 17 de octubre. Esto fue ‘cuatro días antes del coro’ de la divulgación pública y la liberación de los parches el 21. La actividad, que procedía de una IP ligada a una red comercial de anonimización, apunta clarito a un actor malicioso, pero la gran incógnita es: ¿cómo rayos obtuvieron esa información tan, tan exclusiva antes de que se soltara el bombazo? Es una pregunta que tiene a los expertos rascándose la cabeza, buscando dónde se ‘fue la luz’.
Para entender este enredo, hay que echar para atrás hasta agosto. El 11 de ese mes, Calif le notificó al equipo de PHP una vía de ejecución remota de código, un chismecito que los mantenedores ya habían visto en 2024. Curiosamente, OpenAI llegó de manera independiente a la misma conclusión. Después, Wiz comenzó su propia investigación el 19 de agosto y comunicó sus hallazgos al equipo de PHP el 24. La inteligencia artificial tuvo un papel relevante en varias de estas investigaciones, tanto en el descubrimiento como en el desarrollo de vías de explotación complejas, aunque, según la noticia, no hay pruebas que liguen directamente la IA con lo ocurrido el 17 de octubre.
Estas ‘Vulnerabilidades PHP’ críticas, identificadas como CVE-2026-109618 y CVE-2026-109619, tienen una calificación de 9.2 sobre 10, ¡un puntaje que las coloca en la categoría de peligro extremo! El problema no es un simple ‘guayaito’ en un plugin o una aplicación cualquiera, sino que reside en partes fundamentales de PHP, específicamente en la gestión de memoria y los errores. Cloudflare explica que, bajo ciertas condiciones, una petición HTTP bien ‘prepará’ puede hacer que el servidor use datos internos de forma insegura, permitiendo la ejecución de código sin necesidad de autenticación. Esto significa que si tu página web usa PHP, ‘es mejor que te pongas las pilas’ y actualices de una vez, como recomienda PHP mismo.
La verdad es que el ‘coro’ de la divulgación coordinada empezó a desbaratarse el 20 de octubre. Según la PHP Foundation, alrededor de las 3:00 PM UTC, los identificadores de los dos CVE comenzaron a volar por ahí, aunque sin detalles técnicos y con información errónea. Esto forzó al proyecto a adelantar un día la publicación que tenían planeada. Después, se soltó por error un video de Calif con una demostración limitada, y para colmo, el 21 a las 7:41 AM UTC, Chainguard publicó imágenes con la corrección antes de que terminara el embargo. ¡Un verdadero ‘sancocho’! Pero, y aquí viene lo interesante, ninguno de estos ‘tropiezos’ conocidos explica de dónde salió la información para el intento de explotación de cuatro días antes.
Lo que vino después fue ‘un viaje de locura’ que sí se puede seguir sin problemas. Cloudflare pasó de registrar miles de intentos de explotación en las diez horas previas al anuncio, a decenas de miles en los primeros 45 minutos, cientos de miles en dos horas y, finalmente, ¡millones! Así lo detalló su CEO, Matthew Prince, en cifras recogidas por Reuters. La compañía también notó cómo los atacantes estaban modificando sus cargas para ‘tratar de coger a la gente en baja’ y esquivar las protecciones que se estaban desplegando. Amazon, por su lado, vio cómo los exploits se regaban ‘como pólvora’: aparecieron nuevos ejemplos de prueba de concepto y, una vez que se levantó el embargo, comenzaron a usarse contra sus sensores ‘de una vez’.
A estas alturas, casi toda la película está clara: sabemos cuándo se descubrieron los fallos, cómo se trabajaron las correcciones, cuándo el embargo se puso ‘flojo’ y con qué rapidez se multiplicaron los intentos tan pronto salieron más detalles. Pero el inicio de esta historia, ese ‘missing link’ que tiene a todos intrigados, es precisamente la actividad que Amazon detectó el 17 de octubre. Quién estaba detrás de ese ‘tigueraje’ cibernético y, más importante aún, cómo obtuvo ese conocimiento tan privilegiado, siguen siendo preguntas abiertas. La ‘ciberseguridad’ en la República Dominicana y el mundo tiene que estar atenta, porque siempre hay un ‘mañoso’ buscando dónde hacer de las suyas.Si te ha gustado este artículo, ¡compártelo con tus amigos, o déjanos un comentario!
Ingeniero de Sistemas especializado en Inteligencia Artificial y Automatización de Procesos. Con una trayectoria enfocada en la convergencia entre tecnología de vanguardia y comunicación digital, Ramón lidera la implementación de modelos generativos aplicados al periodismo dominicano. Su trabajo garantiza que la información que llega a la diáspora no solo mantenga nuestra identidad “del patio”, sino que cumpla con los más altos estándares de veracidad y optimización técnica de la web moderna (2026).
