# PHP2Shell, vulnerabilidades críticas en PHP y cómo proteger tu servidor - Link: https://binariocero.com/php/php2shell-vulnerabilidades-criticas-en-php-y-como-proteger-tu-servidor - Published: 2026-10-24T08:52:58+02:00 - Author: Binario 0 ![Loading](https://binariocero.com/wp-content/plugins/page-views-count/ajax-loader- 2x.gif) El 21 de octubre de 2026, el equipo de desarrollo de PHP publicó actualizaciones de seguridad para corregir dos vulnerabilidades críticas identificadas como **CVE- 2026-109618 y CVE-2026-109619**, conocidas conjuntamente como PHP2Shell. Ambas tienen una puntuación CVSS 4.0 de 9,2 sobre 10 y pueden permitir la ejecución remota de código sin autenticación en sistemas vulnerables. Puedes consultar los detalles en el [aviso oficial de seguridad de PHP](https://www.php.net/archive/2026.php). El problema afecta al propio intérprete de PHP, por lo que su alcance va mucho más allá de un gestor de contenidos concreto. Cualquier aplicación web que utilice una versión vulnerable de PHP puede estar expuesta, independientemente de si está desarrollada con WordPress, Laravel, Symfony, PrestaShop, Drupal, Joomla o código propio. En este artículo explicamos en qué consisten estas vulnerabilidades, cómo comprobar si un servidor está afectado y qué medidas aplicar para corregirlas en entornos Linux, hosting, Apache, Nginx y contenedores. ## ¿Qué son las vulnerabilidades PHP2Shell? Las vulnerabilidades PHP2Shell afectan a la gestión interna de memoria y al estado de determinadas estructuras del intérprete PHP. Los dos fallos identificados son: * **CVE-2026-109618:** un error relacionado con la gestión de situaciones de falta de memoria (_Out of Memory_ u OOM) puede interrumpir el procesamiento de una petición cuando ciertos datos internos todavía no se han inicializado correctamente. * **CVE-2026-109619:** determinados estados internos pueden conservar referencias a memoria que ya ha sido liberada, permitiendo que posteriores operaciones utilicen información obsoleta. En determinadas condiciones, estos errores pueden aprovecharse para ejecutar código de forma remota. El riesgo es especialmente importante porque un atacante no necesita disponer de una cuenta de usuario para intentar explotar el fallo. Para ampliar la información técnica, consulta el [aviso de CERT-EU sobre las vulnerabilidades críticas de PHP](https://www.cert.europa.eu/publications/security-advisories/2026-018/). Si la explotación tiene éxito, las consecuencias dependerán de los permisos del proceso PHP y de las restricciones del sistema. Entre los posibles impactos se encuentran: * Acceso a información sensible procesada por la aplicación. * Modificación o creación de archivos en el servidor. * Instalación de código malicioso. * Acceso a credenciales disponibles para el proceso comprometido. * Uso del servidor como punto de entrada para nuevos ataques. Esto no significa que todos los servidores vulnerables hayan sido comprometidos, pero sí que deben tratarse como sistemas expuestos hasta aplicar una corrección. ## ¿Qué sistemas están afectados? El problema afecta a las instalaciones de PHP que procesan peticiones web, independientemente de la aplicación que se ejecute sobre ellas. Entre los entornos que deben revisarse se encuentran: * Servidores Apache con `mod_php`. * Nginx con PHP-FPM. * Apache o Nginx que deleguen las peticiones a PHP-FPM. * Instalaciones que utilicen `php-cgi`. * Servidores LiteSpeed o FrankenPHP. * Aplicaciones PHP desplegadas mediante Docker u otros sistemas de contenedores. * Paneles de alojamiento que administren varias versiones de PHP. * Entornos de desarrollo, pruebas y producción accesibles desde redes no confiables. Según el [aviso oficial de PHP](https://www.php.net/archive/2026.php), todas las instalaciones de PHP que atienden peticiones web deben revisarse. El equipo de PHP considera especialmente arriesgadas algunas configuraciones con Apache y `mod_php`, en las que una petición puede activar la vulnerabilidad antes de que se ejecute el código de la aplicación. Por este motivo, actualizar una aplicación o instalar un complemento de seguridad no es suficiente: hay que corregir el intérprete PHP que utiliza el servicio web. ## 1. Comprobar la versión de PHP El primer paso consiste en identificar la versión que ejecuta realmente la aplicación. ### En servidores Linux Ejecuta el siguiente comando por SSH: ```wp-block-code php -v ``` Este comando muestra la versión de PHP disponible en la línea de comandos. Sin embargo, puede no coincidir con la que utiliza el servidor web. Para identificar los servicios PHP-FPM: ```wp-block-code systemctl list-units --type=service --all | grep php ``` En sistemas Debian o Ubuntu, también puedes revisar los paquetes instalados: ```wp-block-code dpkg -l | grep -E 'php[0-9]+\.[0-9]+' ``` Si utilizas Nginx, revisa la configuración del sitio para localizar la directiva` fastcgi_pass`. Esta indicará el socket o la dirección a la que se envían las peticiones PHP. Si utilizas Apache, comprueba si trabaja con PHP-FPM o con un módulo PHP integrado. ### En hosting compartido o paneles de administración Si no tienes acceso SSH, busca en el panel de alojamiento la sección de configuración de PHP. Según el proveedor, puede aparecer como «Versión de PHP», «PHP Selector» o «Configuración del lenguaje». Si no puedes consultar la versión, solicita al proveedor que confirme qué versión de PHP atiende tus aplicaciones y si ya ha aplicado las correcciones. **Importante:** no basta con comprobar la versión de PHP de una única aplicación si el servidor aloja varios sitios web. Cada sitio puede utilizar una versión o una instancia diferente. ## 2. Versiones corregidas de PHP Las versiones publicadas para corregir estas vulnerabilidades son las siguientes: | Rama de PHP | Versión corregida | | PHP 8.5 | 8.5.12 | | PHP 8.4 | 8.4.27 | | PHP 8.3 | 8.3.36 | | PHP 8.2 | 8.2.35 | Puedes comprobar estas versiones en el [archivo oficial de avisos de PHP](https://www.php.net/archive/2026.php). Si utilizas alguna de estas ramas, actualiza como mínimo a la versión indicada o a una revisión posterior que incluya las correcciones. Las ramas PHP 8.1 y anteriores ya no reciben soporte de seguridad ordinario por parte del proyecto PHP. Debes planificar la migración a una versión compatible y mantenida. Si dependes de un proveedor que ofrece parches especiales para versiones antiguas, confirma expresamente que ha aplicado las correcciones correspondientes. Ten en cuenta que algunas distribuciones Linux incorporan parches de seguridad sin cambiar la versión principal que muestran sus paquetes. Por ello, debes comprobar también los avisos de seguridad de la distribución utilizada. Puedes consultar las versiones disponibles en la página de [descargas oficiales de PHP](https://www.php.net/downloads.php). ## 3. Cómo actualizar PHP en Debian y Ubuntu En servidores propios, la actualización debe realizarse mediante el sistema de paquetes o el mecanismo de instalación que se haya utilizado originalmente. ### Paso 1. Realizar una copia de seguridad Antes de modificar PHP, guarda una copia de los archivos de las aplicaciones, sus bases de datos y las configuraciones necesarias para restaurar el servicio. Si administras un servidor de producción, planifica una ventana de mantenimiento cuando sea necesario y verifica que la copia de seguridad sea recuperable. ### Paso 2. Actualizar la información de los repositorios En Debian y Ubuntu: ```wp-block-code sudo apt update ``` Comprueba qué versiones están disponibles para la instalación actual: ```wp-block-code apt-cache policy php8.3-fpm ``` Este ejemplo corresponde a PHP 8.3-FPM. Cambia el nombre del paquete por el que realmente utilice tu servidor. Si tu aplicación utiliza paquetes de la distribución, comprueba los avisos de seguridad de esa distribución. Si utilizas un repositorio externo, verifica su procedencia y que publique los paquetes corregidos. ### Paso 3. Instalar las actualizaciones Si el repositorio configurado proporciona una actualización que incorpora las correcciones, ejecuta: ```wp-block-code sudo apt upgrade ``` Este comando actualiza los paquetes instalados que puedan actualizarse según la configuración de APT. No garantiza que se instale una versión corregida si los repositorios todavía no la ofrecen. Si necesitas migrar a otra rama de PHP, revisa previamente las extensiones, las dependencias y la compatibilidad de las aplicaciones. ### Paso 4. Reiniciar el servicio correspondiente Una vez actualizados los paquetes, verifica que el servicio PHP esté funcionando con la versión corregida. Por ejemplo, para PHP 8.3-FPM: ```wp-block-code sudo systemctl restart php8.3-fpm sudo systemctl status php8.3-fpm ``` Adapta el nombre a la versión instalada. Si Apache utiliza un módulo PHP integrado, puede ser necesario reiniciar Apache para que cargue la versión actualizada: ```wp-block-code sudo systemctl restart apache2 ``` En Nginx con PHP-FPM, actualizar o reiniciar Nginx por sí solo no corrige una versión vulnerable de PHP-FPM. Debes asegurarte de que el proceso PHP que atiende las peticiones utiliza los paquetes corregidos. ### Paso 5. Verificar el resultado Comprueba la versión de la línea de comandos: ```wp-block-code php -v ``` Después, verifica la versión efectiva utilizada por la aplicación mediante sus herramientas administrativas o mediante los mecanismos de diagnóstico disponibles en tu entorno. Si hay varias instancias de PHP instaladas, confirma que todas las que procesan peticiones web están corregidas. ## 4. Cómo actuar en Apache y Nginx La actualización de PHP debe adaptarse a la arquitectura del servidor. **Apache con** `**mod_php**`**:** actualiza el módulo PHP correspondiente y reinicia Apache cuando proceda. No presupongas que cambiar la versión de PHP CLI modifica automáticamente el módulo cargado por Apache. **Nginx con PHP-FPM:** actualiza la instancia PHP-FPM utilizada por cada sitio y comprueba que Nginx sigue apuntando al socket o servicio correcto. **Apache con PHP-FPM:** actualiza PHP-FPM y verifica la conexión entre Apache y la instancia correspondiente. **Varios sitios en un mismo servidor:** identifica qué versión utiliza cada sitio. Algunos paneles de administración permiten seleccionar una versión diferente para cada dominio. En todos los casos, después de la actualización comprueba que las aplicaciones responden correctamente, que los registros no muestran errores nuevos y que los procesos PHP activos se han sustituido cuando sea necesario. ## 5. ¿Qué ocurre si utilizas Docker? Los contenedores también deben revisarse. Actualizar PHP en el sistema operativo del servidor no actualiza automáticamente la versión incluida en una imagen de contenedor. Si utilizas una imagen oficial de PHP, revisa la etiqueta configurada en el `Dockerfile` o en el archivo de despliegue. Actualiza la imagen base a una versión corregida compatible con tu aplicación. Por ejemplo, si tu servicio utiliza PHP-FPM, la imagen elegida debe corresponder a una revisión corregida de la rama utilizada. No basta con reconstruir el contenedor si el `Dockerfile` sigue apuntando a una imagen vulnerable. Un procedimiento general sería: 1. Identificar todas las imágenes que contienen PHP. 2. Seleccionar una imagen corregida y compatible. 3. Reconstruir las imágenes de la aplicación. 4. Probar el nuevo despliegue en un entorno controlado. 5. Desplegar los contenedores actualizados. 6. Confirmar la versión PHP dentro de los contenedores en ejecución. Evita depender de etiquetas genéricas que puedan cambiar de contenido sin que quede registrada la versión exacta. Para despliegues reproducibles, documenta las imágenes utilizadas y su revisión. ## 6. ¿Y si no puedes actualizar inmediatamente? La prioridad debe ser aplicar el parche. Según el [aviso oficial de PHP](https://www.php.net/archive/2026.php), no existe una mitigación completa que sustituya a la actualización. Si no puedes actualizar de inmediato: * Contacta con el proveedor de alojamiento o con el equipo responsable del servidor. * Reduce temporalmente la exposición del servicio cuando sea viable. * Revisa los registros de acceso, errores y actividad del sistema. * Asegúrate de que las copias de seguridad estén disponibles y sean recuperables. * Planifica una actualización urgente y documenta los sistemas que continúan pendientes. Un cortafuegos de aplicaciones web, las restricciones de acceso y otras medidas defensivas pueden reducir ciertos riesgos, pero no garantizan que un intérprete vulnerable esté protegido. Si no es posible corregir un servidor expuesto a Internet, considera aislarlo temporalmente de las redes públicas hasta que la actualización se haya aplicado y verificado. Esta recomendación también aparece en el [aviso de CERT-EU](https://www.cert.europa.eu/publications/security-advisories/2026-018/). ## 7. Comprobar posibles indicios de compromiso Si el servidor estuvo expuesto a Internet mientras ejecutaba una versión vulnerable, actualizar PHP es necesario, pero no demuestra que no haya ocurrido una intrusión. En sistemas Linux, comienza revisando los registros disponibles. Algunas ubicaciones habituales son: ```wp-block-code /var/log/nginx/access.log /var/log/nginx/error.log /var/log/apache2/access.log /var/log/apache2/error.log ``` Las rutas y los nombres pueden variar según la distribución y la configuración. Busca actividad anómala, errores repetidos, peticiones sospechosas y cambios inesperados. La ausencia de una cadena concreta en los registros no descarta un ataque. También conviene revisar: * Archivos ejecutables modificados sin autorización. * Procesos y conexiones de red inesperados. * Nuevas cuentas o cambios de permisos. * Tareas programadas desconocidas. * Credenciales o claves almacenadas a las que pudiera haber accedido un atacante. * Alertas de seguridad del proveedor de alojamiento. Si encuentras indicios de compromiso, conserva las evidencias, limita el acceso al sistema y realiza una investigación antes de eliminar archivos o restaurar copias. En incidentes confirmados puede ser necesario reconstruir el servidor desde una base limpia, corregir el vector de entrada y rotar las credenciales afectadas. ## 8. Lista de comprobación para administradores Antes de cerrar la incidencia, confirma estos puntos: * He identificado todas las instancias de PHP que procesan peticiones web. * He comprobado la versión y el estado de los parches de seguridad. * He actualizado todas las instalaciones vulnerables. * He revisado las versiones utilizadas por contenedores y entornos de pruebas. * He reiniciado o sustituido los procesos PHP cuando ha sido necesario. * He verificado que las aplicaciones funcionan correctamente. * He revisado los registros si existía exposición a Internet. * He documentado las versiones corregidas y las tareas pendientes. * He confirmado que dispongo de copias de seguridad recuperables. ## Conclusión Las vulnerabilidades PHP2Shell demuestran que la seguridad de una aplicación web depende también de sus componentes subyacentes. Aunque el código de la aplicación esté actualizado, una versión vulnerable de PHP puede poner en riesgo todo el servicio. La respuesta debe comenzar por identificar las instancias afectadas, instalar las actualizaciones correspondientes y verificar que los procesos que atienden las peticiones están ejecutando la versión corregida. Si el servidor estuvo expuesto durante un periodo de vulnerabilidad, también es recomendable evaluar posibles indicios de compromiso. **Mantener PHP actualizado, controlar las dependencias y verificar cada entorno de ejecución son tareas esenciales para reducir la superficie de ataque de cualquier infraestructura web.** ### Fuentes oficiales * [PHP: aviso de seguridad del 21 de octubre de 2026](https://www.php.net/archive/2026.php) * [PHP: descargas oficiales](https://www.php.net/downloads.php) * [CERT-EU: vulnerabilidades críticas en PHP](https://www.cert.europa.eu/publications/security-advisories/2026-018/) * [ENISA: declaración conjunta sobre las vulnerabilidades críticas de PHP](https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities)