Si actualizó el sitio web de su empresa a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 tras la falla PHP2Shell, hizo lo correcto, pero eso no lo cubre todo. El 23 de octubre de 2026, el proyecto PHP publicó una nueva alerta sobre una tercera falla, CVE-2026-115560, que la actualización del 21 de octubre no corrige. Requiere una configuración poco habitual y PHP la considera una vía improbable, pero la solución temporal es sencilla: pida hoy a su equipo o a su proveedor de hosting que ponga session.upload_progress.enabled en 0 y reinicie PHP, y luego que confirme por escrito que la actualización del 21 de octubre se aplicó de verdad.

¿Qué anunció PHP el 23 de octubre?

Dos días después de la versión de emergencia, el proyecto publicó una breve alerta informativa sobre el seguimiento del «progreso de carga» en las sesiones, la función que muestra al usuario cuánto lleva subido un archivo grande. La alerta dice que esta función puede abrir una vía de ejecución remota de código en un caso concreto, y que la corrección llegará en la próxima versión regular y no como actualización de emergencia, junto con un aviso completo sobre la falla.

Para un empresario importan dos puntos. Primero, se trata de una falla distinta, así que usar una de las cuatro versiones anteriores no basta por sí solo. Segundo, la misma medida temporal ya figuraba en el aviso sobre CVE-2026-109619 del 21 de octubre. Si su equipo la aplicó entonces, no hace falta nada nuevo: manténgala.

¿Está expuesto su sitio?

Según la alerta de PHP, el problema solo aparece cuando se cumplen tres condiciones:

  • La configuración de PHP fija session.serialize_handler en php_binary o php_serialize.
  • El código de la aplicación lo cambia a php en tiempo de ejecución con ini_set() antes de iniciar la sesión.
  • El seguimiento del progreso de carga sigue activo, como viene por defecto.

La mayoría de los sitios no hace esto. El problema es que un dueño rara vez sabe qué hace cada línea de un sistema construido hace años o de un plugin antiguo. Por eso, la opción más segura: si su sitio no muestra una barra de progreso al subir archivos, desactivar la función no rompe nada y cierra la puerta. Si depende de ella, pregunte a sus desarrolladores si el código cambia ese ajuste en tiempo de ejecución.

Tres días después: compruebe que la actualización del 21 de octubre se aplicó

Las fallas originales, CVE-2026-109618 y CVE-2026-109619, siguen siendo el mayor riesgo. La Autoridad Nacional de Ciberseguridad de Arabia Saudí (NCA) emitió la alerta n.º 2026-7949 sobre ellas, y la agencia estadounidense CISA aconsejó inventariar todos los sistemas PHP, parchear primero los expuestos a internet y desconectar un sistema si no se puede parchear de inmediato. CISA dijo que no había visto explotación exitosa en el momento de la publicación, lo que no significa que el tiempo juegue a su favor.

Tres puntos que muchos pasan por alto:

  • Reiniciar, no recargar. El boletín de Red Hat indica que los cambios de configuración requieren reiniciar los procesos de PHP y que una recarga por sí sola no basta.
  • El número de versión puede ser distinto en servidores Linux. El anuncio de PHP dice que las distribuciones de Linux recibieron los parches por adelantado, así que puede ver un número distinto de 8.5.12, por ejemplo, aunque la corrección esté aplicada. Pida a su proveedor una confirmación por escrito, no solo un número. Red Hat señala que RHEL 8, 9 y 10 están todos afectados.
  • La forma en que se ejecuta PHP cambia el riesgo. El proyecto PHP considera el riesgo más alto con mod_php en Apache, mientras que Red Hat dice que la explotación es más difícil en la práctica con PHP-FPM por defecto. Más difícil no es imposible, así que la actualización es necesaria en ambos casos.

5 preguntas para enviar hoy a su proveedor o a su equipo

  1. ¿Qué versión de PHP corre en cada uno de nuestros sitios y sistemas, y incluye las correcciones del 21 de octubre de 2026?
  2. ¿Se reiniciaron los procesos de PHP tras la actualización, y no solo se recargaron?
  3. ¿Hemos puesto session.upload_progress.enabled en 0? Si no, ¿de verdad necesitamos la función?
  4. ¿El código de nuestro sitio cambia session.serialize_handler en tiempo de ejecución?
  5. ¿Tenemos algún sitio en 8.1 o anterior? Esas ramas ya no tienen soporte, y la tabla de versiones con soporte muestra que el soporte de seguridad de 8.2 termina el 31 de diciembre de 2026.

La visión de Origami

Tres alertas en tres días es normal tras una falla grave: cuando los investigadores escarban en una parte del lenguaje, encuentran lo que hay al lado. Pero también dice algo de las empresas. Quien parcheó el día 21 y cerró el asunto se perderá la alerta del 23. Aquí la seguridad es un seguimiento continuo, no una tarea que se termina una vez.

Lo que vemos en las empresas saudíes es que la pregunta difícil no es «¿cuál es la falla?», sino «¿quién de los nuestros lee una alerta de PHP un viernes por la mañana y sabe qué servidor es el nuestro?». En Origami creamos sitios web y sistemas y vigilamos sus actualizaciones desde el primer día. Si quiere revisar su sitio, o aplicar estos ajustes sin interrumpir el servicio, contáctenos.

En resumen

La actualización del 21 de octubre es imprescindible y sigue siendo lo más importante; la nueva alerta no cambia eso. Añada hoy un paso barato: desactive el seguimiento del progreso de carga si no lo necesita, reinicie PHP y obtenga una confirmación por escrito de su proveedor. Después esté atento a la próxima versión regular de PHP, que traerá la corrección definitiva de CVE-2026-115560.

Fuentes