# Proteger por su cuenta un servidor root y un vServer > Proteger un vServer tras PHP2Shell: compruebe los paquetes PHP, detecte backports, reinicie todos los procesos y refuerce el servidor root de forma duradera. Fuente: https://phpsos.de/es/server/root-server-vserver/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** quien administra por su cuenta un servidor root o un vServer debe también protegerlo por su cuenta tras PHP2Shell: llevar los paquetes de PHP a un estado corregido, reiniciar todos los procesos PHP y comprobar el resultado. El operador del centro de datos, por lo general, solo se ocupa del hardware, la virtualización y la red. Después, merece la pena reforzar el servidor de forma duradera. ## Su responsabilidad con un servidor propio Con un servidor root o un vServer no gestionado, usted alquila potencia de cálculo, no mantenimiento. El sistema operativo, el servidor web, PHP, la base de datos, el cortafuegos, las copias de seguridad y la supervisión están en sus manos. Para la dirección y los propietarios, eso significa: si nadie en la empresa o en un proveedor de servicios ha asumido expresamente estas tareas, no las hace nadie. PHP2Shell lo pone de manifiesto. Las dos vulnerabilidades CVE-2026-109618 y CVE-2026-109619 están en el propio PHP y permiten ejecutar código sin autenticación. El proyecto PHP publicó el 21/10/2026 las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El BSI (Oficina Federal Alemana de Seguridad de la Información) recomienda actualizar de inmediato y, si no es posible, desconectar temporalmente el servidor web de la red. ## Proteger un vServer: comprobar inventario y estado de los paquetes Empiece por hacerse una idea de qué versiones de PHP están instaladas y de qué fuente proceden. Muchos servidores usan, además de los paquetes de la distribución, repositorios adicionales. Los comandos siguientes solo leen. Los nombres de los paquetes son ejemplos. ```bash # Debian/Ubuntu: paquetes PHP instalados y su procedencia apt list --installed 'php*' 2>/dev/null apt-cache policy php8.3-fpm # AlmaLinux/Rocky/RHEL dnf list installed 'php*' # ¿Qué binarios de PHP existen en total? ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null ``` El número de versión por sí solo no basta. Las distribuciones suelen entregar las correcciones de seguridad como backport y el número mostrado se queda entonces más antiguo. Lo decisivo es el registro de cambios del paquete. ```bash # Debian/Ubuntu (nombre del paquete a modo de ejemplo) apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)' # Familia RHEL (nombre del paquete a modo de ejemplo) rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)' ``` Encontrará una guía detallada en [Comprobar la versión de PHP y el estado del parche](https://phpsos.de/es/php2shell/php-version-pruefen/). ## Instalar la actualización y renovar todos los procesos Instale las actualizaciones con el gestor de paquetes y reinicie después cada servicio que cargue PHP. Según la arquitectura, son PHP-FPM, Apache con mod_php, LiteSpeed o un servidor de aplicaciones. Los archivos nuevos en el disco no bastan mientras sigan en memoria procesos antiguos. ```bash # Encontrar los servicios con PHP systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws' # Mostrar los procesos con su hora de inicio ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep # Debian/Ubuntu: detectar programas con bibliotecas obsoletas (si está instalado) needrestart -r l ``` Todo proceso relevante debería haberse iniciado después de la actualización. En sistemas Debian es útil la herramienta `needrestart`, que muestra los servicios con bibliotecas obsoletas. Los detalles del reinicio se describen en [Reiniciar PHP-FPM y todos los procesos de trabajo](https://phpsos.de/es/php2shell/php-fpm-neustart/). > **Importante:** > Un parche no elimina el software malicioso que se haya introducido antes de la actualización. Conserve los registros del servidor web desde el 20/10/2026 y busque rastros en el servidor antes de darlo por limpio. Para una primera búsqueda de rastros hay algunas comprobaciones que no modifican nada. Busque archivos PHP creados o modificados desde el 17/10/2026 en los directorios web, entradas desconocidas en los crontabs de todos los usuarios, nuevos usuarios del sistema y claves SSH, así como procesos del usuario del servidor web que mantengan conexiones salientes. ```bash # Archivos PHP modificados desde el 17/10/2026 (ruta a modo de ejemplo) find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls # Conexiones de red con su proceso asociado ss -tupn ``` Ninguna de estas comprobaciones prueba por sí sola una intrusión, y un resultado vacío no prueba lo contrario. Pero indican si hace falta una investigación más a fondo. Trabaje sobre copias de los registros y no modifique archivos sospechosos hasta haber asegurado el estado. Si hay hallazgos, lo más seguro es una investigación ordenada. En ese caso, no apague el servidor sin más ni lo reinstale de inmediato, porque así se pierden rastros que son importantes para valorar las obligaciones de notificación y una posible denuncia. ## Reforzar el servidor de forma duradera Tras el parche urgente viene la protección básica. No evita todas las vulnerabilidades, pero limita el daño y acorta el tiempo de reacción la próxima vez. Estos puntos han demostrado su eficacia: - **Accesos:** SSH solo con clave, sin inicio de sesión directo como root, interfaces de administración accesibles solo desde redes conocidas. - **Cortafuegos:** abrir solo los puertos que realmente se necesitan y limitar las conexiones salientes del servidor web. - **Configuración de PHP:** desactivar las funciones peligrosas, `open_basedir` por sitio web, pools y usuarios propios por aplicación. - **Permisos de archivos:** el servidor web no puede escribir en el código del programa y los directorios de cargas no ejecutan PHP. - **Actualizaciones:** instalar automáticamente las actualizaciones de seguridad y planificar de forma fija el reinicio y el control. - **Copias de seguridad:** copias según la regla 3-2-1, con al menos una copia fuera del servidor y protegida frente a modificaciones. - **Registros:** recopilar los registros de forma centralizada y conservarlos durante el tiempo suficiente. Cómo es una copia de seguridad fiable se describe en [Copias de seguridad según la regla 3-2-1](https://phpsos.de/es/ratgeber/backups-3-2-1/). Como marco para empresas es adecuado el IT-Grundschutz (protección básica de TI) del BSI. ## Cuándo es mejor un servidor gestionado Un servidor propio compensa si alguien asume el mantenimiento de forma fiable: seguir las actualizaciones, valorar situaciones como PHP2Shell, poder reaccionar por la noche. Si falta esa capacidad, tiene sentido un servidor gestionado o un contrato de mantenimiento fijo. En ambos casos es importante dejar las responsabilidades por escrito. Más información en [Servidor gestionado: aclarar la responsabilidad](https://phpsos.de/es/server/managed-server/). ## ¿Cómo ayuda PHP SOS en concreto? - Registramos todas las instalaciones de PHP, los repositorios de paquetes y los servicios de su servidor y valoramos el estado real del parche. - Instalamos las actualizaciones, reiniciamos todos los procesos y documentamos el resultado. - Revisamos el servidor en busca de rastros de un compromiso y conservamos los registros para un análisis posterior. - Dentro de nuestro [refuerzo de servidores](https://phpsos.de/es/leistungen/server-haertung/) configuramos correctamente los accesos, el cortafuegos, los pools de PHP y los permisos. - Si lo desea, asumimos el mantenimiento continuo mediante un [contrato de mantenimiento de seguridad](https://phpsos.de/es/leistungen/security-wartungsvertrag/). ## Preguntas frecuentes **¿Parchea automáticamente mi centro de datos el vServer?** En los servidores root y vServer no gestionados, por lo general no. El proveedor pone a disposición el hardware o la virtualización y la red; el sistema operativo y todos los servicios que corren en él los administra usted. En caso de duda, revise su contrato. **¿Bastan las actualizaciones de seguridad automáticas?** Ayudan, pero no sustituyen al control. Las actualizaciones automáticas no siempre reinician los procesos PHP en ejecución y a menudo no cubren los paquetes de fuentes externas. Tras cada actualización de seguridad compruebe el estado de los paquetes y las horas de inicio de los procesos. **¿Cómo averiguo si mi paquete incluye un backport?** En el registro de cambios del paquete y en los avisos de seguridad de su distribución. Si figura el número CVE, la corrección está incluida aunque el número de versión parezca más antiguo. Si falta la entrada, aclare el estado antes de dar el servidor por parcheado. **¿Qué hago si no llega ningún parche para mi versión de PHP?** PHP 8.1 y anteriores ya no reciben actualizaciones oficiales. Aplique las medidas provisionales de php.net, planifique con rapidez el cambio a una versión compatible y, si hace falta, desconecte temporalmente el servidor de la red, según la recomendación del BSI. ## Fuentes - [php.net: avisos de seguridad](https://www.php.net/) - [Registro de cambios de PHP 8](https://www.php.net/ChangeLog-8.php) - [php.net: versiones compatibles](https://www.php.net/supported-versions.php) - [BSI IT-Grundschutz (protección básica de TI)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)