Alerta en PHP: dos fallas críticas permiten tomar el control de servidores web y la solución es actualizar hoy

Por Vítor Jaime de Oliveira · VitorProDev · Caracas

PHP es el lenguaje con el que funciona buena parte de la web: gestores de contenido, tiendas en línea, sistemas de facturación y portales institucionales. El 21 de octubre, el equipo de PHP publicó un aviso de seguridad titulado «Critical remote code execution vulnerabilities, update now» (https://www.php.net/archive/2026.php#2026-10-21-5) junto con cuatro versiones nuevas que corrigen dos fallas críticas en el núcleo del lenguaje.

Ese mismo día, la División Cibernética del FBI difundió una alerta (https://x.com/FBICyberDiv/status/2112921648252719420) en la que pide actualizar «de inmediato», inventariar dónde corre PHP y, si no es posible actualizar enseguida, considerar sacar el sistema de línea hasta mitigarlo.

Qué fallas son

• CVE-2026-109618 (corrupción por falta de memoria). Cuando una petición supera el límite de memoria, PHP aborta su procesamiento. Ese corte puede ocurrir con datos internos a medio inicializar, por ejemplo durante la subida de un archivo por formulario, y la limpieza posterior los trata como válidos.
• CVE-2026-109619 (estado global obsoleto). Cierto estado interno de una petición puede sobrevivir después de liberarse su memoria, por ejemplo tras un error fatal. Una petición posterior atendida por el mismo proceso puede usar ese estado antes de reiniciarlo.

Ambas tienen una puntuación CVSS 4.0 de 9.2 (crítica) en la base NVD, según la puntuación asignada por el propio equipo de seguridad de PHP. Las dos permiten ejecución remota de código sin autenticación.

Según php.net, están en riesgo todas las instalaciones de PHP que atienden peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera que el riesgo es mayor con mod_php, donde hay un exploit demostrado en el que una sola petición sin autenticar dispara el ataque antes de que se ejecute cualquier código de la aplicación.

Versiones afectadas y corregidas

Ramas de PHP afectadas y versión que corrige cada una. La 8.1 y anteriores no reciben versión oficial del proyecto. — Crédito: Infografía VitorProDev con datos de php.net, NVD y CERT-EU.

Para la 8.1 y anteriores, el proyecto ya no publica actualizaciones. Algunas distribuciones y proveedores de soporte extendido ofrecen parches retroportados, y dada la gravedad, el equipo de seguridad de PHP publicó parches mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta. La recomendación de fondo sigue siendo migrar a una rama soportada.

Cómo está la situación hoy

Verificado la mañana del 22 de octubre (hora de Caracas):

• Pruebas de concepto: el aviso CERT-EU 2026-018 indica que los detalles técnicos se discuten públicamente y que han comenzado a circular las primeras pruebas de concepto, lo que «aumenta la probabilidad» de que ya haya atacantes explotándolas.
• Explotación activa confirmada:  Ninguna de las fuentes oficiales consultadas confirma todavía ataques reales en curso.
• Catálogo KEV de CISA: a la fecha de la versión del catálogo consultada (21 de octubre, 10:04 a. m., hora de Caracas), ninguna de las dos CVE figura en él. El FBI recomienda seguirlo, así que conviene volver a revisarlo antes de publicar.
• Nuevas versiones: no hay versiones posteriores a 8.5.12, 8.4.27, 8.3.36 y 8.2.35 en php.net.

Qué significa para Monagas

En Monagas, como en el resto del país, muchas pymes, comercios, colegios y medios tienen su sitio en un hosting compartido o en un servidor que alguien configuró hace años. Gestores de contenido, tiendas en línea y sistemas administrativos hechos a medida suelen funcionar con PHP, y no es raro que nadie recuerde qué versión tiene. [No se cuenta con estadísticas sobre cuántos sitios de la región usan PHP ni con qué versión.]

El riesgo práctico es que estas fallas no requieren usuario ni contraseña: basta con que el servidor esté expuesto a internet. Un sitio comprometido puede servir para robar datos de clientes, alojar páginas fraudulentas o atacar a otros. Por eso la prioridad son los sitios públicos y los productos que traen PHP incorporado, aunque no lo parezca (paneles de administración, equipos de red, software de terceros). CERT-EU recomienda consultar el repositorio del NCSC neerlandés (https://github.com/NCSC-NL/php2shell) para identificar software que incluye PHP.

Qué hacer hoy

1. Revisar la versión, en los dos lados. php -v en la terminal muestra la versión de la línea de comandos (CLI), pero el sitio web puede usar otro binario: PHP-FPM o mod_php. Para saber cuál atiende la web, usar una página temporal con phpinfo() (y borrarla después) o php-fpm -v. Pueden ser versiones distintas.
2. Paquetes de la distribución. Las distribuciones Linux y los proveedores de soporte extendido recibieron los parches por adelantado. En Debian, Ubuntu, Red Hat y similares, el arreglo puede venir como backport: el número de versión no cambia a 8.x.y, pero el paquete está corregido. Hay que revisar el registro de cambios o el aviso de seguridad de la distribución, no solo el número.
3. Quien use el repositorio de Remi: php.net advirtió que ese repositorio, mantenido por voluntarios, no tendría actualizaciones el día del lanzamiento y recomienda pasar a paquetes de la distribución o compilar desde la fuente.
4. Composer no actualiza PHP. composer update actualiza las librerías del proyecto, no el intérprete. Sí conviene revisar con composer check-platform-reqs que el proyecto siga funcionando en la versión parcheada.
5. Docker. Reconstruir las imágenes con la imagen base oficial ya parcheada (por ejemplo, php:8.4 actualizada a 8.4.27), volver a desplegar y no reutilizar imágenes en caché.
6. Hosting compartido. En el panel de control (cPanel, Plesk u otro), elegir una rama soportada y confirmar con el proveedor que ya aplicó el parche. Si el proveedor no responde, es motivo para escalar.
7. Reiniciar todos los procesos (PHP-FPM, Apache) después de actualizar, para que no quede ningún worker con código viejo.
8. Si no se puede actualizar hoy: php.net publica mitigaciones parciales, como memory_limit=-1 aplicado sin que la aplicación lo pueda cambiar, un post_max_size bajo y session.upload_progress.enabled=0, pero advierte que reducen la exposición y no hacen segura la instalación. El FBI y CERT-EU sugieren aislar de internet los sistemas expuestos hasta parchearlos.
9. Vigilar. Revisar si hay procesos de PHP que abren intérpretes de comandos (shells) o descargan archivos, algo que una web normal no hace.
10. Si hay señales de compromiso: aislar el servidor, guardar los registros del servidor web y de PHP antes de tocar nada y reportarlo. El FBI recibe reportes en https://www.ic3.gov.

En resumen

No hace falta esperar a que haya ataques confirmados: la corrección existe, es oficial y está disponible para todas las ramas soportadas. Para un sitio web pequeño, actualizar PHP suele llevar minutos; recuperarse de un servidor comprometido, mucho más.

Fuentes: aviso de seguridad de php.net (21-oct-2026); NVD (CVE-2026-109618 y CVE-2026-109619); CERT-EU Security Advisory 2026-018; FBI Cyber Division en X; catálogo KEV de CISA.