• 22 Oct 2026 | 08:10:15 AM
• SISTEMA 5 SAS

Alerta crítica de seguridad en PHP: ¿qué está pasando y qué debe hacer tu empresa?

Dos vulnerabilidades críticas pueden permitir la ejecución remota de código sin autenticación. Si tu organización utiliza PHP en páginas web, portales, aplicaciones o servicios expuestos a Internet, es momento de revisar la infraestructura.

El 21 de octubre de 2026 se publicaron actualizaciones de seguridad para corregir dos vulnerabilidades críticas identificadas como CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación CVSS v4.0 de 9,2 y pueden permitir ejecución remota de código sin autenticación.

El riesgo merece especial atención porque PHP forma parte de la infraestructura de numerosas aplicaciones y productos. El problema no debe abordarse únicamente preguntando si una empresa “tiene una página en PHP”, sino identificando dónde se está ejecutando PHP dentro de toda la infraestructura tecnológica

¿Qué está pasando con PHP?

Las vulnerabilidades afectan al propio núcleo de PHP y pueden permitir que un atacante remoto ejecute código en un servidor vulnerable sin necesidad de autenticarse previamente.

Las vulnerabilidades han sido identificadas como:

1. CVE-2026-109618: vulnerabilidad relacionada con corrupción de memoria.
2. CVE-2026-109619: vulnerabilidad relacionada con la reutilización de un estado interno de una solicitud anterior.

Ambas pueden desembocar en Remote Code Execution (RCE) y tienen una calificación CVSS 9,2 – Crítica.

¿Qué sistemas pueden estar expuestos?

De acuerdo con la información operacional recopilada por NCSC-NL, las instalaciones PHP que atienden solicitudes web están en riesgo. Esto contempla entornos como PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera especialmente relevante el riesgo asociado a configuraciones con mod_php.

Existe además otro aspecto que las organizaciones deben contemplar.

PHP puede estar integrado dentro de appliances, dispositivos de red, interfaces de administración y otros productos de terceros, por lo que una organización podría depender de PHP sin administrarlo directamente como un componente independiente.

¿Cuáles son los riesgos para una empresa?

Una vulnerabilidad de ejecución remota de código puede permitir comprometer el servidor vulnerable con los privilegios del proceso afectado.

Desde una perspectiva empresarial, esto obliga a considerar la seguridad no solamente del servidor PHP, sino también de las aplicaciones, información y recursos a los que ese sistema pueda acceder.

El nivel de impacto real dependerá de factores como la configuración del entorno, privilegios, segmentación y exposición de cada servidor.

Por eso es importante evitar dos extremos: minimizar la vulnerabilidad por tratarse de un componente técnico o asumir automáticamente que toda la infraestructura está comprometida.

Lo correcto es identificar, verificar, actualizar y monitorear.

¿Qué versiones de PHP deben utilizarse?

Este es posiblemente el punto más importante para los responsables de infraestructura.

Las correcciones fueron publicadas el 21 de octubre de 2026 en las siguientes versiones:

Esto significa que no basta con decir “tenemos PHP 8.4”.

Por ejemplo, una infraestructura que ejecute una versión PHP 8.4 anterior a 8.4.27 necesita ser revisada y actualizada.

El objetivo debe ser utilizar una rama soportada e instalar como mínimo la versión corregida correspondiente, teniendo en cuenta también las actualizaciones posteriores que estén disponibles.

¿Y qué ocurre con PHP 8.1 y versiones anteriores?

Este punto es especialmente importante en infraestructuras antiguas.

NCSC-NL indica que PHP 8.1 y versiones anteriores ya no cuentan con soporte del proyecto PHP. Algunos proveedores y distribuciones LTS pueden proporcionar paquetes con correcciones retroportadas, y PHP publicó backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1.

Por ello, encontrar una versión antigua no debería llevar simplemente a ignorarla porque “la aplicación siempre ha funcionado así”.

Si una aplicación depende todavía de una rama sin soporte, la organización debería revisar la actualización proporcionada por su distribución o proveedor y valorar la migración hacia una rama actualmente mantenida.

No esperes a que una vulnerabilidad se convierta en un incidente

La ciberseguridad no consiste únicamente en reaccionar cuando aparece un ataque.

Consiste en conocer la infraestructura, identificar oportunamente la exposición y actuar antes de que una vulnerabilidad pueda convertirse en un incidente.

Si tu organización utiliza PHP, este es el momento de identificar qué versiones están desplegadas, revisar los sistemas expuestos, aplicar las actualizaciones correspondientes y mantener monitorización sobre la infraestructura.

IDENTIFICA • ACTUALIZA • PROTEGE