Saltar al contenido
Tecnologías emergentes en Latinoamérica y el mundoMiércoles 21 oct 2026

CiberseguridadVulnerabilidades

PHP corrige dos fallas críticas de ejecución remota y ya hay intentos de ataque

Las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 salieron a las 13:34 UTC. Cloudflare y watchTowr reportan ataques, y las ramas 8.1 y anteriores dependen de arreglos de las distribuciones.

Por Redacción LatamByte

Asistida por IA

Alerta crítica de PHP: ya salieron las versiones corregidas 8.5.12, 8.4.27, 8.3.36 y 8.2.35; las ramas 8.1, 8.0, 7 y 5 no tienen versión oficial
Imagen: LatamByte

PHP publicó este miércoles 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos fallas críticas que permiten tomar el control de un servidor web sin usuario ni contraseña. El parche salió a las 13:34 UTC, casi media hora antes de lo anunciado, según los avisos en GitHub. Eran las 10:34 en Buenos Aires, San Pablo y Santiago, las 9:34 en Caracas, las 8:34 en Bogotá y Lima, y las 7:34 en Ciudad de México. El equipo de PHP pide actualizar de inmediato y aclara que ningún ajuste de configuración reemplaza al parche.

Los datos de las fallas, CVE-2026-109618 y CVE-2026-109619, se habían filtrado el martes, como contó LatamByte. Ahora el aviso de seguridad de PHP confirma los dos identificadores, el puntaje de 9,2 sobre 10 y que el ataque puede ejecutar código a distancia sin autenticarse.

El error está en PHP, no en el sitio

Las dos fallas viven en el núcleo de PHP, el programa que interpreta el código de sitios hechos con WordPress, Drupal o Joomla, así que alcanzan a cualquier sitio con una versión vulnerable. La primera aparece cuando PHP se queda sin memoria en medio de una petición y deja datos internos a medio armar. La segunda deja restos de una visita anterior en memoria ya liberada, y la siguiente puede tropezar con ellos.

Uno de los caminos de ataque pasa por el registro del progreso de subidas de archivos, session.upload_progress, como sugería un rumor previo al parche. PHP ve el riesgo mayor en los servidores Apache con mod_php, donde demostró un ataque que arranca con una petición sin autenticar, antes de que corra el código del sitio. La segunda falla también se validó contra PHP-FPM, la configuración más común con Nginx.

Las encontró la empresa Wiz, junto con Calif y OpenAI, con ayuda de inteligencia artificial. Wiz dijo que tomó el control de WordPress, Drupal y Joomla sin credenciales y que el código vulnerable existe desde PHP 5.4, de 2012.

Intentos de ataque, sin intrusiones probadas

El estado hoy es de intentos reportados. Cloudflare protege por defecto a sus clientes desde las 03:02 UTC y vio tráfico de ataque que cambiaba para esquivar sus reglas. La empresa watchTowr las marca como explotadas según su red de señuelos, servidores falsos que atraen atacantes.

Otras fuentes ven menos. Patchstack recibió a las 07:34 UTC avisos de empresas de alojamiento sobre incidentes, pero a las 13:57 UTC su propia telemetría solo mostraba sondeos, sin pruebas de intrusiones. Huntress no detectó ataques en sus clientes hasta las 14:00 UTC. A las 14:04 UTC, las fallas no figuraban en el catálogo de fallas explotadas de la agencia de ciberseguridad de Estados Unidos (CISA). La diferencia está en qué cuenta cada uno. Una petición maliciosa es un intento, y hasta la tarde nadie mostró un servidor real tomado.

Desde la madrugada hay en GitHub al menos dos repositorios que dicen contener código de ataque, y CERT-EU confirmó que circulan pruebas iniciales. Tenable advirtió que no verificó que funcionen y que pueden esconder programas maliciosos.

La gravedad también tiene matices. Red Hat calificó la primera falla como "importante", un escalón debajo de crítica, porque en sus sistemas PHP corre con PHP-FPM y considera el ataque difícil en la práctica. Los avisos de PHP coinciden en que con FPM no se demostró un ataque completo de esa falla, pero sí de la segunda.

Las versiones viejas, con arreglos a medias

Las ramas 8.1 y anteriores siguen sin versión oficial, pero el equipo de PHP publicó arreglos mínimos en código fuente para 7.4, 8.0 y 8.1, pensados para quien compila por su cuenta. Para PHP 5 y las 7 anteriores a la 7.4 no hay nada.

Las distribuciones de Linux recibieron el parche por adelantado. Ubuntu ya corrigió sus versiones 22.04, que usa PHP 8.1, 24.04, 26.04 y 26.10, y Debian sus versiones 12 y 13. Red Hat no tenía paquetes corregidos a media tarde, y el repositorio Remi, muy usado en servidores Red Hat, AlmaLinux y Rocky, no tendrá actualizaciones hoy.

Esos arreglos importan en la región. Según el conteo de Mallory del martes, el 88 % de los servidores de Argentina que muestran su versión, unos 12.700, corre PHP 8.1 o anterior, igual que el 73 % en México y el 64 % en Brasil. A las 15:30 UTC, LatamByte no encontró avisos en los sitios de CERT.br, ColCERT, CERT.uy ni BA-CSIRT.

Actualizar primero lo expuesto

Quien administra un sitio tiene que instalar hoy PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, según su rama, empezando por los servidores expuestos a internet. En Debian 12 el paquete corregido es 8.2.35-1~deb12u1, en Debian 13 8.4.27-1~deb13u1, en Ubuntu 24.04 8.3.6-0ubuntu0.24.04.13 y en Ubuntu 22.04 8.1.2-1ubuntu2.28. Después hay que reiniciar Apache o PHP-FPM para que tome la versión nueva. En alojamiento compartido, hay que pedírselo al proveedor.

Si no se puede actualizar ya, PHP propone medidas que reducen el riesgo sin eliminarlo, como desactivar session.upload_progress.enabled, fijar memory_limit=-1, bajar post_max_size a 8 megabytes y, en PHP 8.5, poner fatal_error_backtraces=0, reiniciando todos los procesos. Si ni eso es posible, el Centro Nacional de Ciberseguridad del Reino Unido recomienda sacar el sistema de internet. Huntress sugiere vigilar si los procesos de PHP lanzan intérpretes de comandos o herramientas como curl y wget.

Sansec mantiene su pronóstico de explotación masiva. Cada hora sin parche juega para el atacante.

Ficha técnica

Contexto (1 término)
catálogo de vulnerabilidades explotadas conocidas (KEV)
Lista pública de la Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA) que reúne vulnerabilidades con evidencia de explotación activa, para que se prioricen al corregir.

Glosario de LatamByte

Vulnerabilidades

Fuentes