Los cierres por fallas de seguridad de PHP en Japón llegan a 1.090 mientras los servicios tienen dificultades para reabrir

12 min de lectura
Japan's PHP Security Shutdowns Reach 1,090 as Services Struggle to Reopen

Cientos de servicios aún esperan volver a operar

La respuesta de Japón a dos graves fallas de seguridad de PHP ha interrumpido al menos 1.090 sitios web y servicios en línea; cientos todavía no habían anunciado su reapertura al 26 de octubre de 2026. La interrupción ha afectado las compras en línea, los trámites de cuentas financieras, los servicios de cuidado infantil y los videojuegos, mientras los operadores instalan correcciones y comprueban si sus sistemas son seguros para volver a conectarlos.

Contenido
  1. Cientos de servicios aún esperan volver a operar
  2. Qué pueden hacer las fallas PHP2shell
  3. Cómo se extendieron los cierres
  4. Por qué desconectar un sitio web se convirtió en una opción
  5. Un parche es solo una parte de la reapertura
  6. ¿Qué versiones requieren atención?
  7. Los intentos de ataque aumentan la urgencia
  8. Una tercera vulnerabilidad requiere cambiar una configuración
  9. Algunas organizaciones afrontan una decisión más amplia
  10. Puntos clave

Assured, una empresa de Tokio que proporciona información sobre evaluaciones de seguridad de servicios en la nube, contabilizó 1.090 suspensiones de servicios hasta las 15:00 del 26 de octubre. Su análisis se basó principalmente en publicaciones de cuentas oficiales en X que anunciaban cierres. El total aumentó desde 502 a las 14:00 del 23 de octubre: un incremento de 588, o cerca del 117%, en aproximadamente tres días.

Assured no había confirmado un anuncio de reapertura para 465 de esos servicios. Esto representa alrededor del 43% de las suspensiones registradas. Las cifras se basan en anuncios públicos, por lo que los operadores aún deben confirmar el estado actual de esos 465 servicios.

Bandai Namco Holdings esperaba reabrir al mediodía del 27 de octubre una tienda en línea que vende juguetes y otros productos, después de que las tareas de mantenimiento comenzaran la noche del 21 de octubre. Las conexiones en línea de juegos de máquinas recreativas, entre ellos Taiko no Tatsujin, seguían suspendidas. En Daiwa Securities, algunas funciones del sitio web ya estaban disponibles, mientras que las solicitudes para abrir cuentas de inversión NISA y trámites como los cambios de domicilio seguían sin estar disponibles a las 17:00 del 26 de octubre.

Qué pueden hacer las fallas PHP2shell

La Agencia de Promoción de las Tecnologías de la Información de Japón, conocida como IPA, identificó las vulnerabilidades como CVE-2026-109618 y CVE-2026-109619 en su alerta de seguridad de PHP del 22 de octubre. La combinación de ambas se conoce como PHP2shell. PHP es un software que se utiliza para ejecutar muchos sitios web y aplicaciones web, y procesa tareas en los servidores antes de que la información llegue al navegador de un usuario.

Publicidad

CVE-2026-109618 se refiere al manejo de errores cuando PHP se queda sin memoria. CVE-2026-109619 afecta al procesamiento de las solicitudes enviadas a un servidor. La explotación de las fallas podría permitir que un atacante remoto ejecute código arbitrario, es decir, instrucciones elegidas por el atacante y no por el operador del sitio web.

JPCERT/CC, el organismo de Japón encargado de coordinar la respuesta a incidentes de seguridad informática, señala que ese código podría ejecutarse con los permisos del proceso de PHP. En términos sencillos, un atacante podría realizar acciones que el software que ejecuta el sitio web tiene permitido realizar. El alcance dependería de los permisos y la configuración del sistema afectado.

La IPA indica que las organizaciones deben consultar la información de los desarrolladores o proveedores de los productos que utilizan, ya que PHP puede formar parte de una aplicación o un servicio más amplio. JPCERT/CC también advierte que el PHP incluido en productos de software o distribuciones de Linux podría estar afectado, por lo que las indicaciones de los proveedores son parte de la respuesta.

Cómo se extendieron los cierres

Los operadores comenzaron a desconectar sistemas el 21 de octubre, antes de que las actualizaciones de seguridad estuvieran disponibles, alrededor de las 23:00, hora de Japón. Algunos se adelantaron a la publicación, cuando la divulgación de detalles sobre las vulnerabilidades podía aumentar el riesgo de ataques.

La secuencia muestra cómo una actualización urgente de software provocó varios días de interrupciones:

  • 21 de octubre: BASE, Codmon, Pixiv, DMM.com, niconico y algunos servicios de Sakura Internet entraron en mantenimiento o suspendieron funciones. También se interrumpieron temporalmente juegos como Granblue Fantasy y Uma Musume Pretty Derby.
  • 21 de octubre, 21:55: la primera ministra Sanae Takaichi pidió preparativos urgentes para aplicar los parches y dijo que la suspensión temporal de sitios web era una opción cuando no fuera posible instalarlos de inmediato.
  • 21 de octubre, alrededor de las 23:00: se publicaron las actualizaciones de seguridad de PHP.
  • 22 de octubre: la IPA y JPCERT/CC publicaron alertas que explicaban las vulnerabilidades y las medidas recomendadas.
  • 23 de octubre: el recuento de Assured llegó a 502 suspensiones. Los desarrolladores de PHP también dieron a conocer otra vulnerabilidad, CVE-2026-115560.
  • 26 de octubre: el total de Assured llegó a 1.090, mientras que JPCERT/CC actualizó su advertencia con informes de intentos de explotación.
  • 27 de octubre, mediodía: Bandai Namco esperaba reabrir su tienda en línea de juguetes y otros productos.
Publicidad

Por qué desconectar un sitio web se convirtió en una opción

La Oficina Nacional de Ciberseguridad de Japón recomendó suspender temporalmente un sitio web para reducir los riesgos cuando los operadores no pudieran instalar el parche con rapidez. Takaichi reiteró esa opción en su mensaje del 21 de octubre. CERT-EU y el Centro Nacional de Ciberseguridad del Reino Unido también instaron a actuar y plantearon la posibilidad de desconectar los sistemas hasta que estuvieran implementadas las protecciones.

Las indicaciones de la IPA establecen una serie de opciones. Las organizaciones deben considerar primero protecciones temporales y restricciones de acceso mientras preparan una actualización o migración. Si resulta difícil aplicar medidas temporales eficaces, deben evaluar si bloquear el acceso externo o suspender el servicio, teniendo en cuenta los posibles daños y las interrupciones de la actividad.

Para los clientes, esa decisión significó perder acceso a funciones cotidianas mientras los operadores trabajaban. Una tienda en línea podía dejar de aceptar pedidos, un sitio web financiero podía suspender los trámites de cuentas y una máquina recreativa podía perder la conexión a las funciones en línea.

Yasuhiro Suzuki, quien dirigió la investigación de Assured, dijo que cada vez más operadores optaban por suspender servicios para proteger la información de los clientes, mientras que el lento restablecimiento mostraba lo difícil que podía ser reabrirlos de forma segura. Su evaluación refleja el principal problema operativo: cerrar el acceso puede ser rápido, pero restablecerlo requiere completar el trabajo necesario.

Un parche es solo una parte de la reapertura

Las interrupciones de Bandai Namco muestran por qué los servicios de un mismo grupo empresarial pueden reanudarse en distintos momentos. El grupo esperaba reabrir su tienda de productos el 27 de octubre, mientras que las conexiones de los juegos de máquinas recreativas seguían suspendidas. Las actualizaciones de los sistemas necesarias para instalar el parche de PHP estaban tardando.

Algunos servicios también evaluaban trasladar temporalmente sus datos a servidores de otra empresa cuya seguridad ya se había comprobado. Esto cambiaría el lugar donde funciona el servicio mientras los equipos trabajan en el entorno afectado y exigiría preparativos adicionales antes de que los clientes pudieran volver.

Daiwa Securities había restablecido algunas partes de su sitio web, incluidas las preguntas frecuentes, pero las solicitudes de apertura de cuentas y los cambios de domicilio seguían sin estar disponibles el 26 de octubre. Así, una página de información que funcionaba coexistía con trámites interrumpidos para los clientes.

Publicidad

La IPA explica que los sistemas que llevan mucho tiempo sin actualizarse podrían requerir cambios en el código de las aplicaciones y pruebas para comprobar que las funciones sigan operativas después de actualizar PHP. La falta de documentación de desarrollo, de personal que conozca el sistema y de contratos de mantenimiento vigentes puede dificultar el trabajo. JPCERT/CC recomienda realizar pruebas suficientes y luego instalar cuanto antes las versiones corregidas.

¿Qué versiones requieren atención?

La IPA y JPCERT/CC señalan cuatro versiones corregidas de PHP para las dos vulnerabilidades originales: PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Las versiones anteriores de cada una de esas ramas están afectadas. Los operadores deben elegir la corrección correspondiente a la rama de PHP que utiliza su sistema y consultar las indicaciones de su proveedor de software o sistema operativo.

Las instalaciones antiguas presentan un problema adicional. La IPA cita un hallazgo de la empresa de seguridad Wiz según el cual las versiones a partir de PHP 5.4 están afectadas por al menos una de las dos vulnerabilidades. PHP 8.1 y las versiones anteriores han llegado al fin del soporte, por lo que ya no reciben el mantenimiento habitual disponible para las versiones compatibles.

La IPA recomienda migrar a versiones de PHP con soporte o a productos y servicios que cuenten con protecciones cuando no haya una corrección disponible. JPCERT/CC añade que los desarrolladores de PHP proporcionaron medidas de mitigación limitadas para PHP 7.4, 8.0 y 8.1 debido a la gravedad de las vulnerabilidades.

La mitigación temporal reduce la exposición a través de determinadas vías de ataque. JPCERT/CC señala que la actualización es la solución para las vulnerabilidades originales, por lo que las organizaciones que utilicen configuraciones temporales aún deben planificar la actualización o migración de software que requieren sus sistemas.

Los intentos de ataque aumentan la urgencia

La actualización del 26 de octubre de JPCERT/CC a su aviso sobre vulnerabilidades de PHP señala que habían aparecido numerosos fragmentos de código de demostración que afirmaban explotar las fallas. También menciona informes reiterados de tráfico de red que intentaba explotarlas.

Que ese código tenga éxito depende de factores como la versión de PHP, el entorno de ejecución y la disposición de los datos en la memoria. JPCERT/CC advierte que podrían surgir otros métodos de ataque y técnicas dirigidas a entornos concretos, y recomienda tanto actualizar como investigar posibles intrusiones.

Publicidad

Entre las medidas de investigación que recomienda figuran buscar cookies PHPSESSID inusualmente largas o con un formato extraño, que contienen información utilizada para reconocer la sesión de un navegador. Otras señales de alerta incluyen solicitudes sospechosas que utilizan multipart/form-data, un formato común para las cargas de archivos, especialmente si se producen cerca de errores por límite de memoria o errores HTTP 500 que indican un problema del servidor.

También se deben examinar los fallos inesperados o los reinicios frecuentes de los procesos de trabajo de PHP. Estos procesos se encargan de gestionar las tareas entrantes. JPCERT/CC recomienda además buscar procesos sospechosos, comunicaciones externas y archivos recién creados, y mantener la vigilancia. Si se sospecha que hubo una intrusión, aconseja conservar los registros y otras pruebas, investigar el área afectada y aislar los sistemas cuando sea necesario.

Una tercera vulnerabilidad requiere cambiar una configuración

Los desarrolladores de PHP dieron a conocer CVE-2026-115560 el 23 de octubre, lo que añadió otra tarea durante la respuesta. JPCERT/CC señala que esta vulnerabilidad puede permitir la ejecución de código arbitrario si se da una combinación determinada de opciones de configuración y código de aplicación.

Los desarrolladores describieron la configuración afectada como poco común y previeron publicar una corrección en el ciclo habitual de versiones. Hasta entonces, JPCERT/CC transmitió la recomendación de establecer session.upload_progress.enabled=0 y reiniciar todos los procesos de trabajo. En su actualización del 26 de octubre, no indicó una fecha de publicación para la corrección.

La misma configuración ya se había recomendado como medida de mitigación para CVE-2026-109619. Según el aviso, los operadores que ya la habían aplicado no necesitaban repetir ese paso. Al revisar sus sistemas, los equipos aún deben tener en cuenta tanto las dos vulnerabilidades originales como este problema adicional.

Algunas organizaciones afrontan una decisión más amplia

Las recomendaciones de la IPA van más allá de la reparación inmediata. La agencia pide a las organizaciones que examinen qué función sigue cumpliendo un sistema, cuánto se utiliza y si otro servicio podría sustituirlo. En el caso de un software que lleva tiempo sin mantenimiento, restablecer el servicio puede exigir decidir quién se encargará de mantenerlo después.

La IPA señala que tanto los directivos y responsables de las empresas como el personal técnico deben evaluar si cuentan con las personas, el presupuesto y los acuerdos de mantenimiento necesarios para actualizar o migrar el sistema y mantenerlo en funcionamiento. Si es posible proporcionar ese apoyo, la agencia recomienda realizar la actualización o migrar a un servicio protegido.

Publicidad

Si no es posible garantizar el mantenimiento continuo, la IPA enumera otras opciones: migrar a un producto con soporte, reducir las funciones, poner fin al acceso público o retirar el sistema. También pide preparar planes para conservar o transferir los datos necesarios y explicar a los usuarios qué alternativas tendrán.

El desafío práctico abarca ahora desde instalar versiones específicas de PHP hasta restablecer funciones concretas para los clientes. La reapertura prevista de la tienda de Bandai Namco representa un paso programado, mientras que los 465 servicios sin anuncios de reapertura confirmados en el recuento de Assured muestran cuánto quedaba por comprobar públicamente el 26 de octubre.

Puntos clave

  • Assured contabilizó 1.090 suspensiones de servicios en Japón hasta las 15:00 del 26 de octubre, frente a 502 el 23 de octubre.
  • No se habían confirmado anuncios de reapertura para 465 servicios, alrededor del 43% del total.
  • Las vulnerabilidades PHP2shell pueden permitir que atacantes remotos ejecuten código con los permisos del proceso de PHP.
  • Las versiones corregidas para las dos fallas originales son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
  • JPCERT/CC advirtió sobre la publicación de código de demostración y los informes de intentos de explotación.
  • Una tercera vulnerabilidad requiere un cambio temporal en la configuración y el reinicio de todos los procesos de trabajo mientras se prepara una corrección.
  • Bandai Namco esperaba reabrir su tienda de productos al mediodía del 27 de octubre; algunas conexiones de máquinas recreativas y trámites de Daiwa Securities seguían suspendidos el 26 de octubre.
Compartir este artículo

También le puede interesar