PHP: fallas críticas permiten ejecutar código remoto sin autenticación

Qué está pasando

El proyecto PHP publicó el 21 de octubre de 2026 las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades críticas. Ambas permiten ejecución remota de código sin autenticación. Según el boletín, un exploit demostrado logra el ataque con una sola petición, antes de que se ejecute cualquier código de la aplicación. Los detalles técnicos ya se discuten en público y circulan pruebas de concepto iniciales, lo que aumenta la probabilidad de que se estén explotando.

CVE-2026-109618 se origina en cómo PHP maneja la falta de memoria. Cuando una petición supera el límite de memory_limit, PHP la aborta de golpe y puede dejar datos internos a medio inicializar, por ejemplo mientras procesa la subida de un archivo desde un formulario. Luego, al limpiar, intenta liberar memoria que puede contener datos controlados por el atacante. CVE-2026-109619 ocurre porque cierto estado interno de una petición puede sobrevivir después de liberada su memoria, por ejemplo tras un error fatal. Una petición posterior atendida por el mismo proceso puede usar ese estado obsoleto.

Está en riesgo toda instalación de PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera que mod_php es la configuración de mayor riesgo. También pueden verse afectados productos comerciales y de código abierto que usan PHP internamente, aunque no expongan una instalación de PHP de forma directa.

El 23 de octubre se reveló una tercera falla, CVE-2026-115560, que también podría permitir ejecución remota de código. Por ahora no hay detalles técnicos. Según PHP, solo afecta a aplicaciones configuradas de forma poco habitual y no habrá una versión fuera de calendario para corregirla. Hasta la próxima versión regular, la protección recomendada es desactivar session.upload_progress.enabled.

Vulnerabilidades

Productos afectados

Qué hacer ahora

1. Actualiza de inmediato todas las instalaciones de PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según la rama que uses, y verifica qué versión quedó instalada con php -v en cada servidor.
2. Si usas los paquetes de tu distribución Linux o de un proveedor LTS, consulta con ellos por los paquetes actualizados, porque recibieron los parches por adelantado.
3. Si tienes PHP 8.1 o anterior, pide a tu distribución o proveedor LTS los parches portados o migra a una versión con soporte. Si compilas desde el código fuente, aplica los parches mínimos que publicó PHP para 7.4, 8.0 y 8.1.
4. Si usas rpms.remirepo.net, cambia a los paquetes de tu distribución o compila desde el código fuente, porque ese repositorio no tendrá actualizaciones el día del lanzamiento.
5. Desactiva session.upload_progress.enabled (valor 0) en php.ini, en el pool de FPM o en la configuración del servidor, y reinicia todos los workers. Así te proteges de CVE-2026-115560 hasta la próxima versión regular.
6. Revisa qué productos de terceros que usas incluyen PHP internamente, con ayuda del repositorio de NCSC-NL (github.com/NCSC-NL/php2shell).
7. Si no puedes actualizar de inmediato, aísla de las redes públicas las aplicaciones expuestas a Internet hasta aplicar y verificar el parche.

Si no puedes actualizar de inmediato

Medidas temporales: reducen la exposición, pero no reemplazan la actualización.

• Estas medidas reducen la exposición pero no hacen segura la instalación; solo la actualización corrige las fallas.
• CVE-2026-109618: define memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo (por ejemplo, con php_admin_value en el pool de FPM o en Apache). Verifica también que ningún pool, directorio o aplicación vuelva a fijar un límite finito.
• CVE-2026-109618: usa un post_max_size bajo (8M si la aplicación no necesita subir archivos, 32M si los necesita) y mantén upload_max_filesize por debajo de post_max_size.
• CVE-2026-109618: limita en el servidor web o proxy el tamaño de la petición decodificada, la cantidad de campos, las partes multipart, los encabezados y la profundidad de anidamiento. Esos límites también deben cubrir las peticiones sin un Content-Length utilizable.
• CVE-2026-109618: usa un límite de memoria de contenedor o cgroup que, idealmente, termine solo el worker afectado. No uses RLIMIT_AS ni RLIMIT_DATA, porque pueden provocar la falla vulnerable.
• CVE-2026-109619: define session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor, y reinicia todos los workers. No uses ini_set() ni .user.ini de FPM para esto.
• CVE-2026-109619: en PHP 8.5, define fatal_error_backtraces=0 y reinicia todos los workers.
• CVE-2026-109619: elimina configuraciones por petición inválidas u obsoletas que generen diagnósticos antes de la inicialización. Ocultarlos con error_reporting, display_errors o @ no sirve.
• CVE-2026-109619: corrige los errores fatales y los tiempos de ejecución agotados que un atacante pueda provocar, incluidos los de callbacks, procesamiento de subidas o importaciones y limpieza.

Cómo te ayuda UpTech

Referencias

1. https://www.php.net/archive/2026.php#2026-10-20-1
2. https://cyberplace.social/@GossiTheDog/117474220875882526
3. https://x.com/watchtowrcyber/status/2112611507749982605
4. https://www.php.net/index.php#2026-10-20-1
5. https://github.com/NCSC-NL/php2shell
6. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
7. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
8. https://thehackernews.com/2026/10/urgent-php-warns-of-another-unpatched.html