Vulnerabilidad crítica en PHP: qué pasó y por qué conviene mantener las aplicaciones al día

Qué pasó

El 20 de octubre de 2026 el proyecto PHP avisó que publicaría una versión de seguridad al día siguiente. El 21 de octubre llegaron las versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Corrigen dos vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619. Las dos tienen una calificación de 9,2 en la escala CVSS v4.0, que llega hasta 10, y según el proyecto pueden permitir la ejecución remota de código sin autenticación.

En palabras simples: si se aprovechan, una persona externa podría acceder a la aplicación y ejecutar cualquier acción a su discreción, desde robar datos hasta tomar el control de la aplicación. Por eso recomendamos la actualización con insistencia.

Tras el anuncio se reportaron intentos de explotación activos, y circuló una prueba de concepto pública conocida como PHP2Shell. Hasta donde sabemos, las fuentes consultadas no confirman intrusiones exitosas en un servidor específico, pero el tiempo para actuar es corto.

A quién le aplica

El anuncio de PHP indica que el riesgo cubre todas las instalaciones de PHP que atienden peticiones web, entre ellas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Esto incluye sitios web y aplicaciones que corren sobre servidores propios o en la nube.

Dos precisiones del mismo anuncio:

• PHP 8.1 y versiones anteriores ya no reciben actualizaciones del proyecto. Algunos proveedores de distribuciones ofrecen correcciones propias; si no es su caso, la salida es migrar a una versión con soporte.
• PHP 8.2 llega al fin de su vida útil el 31 de diciembre de 2026, así que conviene planear desde ahora el paso a una versión más reciente.

¿Tiene dudas sobre qué versión usa su aplicación? Agende una llamada de hasta 30 minutos y la revisamos con usted.

Qué hicimos en InnClod

Desde el 21 de octubre aplicamos medidas preventivas y reglas de mitigación en los firewalls y en la seguridad perimetral de la infraestructura que administramos. Esas medidas reducen la exposición mientras se completa la actualización.

El propio proyecto PHP aclara que las mitigaciones temporales disminuyen el riesgo en caminos específicos, pero que actualizar es la única corrección completa. Por eso el siguiente paso es llevar cada aplicación a la última versión de PHP que sea compatible con ella.

Actualizar PHP puede impactar muchas partes de una aplicación, así que en algunas habrá una interrupción temporal. El tiempo exacto depende de cada una: lo estimamos caso por caso y se lo confirmamos directamente a cada cliente. Nuestra meta es terminar a más tardar el 28 de octubre, o antes si las pruebas lo permiten. Cuando la actualización queda fuera del esquema de soporte de servidores contratado, tiene un costo adicional que informamos antes de empezar.

Por qué importa mantener las aplicaciones actualizadas

Cuando se publica una corrección de seguridad, también se hace público qué se corrigió. Desde ese momento, cada día que una aplicación sigue en la versión anterior es un día en que la información para atacarla está disponible. Por eso las actualizaciones de seguridad pierden valor con el paso del tiempo.

Con más de 35 aplicaciones en soporte continuo, lo que más nos ayuda es que actualizar sea parte del mantenimiento normal y no una urgencia. Estas son las ventajas de ese hábito:

• Saltos más pequeños. Pasar de una versión a la siguiente es más sencillo que recuperar varios años de atraso.
• Compatibilidad probada. Una aplicación que se ajusta con frecuencia llega a un parche crítico lista para recibirlo.
• Soporte vigente. Las versiones con soporte reciben correcciones; las que ya no lo tienen dependen de terceros.
• Ventanas planeadas. Una interrupción acordada con anticipación afecta menos al negocio que una decisión de último momento.

Qué puede revisar hoy

Si administra sus propios servidores o aplicaciones, estos pasos son un buen comienzo:

1. Identifique la versión de PHP que usa cada sitio o aplicación.
2. Compare con las versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
3. Consulte con su proveedor de sistema operativo si ya publicó el paquete actualizado.
4. Revise en el anuncio oficial las medidas temporales, y recuerde que no reemplazan la actualización.
5. Planee la ventana de mantenimiento y avise a sus usuarios.

Si prefiere que nos encarguemos, esto hace parte de lo que ofrecemos en nuestros servicios de infraestructura y soporte: servidores en la nube, copias de seguridad, monitoreo y mesa de ayuda de lunes a viernes, de 8:00 a. m. a 5:00 p. m., hora de Colombia.

Preguntas frecuentes

¿Mi aplicación está afectada?

El anuncio de PHP cubre las instalaciones que atienden peticiones web. Si su aplicación está escrita en PHP, la forma de saberlo es revisar la versión instalada y compararla con las corregidas.

¿Hasta cuándo habrá interrupciones en las aplicaciones que administra InnClod?

Depende de cada aplicación. Estimamos el tiempo caso por caso y cada cliente recibe aviso directo; nuestra meta es terminar a más tardar el 28 de octubre.

¿La actualización tiene costo?

Si su aplicación hace parte de su esquema de soporte de servidores, lo revisamos con usted. Cuando queda fuera de ese esquema, la actualización tiene un costo adicional, y se lo informamos con la estimación antes de empezar.

¿Las medidas de mitigación son suficientes?

No. Según el proyecto PHP reducen la exposición, pero actualizar es la única corrección completa.

¿Qué pasa si mi aplicación usa PHP 8.1 o una versión anterior?

Esas versiones ya no reciben actualizaciones del proyecto. Conviene consultar a su proveedor por correcciones propias o migrar a una versión con soporte.