La semana negra de la ciberseguridad, PHP2Shell, Java y 1.295 parches de Oracle en apenas unos días

Hay semanas en las que la seguridad informática parece avanzar silenciosamente, aparecen actualizaciones, se corrigen errores y prácticamente nadie fuera del sector se entera. La semana del 19 de octubre de 2026 fue exactamente lo contrario.

El martes Oracle publicó una de sus grandes actualizaciones trimestrales con 1.295 nuevos parches de seguridad distribuidos entre decenas de productos, solamente Java SE recibió 55 correcciones. Un día después llegó lo que podríamos llamar sin exagerar el miércoles negro de PHP, con dos vulnerabilidades críticas capaces de permitir ejecución remota de código sin autenticación y organismos públicos que llegaron a desconectar páginas preventivamente mientras actualizaban.

Como si eso fuera poco, durante las horas siguientes Amazon reveló que ya había observado intentos de explotación antes de que las vulnerabilidades de PHP fueran anunciadas públicamente y el viernes 23 apareció una tercera falla, CVE-2026-115560, para la que todavía no existe un parche definitivo.

Visto individualmente, cada episodio tiene características diferentes. Vistos juntos, dejan una semana bastante difícil de olvidar para administradores de sistemas, desarrolladores, proveedores de hosting y cualquiera que dependa de infraestructura conectada a Internet.

Pero también es una buena oportunidad para entender algo que suele perderse entre titulares alarmantes, no todas las vulnerabilidades significan lo mismo, no todas tienen el mismo riesgo y una cantidad enorme de CVE tampoco implica necesariamente que millones de computadoras estén siendo atacadas en ese momento.

Martes 20, Oracle abre la semana con 1.295 nuevos parches de seguridad

La primera gran señal apareció el martes 20 de octubre con el Critical Patch Update de Oracle, conocido habitualmente como CPU.

Estas actualizaciones no son inesperadas, Oracle las publica siguiendo un calendario conocido y permiten corregir vulnerabilidades de numerosos productos al mismo tiempo.

Lo extraordinario esta vez fue nuevamente su dimensión.

El paquete de octubre incluyó 1.295 nuevos parches de seguridad distribuidos entre productos como Oracle Database, Fusion Middleware, Java SE, MySQL, PeopleSoft, JD Edwards, E-Business Suite, Oracle Communications, sistemas de análisis y numerosas plataformas empresariales.

Dentro del propio paquete aparecieron además vulnerabilidades con puntuación CVSS 10.0, el máximo de la escala utilizada para representar gravedad, en productos como Oracle Access Manager y diferentes componentes de Oracle SOA Suite.

De cualquier manera, la magnitud del paquete muestra algo que muchas veces queda invisible para quien solamente utiliza una computadora o una página web, detrás de los servicios que usamos diariamente existe una enorme cantidad de software que necesita recibir correcciones permanentemente.

Java tampoco pasó una semana tranquila, Oracle corrigió 55 problemas de seguridad

Dentro de la actualización de Oracle hubo un apartado especialmente grande dedicado a Java SE.

Oracle publicó 55 nuevos parches de seguridad para Java y señaló que 49 de las vulnerabilidades podían explotarse remotamente sin necesidad de autenticación, es decir, mediante una red sin que el atacante necesitara previamente una cuenta válida.

Eso no significa que las 49 permitan automáticamente tomar control de cualquier computadora con Java instalado. Algunas necesitan condiciones adicionales, otras afectan componentes concretos y el impacto cambia de acuerdo con la forma en que Java esté siendo utilizado.

La puntuación más alta dentro de la matriz de riesgo publicada por Oracle para Java SE fue 7.5, mientras que el paquete completo de Oracle sí incluyó vulnerabilidades CVSS 10.0 en otros productos.

Oracle recomienda mantener el JDK actualizado con cada Critical Patch Update, especialmente en empresas que utilizan Java en aplicaciones internas, servidores, sistemas administrativos o desarrollos propios.

Y una aclaración que siempre vale la pena hacer, Java no es JavaScript

Los nombres siguen provocando confusión incluso después de décadas, pero Java y JavaScript son tecnologías diferentes.

Que Oracle publique vulnerabilidades para Java no significa que de repente todos los sitios que utilizan JavaScript en el navegador estén afectados.

Java sigue siendo muy utilizado en aplicaciones empresariales, sistemas internos, servicios y plataformas de gran escala, mientras JavaScript es uno de los lenguajes fundamentales de la web moderna.

Por eso leer simplemente “55 fallas en Java” sin entender qué producto, versión y escenario está involucrado puede llevar a conclusiones equivocadas.

Miércoles 21, PHP convierte una semana complicada en un verdadero miércoles negro

Si el martes había sido intenso, lo ocurrido el miércoles llevó la preocupación a otro nivel.

PHP publicó actualizaciones extraordinarias para solucionar CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades puntuadas con CVSS 9.2 capaces de terminar en ejecución remota de código sin autenticación.

Eso significa que, bajo las condiciones necesarias, un atacante podía enviar solicitudes especialmente diseñadas a un servidor y conseguir ejecutar código sin iniciar sesión previamente.

Las nuevas versiones fueron:

PHP fue muy claro, las mitigaciones podían reducir determinadas vías de ataque, pero actualizar era la única solución completa.

El problema era además especialmente relevante para Internet porque PHP no es una aplicación aislada que utilizan unas pocas organizaciones, es la tecnología que se encuentra debajo de una enorme cantidad de páginas y aplicaciones web.

WordPress.org publicó incluso una advertencia específica recomendando que los propietarios de sitios comprobaran su versión de PHP y actualizaran cuanto antes, aclarando al mismo tiempo que no se trataba de una vulnerabilidad de WordPress y que ninguna actualización de WordPress podía solucionar el problema.

Después conocimos un dato todavía más inquietante, alguien estaba intentando explotarlo desde el 17 de octubre

Una de las revelaciones más interesantes de toda la semana llegó desde Amazon Threat Intelligence.

Su red de honeypots MadPot detectó el 17 de octubre un intento de explotación relacionado con PHP2Shell, cuatro días antes de que las vulnerabilidades fueran divulgadas públicamente.

Amazon señaló que aquel intento provenía de una dirección asociada con una red comercial de anonimización y que no sabe cómo el actor consiguió información suficiente para intentar el ataque antes de finalizar el embargo.

Durante la madrugada del propio 21 de octubre también aparecieron diferentes pruebas de concepto e intentos procedentes de distintas infraestructuras, antes de que llegara la hora prevista para levantar oficialmente el embargo.

Una vez publicados los parches y los detalles técnicos, Amazon observó nuevas pruebas de explotación prácticamente de inmediato.

Sin embargo, conviene mantener una distinción importante, detectar intentos de explotación no equivale automáticamente a demostrar que esos ataques consiguieron comprometer servidores reales.

El impacto fue tan grande que algunos organismos prefirieron apagar antes que arriesgar

Durante las primeras horas existía demasiada incertidumbre sobre la facilidad con la que PHP2Shell podía explotarse, por eso distintos organismos y organizaciones decidieron desconectar temporalmente servicios expuestos a Internet mientras verificaban versiones y aplicaban las correcciones.

CISA en Estados Unidos pidió aplicar los parches inmediatamente y recomendó que los sistemas que no pudieran actualizarse, especialmente aquellos utilizando ramas de PHP antiguas y sin soporte, fueran retirados temporalmente de Internet.

ENISA, CERT-EU, Europol EC3 y otros organismos europeos publicaron recomendaciones similares, priorizando todos los sistemas PHP accesibles desde Internet.

El mensaje era excepcionalmente contundente porque las vulnerabilidades ocurrían dentro del propio runtime PHP, incluso antes de que determinadas aplicaciones llegaran a ejecutar su código habitual.

Viernes 23, cuando parecía que la semana terminaba PHP anunció CVE-2026-115560

Dos días después de corregir PHP2Shell, PHP publicó otro aviso relacionado con el mecanismo de progreso de subida de archivos y las sesiones.

La nueva vulnerabilidad recibió el identificador CVE-2026-115560 y también puede abrir un posible camino hacia ejecución remota de código.

Pero esta vez el contexto es bastante diferente.

Para que aparezca la condición vulnerable, una aplicación debe utilizar inicialmente determinados formatos de serialización de sesión, modificarlos durante la ejecución mediante ini_set() antes de iniciar la sesión y mantener activa además la función session.upload_progress.enabled.

PHP considera que esa combinación es poco habitual y decidió solucionar el problema dentro de su próximo ciclo normal de mantenimiento en lugar de publicar otra actualización extraordinaria.

Mientras llega el parche definitivo, recomienda:

Esta misma medida ya había sido incluida entre las mitigaciones publicadas el miércoles, por eso quienes la aplicaron entonces no necesitan realizar una nueva modificación y simplemente deben mantenerla.

Sábado 24, así termina por ahora una de las semanas más intensas del año

Con algo más de distancia, el panorama puede resumirse de manera mucho más clara que durante el miércoles.

Además, las investigaciones realizadas durante los días posteriores indican que explotar las dos vulnerabilidades originales de PHP resulta más complejo de lo que inicialmente se temía y la probabilidad de una explotación masiva parece menor.

Eso no significa que el peligro haya desaparecido, solamente que el escenario más apocalíptico de las primeras horas no terminó materializándose de la manera que algunos titulares sugerían.

Los parches siguen siendo obligatorios.

Meter todas estas vulnerabilidades dentro de la misma bolsa sería un error

Precisamente porque ocurrieron en pocos días podemos caer en la tentación de pensar que Java, Oracle y PHP atravesaron exactamente la misma emergencia.

No fue así.

Oracle publicó una actualización trimestral planificada que concentró una enorme cantidad de correcciones.

Java formó parte de esa actualización y recibió decenas de parches, muchos relacionados con posibilidades de explotación remota, pero no apareció repentinamente una única vulnerabilidad Java equivalente a PHP2Shell que obligara a desconectar Internet de emergencia.

PHP2Shell, en cambio, representó una divulgación extraordinaria de dos vulnerabilidades críticas de alcance transversal, con una actualización fuera del ciclo normal y explotación ya siendo investigada.

Finalmente, CVE-2026-115560 volvió a involucrar PHP, aunque bajo unas condiciones mucho más específicas y con una valoración actual bastante inferior en cuanto a probabilidad de explotación.

Esta semana dejó además otro protagonista silencioso, la inteligencia artificial

PHP2Shell también mostró cómo está cambiando el ritmo de la seguridad informática.

Las vulnerabilidades originales fueron descubiertas independientemente por equipos de investigación que utilizaron herramientas modernas de análisis, mientras Amazon advirtió además que la inteligencia artificial está reduciendo el tiempo necesario para estudiar parches, comparar cambios de código y convertir una corrección publicada en un posible exploit.

Esto no significa que una IA presione un botón y automáticamente pueda atacar cualquier sistema.

Significa algo posiblemente más importante, tareas que antes podían demandar bastante tiempo a investigadores altamente especializados ahora pueden acelerarse, y eso reduce la ventaja temporal que tienen los defensores después de publicarse un parche.

Durante años era habitual pensar en ventanas de actualización medidas en días o incluso semanas.

En vulnerabilidades críticas de servicios expuestos directamente a Internet, esa lógica empieza a quedarse vieja.

Para una empresa, la principal enseñanza no es aprenderse las CVE de memoria

Un comercio, estudio profesional o pyme no necesita convertirse en especialista en PHP, Java, servidores o análisis forense para tener presencia en Internet.

Pero sí necesita entender que una página web profesional depende de mucho más que aquello que vemos en pantalla.

Detrás existen un hosting, una versión de PHP, un servidor web, una base de datos, un CMS, plugins, APIs y otras tecnologías que continúan evolucionando después del día en que el sitio fue publicado.

Por eso mantenimiento no debería significar únicamente cambiar un texto, subir una foto o comprobar que la página abre.

Preguntas frecuentes sobre la semana de vulnerabilidades

Quizás no fue la semana en que Internet estuvo a punto de romperse, pero sí una semana que explicó perfectamente cómo funciona la seguridad moderna

Cuando miramos todo junto parece una tormenta perfecta, más de mil parches de Oracle, decenas de correcciones en Java, dos fallas críticas de PHP, intentos de explotación detectados antes de la divulgación y una tercera vulnerabilidad de PHP apareciendo apenas dos días después.

Pero el aprendizaje más interesante no surge de acumular cifras.

Surge de observar la velocidad.

Una vulnerabilidad puede descubrirse, permanecer bajo embargo, empezar a atraer intentos de explotación, recibir un parche y ser analizada por atacantes prácticamente dentro de la misma semana.

Al mismo tiempo, proveedores de infraestructura, empresas de seguridad, organismos públicos y desarrolladores tienen que responder coordinadamente mientras millones de sistemas continúan funcionando.

Por eso la seguridad real nunca fue instalar algo una vez y olvidarse.