> ## Content Index > Fetch the complete content index at: https://bullquill.com/llms.txt > Use this file to discover other available public pages before exploring further. # PHP fija parches de emergencia para dos fallos críticos: qué hacer - URL: https://bullquill.com/es/php-emergency-security-patches-what-to-do-es/ - Published: 2026-10-21T06:37:32.000Z - Updated: 2026-10-21T12:44:27.000Z - Description: El equipo de seguridad de PHP anunció por adelantado una versión urgente que corrige dos vulnerabilidades con una puntuación de 9.2 en CVSS v4.0. Esto es lo que está confirmado oficialmente, lo que sigue sin verificarse y cómo pueden prepararse los operadores de servidores. - Author: Rowan Ashby - Tags: Tech, Trending, #lang-es, #tr-php-emergency-security-patches-what-to-do ## Puntos clave - El equipo de seguridad de PHP programó una versión de seguridad fuera de ciclo para el miércoles 21 de octubre de 2026 a las 14:00 UTC con el fin de corregir dos vulnerabilidades, cada una con una puntuación de 9.2 (Crítica) en la escala CVSS v4.0. - PHP afirma que podría publicar las correcciones antes si los detalles técnicos se hacen públicos o si hay pruebas de explotación activa. Las versiones afectadas y las corregidas solo se indicarán cuando se publique la versión. - CERT-EU identifica los fallos como CVE-2026-109618 y CVE-2026-109619 y señala que podrían permitir la ejecución remota de código. No se ha divulgado oficialmente ningún detalle técnico. - Varios investigadores han vinculado al menos uno de los fallos con la función `session.upload_progress` de PHP, activada de forma predeterminada. PHP no lo ha confirmado, y desactivar esa opción es una medida provisional no oficial que quizá no cubra ambos fallos. - Actualmente solo PHP 8.2, 8.3, 8.4 y 8.5 reciben correcciones de seguridad. No se espera que los servidores con ramas más antiguas reciban parches oficiales. ## Qué anunció el proyecto PHP El martes 20 de octubre de 2026 a las 19:33 UTC, el gestor de versiones de PHP Jakub Zelenka publicó un aviso en la lista de correo oficial del proyecto, php.announce, titulado "Upcoming Critical PHP Security Release". El aviso indica que la versión abordará "dos vulnerabilidades críticas (ambas con CVSS v4.0 9.2, Crítica)" y fija la hora de publicación a las 14:00 UTC del miércoles 21 de octubre de 2026. El anuncio es breve. No menciona las ramas afectadas, los componentes vulnerables ni ninguna solución alternativa. Pide a los usuarios que se preparen ya para actualizar en cuanto la versión esté disponible y advierte que el equipo se reserva el derecho de publicarla antes si los detalles se filtran aún más o si los atacantes empiezan a explotar los fallos. El mismo aviso previo aparece en la portada de php.net, que indica que las versiones afectadas y corregidas se enumerarán junto con la publicación. Anunciar por adelantado una versión de seguridad es poco habitual en PHP. Sus actualizaciones de seguridad ordinarias suelen publicarse con poca difusión previa. Las más recientes llegaron el 24 de septiembre de 2026 como PHP 8.5.11, 8.4.26, 8.3.35 y 8.2.34\. Un aviso aparte con una hora fija indica que los mantenedores esperan una respuesta rápida y amplia de los operadores de servidores. ## Por qué el aviso llegó antes Según las cronologías publicadas por las empresas de seguridad Sansec y Huntress, una publicación en el foro Hacker News hacia las 15:20 UTC del 20 de octubre describía dos próximas divulgaciones de ejecución remota de código en PHP. La publicación se eliminó después, pero circularon capturas de pantalla. Huntress y Sansec informan de que la empresa de seguridad watchTowr confirmó que los fallos eran reales, y Huntress afirma que watchTowr reprodujo uno de ellos, CVE-2026-109618\. Sansec informa de que la fecha programada se adelantó un día respecto a lo previsto inicialmente. El servicio de ciberseguridad de la UE para sus instituciones, CERT-EU, emitió el Security Advisory 2026-018 sobre los dos CVE. Afirma que "podrían permitir la ejecución remota de código" y que las puntuaciones apuntan a una posible explotación sin autenticación. CERT-EU añade que todavía no hay detalles técnicos públicos. ## Qué versiones y funciones podrían estar afectadas Esta es la mayor incógnita, y la respuesta oficial solo llegará con la publicación. Esto es lo que dicen las fuentes hasta ahora: - **PHP (oficial):** las versiones afectadas y corregidas se publicarán junto con la versión. - **CERT-EU:** citando otra fuente, afirma que los fallos podrían afectar a todas las versiones de PHP desde PHP 5. - **Sansec:** afirma que una captura filtrada de una herramienta de explotación llamada "PHP2Shell" asegura funcionar contra todas las versiones desde PHP 5.4.0\. Esa afirmación procede del propio banner de la herramienta y no se ha verificado de forma independiente. - **Huntress:** señala que los informes apuntan a PHP 5 a 8, pero que no se ha publicado la causa raíz. Prevé correcciones solo para las ramas de PHP 8 con soporte. En cuanto al componente concreto, el sitio japonés de noticias de seguridad Lilting ha recopilado análisis de investigadores que vinculan al menos uno de los fallos con el controlador de `session.upload_progress`, descrito como un heap use-after-free. Se trata de un tipo de error de corrupción de memoria en el que un programa sigue usando memoria después de liberarla. Un investigador independiente sitúa el error en la función `php_session_rfc1867_callback` y afirma que el segundo fallo está en otro lugar, en el analizador de solicitudes multipart. GMO Flatt Security, también citada por Lilting, advierte de que su propio análisis podría contener imprecisiones. Ninguna de estas atribuciones ha sido confirmada por el proyecto PHP ni por CERT-EU, por lo que conviene considerarlas provisionales. La función de progreso de carga de sesión permite a PHP registrar cuánto de un archivo subido ha llegado, para que una página web pueda mostrar una barra de progreso. Según el manual de PHP, `session.upload_progress.enabled` tiene como valor predeterminado "1" (activado) y puede modificarse por directorio (`INI_PERDIR`). Eso significa que no puede desactivarse desde dentro de una aplicación con `ini_set()`. ## Las cifras: ramas de PHP y exposición | Elemento | Valor | Fuente | | ------------------------------------------------------------------- | ----------------------------------------- | -------------------------- | | Gravedad de cada fallo | CVSS v4.0 9.2 (Crítica) | PHP php.announce #509 | | Publicación programada | 21 oct 2026, 14:00 UTC | PHP php.announce #509 | | PHP 8.5 (última 8.5.11) | Soporte de seguridad hasta el 31 dic 2029 | php.net supported versions | | PHP 8.4 (última 8.4.26) | Soporte de seguridad hasta el 31 dic 2028 | php.net supported versions | | PHP 8.3 (última 8.3.35) | Soporte de seguridad hasta el 31 dic 2027 | php.net supported versions | | PHP 8.2 (última 8.2.34) | Soporte de seguridad hasta el 31 dic 2026 | php.net supported versions | | Sitios web con lenguaje del lado del servidor conocido que usan PHP | 69,3 % | W3Techs, 21 oct 2026 | | Proporción de sitios PHP en PHP 7 / PHP 5 | 27,0 % / 7,7 % | W3Techs, 21 oct 2026 | Las cifras de W3Techs importan porque aproximadamente un tercio de los sitios con PHP de su estudio funcionan con PHP 7 o PHP 5\. Esas ramas dejaron de recibir correcciones oficiales hace años. Si los fallos alcanzan realmente versiones tan antiguas, esos sitios no recibirán un parche del proyecto PHP. ## Qué deben hacer ahora los administradores de servidores La única solución oficial es instalar la versión corregida de PHP una vez publicada. Hasta entonces, las indicaciones de PHP, CERT-EU, Huntress y Sansec se resumen en los siguientes pasos. 1. **Inventariar todas las instalaciones de PHP.** Huntress subraya que PHP suele venir integrado en dispositivos de proveedores, paneles de control de alojamiento y paquetes de CMS, y no solo instalado como paquete independiente. 2. **Prepararse para parchear primero los sistemas expuestos a internet.** Vigile la portada de php.net y la lista php.announce para conocer los números de versión corregidos. Si depende de paquetes de una distribución Linux, consulte el sistema de seguimiento de seguridad de su distribución, porque las correcciones retroportadas pueden tener números de versión distintos. 3. **Hablar con el proveedor de alojamiento.** Sansec señala que la corrección se aplica a nivel de servidor y no puede hacerse desde el código de la aplicación, así que los propietarios de tiendas en Magento, Shopware o WooCommerce que no gestionan sus propios servidores deberían pedir a su proveedor que aplique la actualización en cuanto esté disponible. 4. **Resolver el PHP sin soporte.** Huntress aconseja actualizar, desconectar o restringir detrás de una VPN o un firewall de aplicaciones web cualquier servidor con PHP 5, 7, 8.0 u 8.1\. CERT-EU recomienda aislar las aplicaciones expuestas a internet si no es posible parchear con rapidez. 5. **Valorar con cuidado la medida provisional no oficial.** Varios investigadores sugieren establecer `session.upload_progress.enabled = 0` en `php.ini`, `.user.ini` o la configuración del servidor web. La subida de archivos sigue funcionando; solo se detiene el seguimiento del progreso. No es una recomendación de PHP, y al menos un investigador afirma que solo bloquea uno de los dos fallos. 6. **Vigilar señales de compromiso.** Huntress cita al investigador de detección Florian Roth, quien prevé que la explotación se manifieste como "procesos hijo sospechosos generados por PHP". Es decir, procesos de PHP como php-fpm o apache2 que lanzan shells o herramientas de descarga. Si se sospecha una intrusión, aísle el servidor y conserve los registros web y de PHP antes de limpiarlo. ## Lo que aún se desconoce Según la información pública más reciente antes de la publicación programada, PHP no había dado a conocer las versiones afectadas, la causa raíz ni ninguna solución alternativa oficial. Huntress afirmó que no había observado explotación real en los entornos de sus socios hasta el 20 de octubre, y no se conocía código de explotación público. Sansec prevé que los ataques masivos comiencen unos 15 minutos después de la publicación, una estimación y no una observación. Tampoco se ha confirmado si los fallos pueden activarse sin autenticación ni en qué configuraciones de servidor (mod\_php, PHP-FPM, CGI). ## Qué significa PHP es el lenguaje del lado del servidor detrás de la mayor parte de la web, incluidas plataformas de gestión de contenidos y de comercio electrónico de uso extendido, por lo que un fallo explotable a distancia en el propio PHP podría tener un alcance muy amplio. A diferencia de un error en un plugin, no puede corregirse actualizando una sola aplicación. Cada servidor debe actualizarse a nivel del entorno de ejecución. El aviso previo da a los operadores un margen estrecho para organizar el mantenimiento y contactar con sus proveedores de alojamiento. El mayor riesgo a largo plazo está en la gran cantidad de sitios que siguen en versiones de PHP sin soporte, que podrían seguir expuestos después de hoy si no se actualizan o se protegen. Los administradores deberían considerar las notas oficiales de la versión de PHP, y no las filtraciones ni las afirmaciones en redes sociales, como la referencia autorizada sobre qué está afectado y qué se ha corregido. ## Preguntas frecuentes ### ¿Cuándo se publicarán las correcciones de seguridad de PHP? El equipo de seguridad de PHP programó la publicación para el miércoles 21 de octubre de 2026 a las 14:00 UTC y señaló que podría adelantarla si los detalles se hacen públicos o se detecta explotación. ### ¿Qué versiones de PHP están afectadas? PHP aún no ha indicado las versiones afectadas; dice que las enumerará junto con la publicación. Informes de terceros sugieren que podrían estar afectadas versiones desde PHP 5, pero no está confirmado. Actualmente solo PHP 8.2 a 8.5 reciben correcciones de seguridad. ### ¿Desactivar session.upload\_progress protege mi servidor? Es una medida provisional no oficial sugerida por investigadores, no una recomendación de PHP. Al menos un investigador afirma que solo bloquea uno de los dos fallos, por lo que instalar la versión oficial corregida sigue siendo la única solución confirmada. ### ¿Cuáles son los identificadores CVE? CERT-EU registra las vulnerabilidades como CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9.2 en la escala CVSS v4.0. ### ¿Qué hago si mi servidor usa una versión antigua de PHP? Las empresas de seguridad aconsejan actualizar a una rama con soporte, o restringir el acceso detrás de una VPN o un firewall de aplicaciones web, porque no se espera que las versiones sin soporte reciban correcciones oficiales. ## Fuentes - [PHP php.announce #509: Upcoming Critical PHP Security Release (20 Oct 2026)](https://news-web.php.net/php.announce/509?ref=bullquill.com) - [PHP.net front page: news and security announcements](https://www.php.net/?ref=bullquill.com) - [PHP.net: Supported versions](https://www.php.net/supported-versions.php?ref=bullquill.com) - [PHP manual: Session runtime configuration](https://www.php.net/manual/en/session.configuration.php?ref=bullquill.com) - [PHP manual: Session upload progress](https://www.php.net/manual/en/session.upload-progress.php?ref=bullquill.com) - [CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018/?ref=bullquill.com) - [Huntress: Rapid Response, php2shell leaked critical PHP vulnerabilities](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities?ref=bullquill.com) - [Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619](https://sansec.io/research/php2shell?ref=bullquill.com) - [Lilting: Disabling session.upload\_progress before the php2shell patch lands](https://lilting.ch/en/articles/php2shell-session-upload-progress-uaf?ref=bullquill.com) - [W3Techs: Usage statistics of PHP for websites](https://w3techs.com/technologies/details/pl-php?ref=bullquill.com)