 | RCE por estado global obsoleto (*stale*) |
| **Causa** | Si PHP se queda sin memoria mientras los datos internos de la petición están a medio inicializar, la limpieza los trata como válidos | Estado interno de una petición sobrevive a la liberación de su memoria; otra petición del mismo worker lo usa antes de que se reinicie |
| **Autenticación** | No requiere | No requiere |
| **Aviso** | [GHSA-w8hw-w9fx-j79w]( | [GHSA-6wmf-4rv5-p3rp]( |
| **Publicado** | 21 de octubre de 2026 |
| **Quién está en riesgo** | Todo PHP que atienda web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed |
| **Mayor riesgo** | **mod_php**: hay exploit demostrado que dispara el ataque antes de ejecutar código de la aplicación |
> El aviso de PHP no publica rangos de versiones afectadas, solo las versiones corregidas.
| 8.2 | **8.2.35** (EOL el 31-dic-2026) |
- **PHP 8.1 y anteriores** ya no reciben parches del proyecto. Opciones: backport de tu distro/proveedor LTS, o compilar las ramas de backport del equipo de seguridad: [7.4]( [8.0]( [8.1](
- Las distribuciones recibieron los parches por adelantado: revisa tus paquetes. Debian/Ubuntu/RHEL **retroportan** el fix sin cambiar el número de versión, así que mira el changelog y no solo `php -v`.
- ⚠️ **`rpms.remirepo.net` no tendrá actualizaciones hoy.** PHP recomienda cambiar a paquetes de la distribución o compilar desde fuente.
### Opción A — Script automático (recomendado)
Ejecución rápida (descarga y corre en un paso):
curl -fsSL | sudo bash
O descárgalo primero para revisarlo antes de ejecutarlo:
curl -fsSLO
Funciona con `sh` o `bash`. Si `bash` no existe, el script lo instala con el gestor de paquetes (apt, dnf, yum, apk, zypper o pacman) y se relanza solo; es lo único que instala. Del resto solo lee: no modifica configuración de PHP.
1. **Qué PHP atiende peticiones:** php-fpm, php-cgi, FrankenPHP, LiteSpeed y si Apache tiene `mod_php`.
2. **Versiones instaladas:** busca todos los binarios PHP y los compara con las versiones corregidas; también busca el CVE en el changelog de la distro (backports).
3. **Mitigaciones temporales:** `memory_limit`, `post_max_size`, `session.upload_progress.enabled`, `fatal_error_backtraces` y overrides en pools FPM/Apache.
4. **Reinicio pendiente:** workers que siguen usando archivos reemplazados.
| `2` | No se pudo confirmar, hay que revisar a mano |
php -v # versión del CLI (puede diferir de la del web)
php-fpm -v 2>/dev/null # versión de FPM
apachectl -M 2>/dev/null | grep -i php # ¿mod_php cargado?
pgrep -a 'php-fpm|frankenphp|lsphp' # procesos PHP activos
zgrep -iE "CVE-2026-10961[89]" /usr/ /doc/php*-common/changelog.Debian.gz
rpm -q --changelog php-common | grep -iE "CVE-2026-10961[89]"
> El CLI y el servicio web pueden ser **versiones distintas**. Revisa cada una y cada pool de FPM.
### 1. Actualizar (única solución completa)
sudo apt update && sudo apt install --only-upgrade 'php*' 'libapache2-mod-php*'
# RHEL / Rocky / Alma / Fedora (paquetes de la distro, no Remi hoy)
Después **reinicia** el servicio web (`php-fpm`, `apache2`/`httpd`, LiteSpeed, FrankenPHP) y vuelve a correr el script. Actualizar el paquete no basta si los workers viejos siguen en memoria.
### 2. Si NO puedes actualizar hoy: reducir exposición
> **Esto no hace seguro al servidor.** Solo cierra rutas de ataque conocidas. Actualiza en cuanto puedas.
- `memory_limit=-1`, preferentemente donde la app no pueda cambiarlo (`php_admin_value`). Verifica que ningún pool, directorio o app restaure un límite finito.
- `post_max_size` bajo y `upload_max_filesize` menor que él:
post_max_size = 8M ; sin subidas de archivos
; post_max_size = 32M ; si necesitas subidas
- Limitar en el servidor web o proxy: tamaño decodificado del cuerpo, número de campos, partes multipart, cabeceras y profundidad de anidamiento. Debe cubrir también peticiones **sin `Content-Length`** utilizable.
- Usar un límite de contenedor/cgroup como frontera de disponibilidad, idealmente matando solo al worker afectado.
- ❌ **No uses `RLIMIT_AS` ni `RLIMIT_DATA`** (`ulimit -v` / `-d`): pueden provocar justo la falla de asignación vulnerable.
**Para CVE-2026-109619 (estado obsoleto)**
- Desactivar el progreso de subida de sesión y reiniciar **todos** los workers. Hazlo en `php.ini`, pool FPM o configuración del servidor, que apliquen antes de procesar la petición. **No** sirve `ini_set()` ni `.user.ini` de FPM.
- Solo PHP 8.5: bloquea la ruta confirmada de backtrace en errores fatales y reinicia workers.
- Eliminar ajustes por petición inválidos u obsoletos que emitan avisos antes de la inicialización. Ocultarlos con `error_reporting`, `display_errors` o `@` **no ayuda**.
- Corregir errores fatales y timeouts de ejecución alcanzables por un atacante (callbacks, procesamiento de subidas/importaciones, limpieza).
sudo systemctl restart php8.4-fpm apache2 # ajusta a tus servicios
No hay IOCs públicos (hashes, dominios, IPs) en el aviso. La detección es **por comportamiento**:
# Caídas de workers (segfault, OOM) en los últimos 30 días
journalctl --since "-30d" | grep -iE "php.*(segfault|killed process|out of memory)|oom-kill.*php"
# Errores fatales / agotamiento de memoria en logs de PHP-FPM
grep -riE "Allowed memory size|Out of memory|child .* exited on signal" /var/log/php* /var/log/apache2 /var/log/httpd 2>/dev/null | tail -n 50
- Workers PHP que terminan por señal (`SIGSEGV`, `SIGABRT`) de forma repetida.
- Peticiones con cuerpos enormes, muchos campos/partes multipart o sin `Content-Length`.
- Procesos hijos inesperados de `php-fpm`/`apache2` (shells, `curl`, `wget`) o archivos `.php` nuevos en directorios escribibles.
> Si sospechas explotación, trata **el servidor completo como comprometido**: preserva logs y memoria, revisa webroots por archivos nuevos o modificados, rota credenciales y secretos que PHP pudiera leer.
> Revisamos su servidor contra las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 de PHP, publicadas el 21 de octubre de 2026. Permiten que una persona sin cuenta ejecute código en el servidor enviando peticiones web especialmente construidas.
> Su servidor usa PHP en una versión sin la corrección, por lo que **es vulnerable**. La solución es actualizar PHP a la versión corregida y reiniciar el servicio web; mientras tanto aplicamos ajustes que reducen la exposición, pero que no sustituyen la actualización.
| `check-php-cve-2026-109618.sh` | Script de detección (Bash, sin dependencias) |
- [PHP.net — Security advisory: Critical RCE vulnerabilities (21-oct-2026)](
- [GHSA-w8hw-w9fx-j79w — CVE-2026-109618](
- [GHSA-6wmf-4rv5-p3rp — CVE-2026-109619](
- [PHP — Descargas](
**Autor:** [Álvaro Guzmán]( ·
*Información vigente al 21 de octubre de 2026.*
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
