PHP2Shell: qué hacer si no puedes parchear tu servidor y cómo detectar una intrusión

Actualizado: 21 de octubre de 2026.

Respuesta rápida: si tu web ejecuta una versión vulnerable de PHP, actualiza cuanto antes a una versión corregida ofrecida por tu proveedor. Las versiones publicadas el 21 de octubre son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si no puedes aplicar el parche de inmediato, reduce la exposición pública y consulta al proveedor de hosting o al equipo de seguridad. Después de actualizar, comprueba si hay señales de intrusión: instalar el parche no demuestra por sí solo que el servidor no haya sido comprometido antes.

Las vulnerabilidades críticas conocidas como PHP2Shell han elevado la prioridad de la actualización de servidores PHP. Los avisos oficiales describen dos fallos, CVE-2026-109618 y CVE-2026-109619, con una puntuación CVSS 4.0 de 9,2. En determinadas condiciones, un atacante remoto sin autenticación podría llegar a ejecutar código. El problema afecta a la capa que procesa las peticiones web, por lo que no basta con revisar WordPress, Joomla o Drupal como si el intérprete PHP fuese un componente más de la aplicación.

1. Identifica la versión real de PHP que procesa la web

Empieza por el panel de tu hosting y revisa la versión asignada al dominio o al sitio concreto. En alojamientos con varios dominios, PHP puede configurarse por separado para cada uno; comprobar una instalación no confirma que todas estén protegidas. Si tienes acceso al servidor, verifica también los servicios que atienden peticiones web, incluidos PHP-FPM, Apache con mod_php, CGI o LiteSpeed, según la arquitectura que utilices.

No publiques un archivo phpinfo() accesible desde Internet como método de comprobación: puede revelar rutas, módulos y configuración interna. Si necesitas esa información, utiliza las herramientas del panel, la consola autenticada o pide al proveedor una confirmación por escrito. El dato relevante es la versión que realmente está sirviendo las peticiones, no la versión que aparece instalada en un entorno de pruebas.

2. Aplica la versión corregida adecuada

El aviso oficial de PHP del 21 de octubre enumera estas versiones corregidas:

• PHP 8.5: 8.5.12.
• PHP 8.4: 8.4.27.
• PHP 8.3: 8.3.36.
• PHP 8.2: 8.2.35.

Solicita al proveedor que actualice el runtime asignado a tu sitio o realiza el cambio desde el panel si tienes permisos y un procedimiento probado. Haz primero una copia de seguridad verificable de archivos y base de datos, registra la versión anterior y comprueba compatibilidad de plugins y temas. La copia de seguridad no sustituye al parche: es una medida de recuperación por si la actualización provoca una incompatibilidad.

PHP indica que no existe una mitigación completa que sustituya a instalar una versión corregida. Desactivar la visualización de errores, cambiar error_reporting o añadir el operador @ no corrige el fallo del intérprete. Tampoco debes asumir que un firewall de aplicaciones web elimina el riesgo por completo.

3. Si no puedes actualizar hoy, reduce la exposición

Escala el problema al hosting y solicita una hora concreta de actualización. Si la corrección no está disponible, pregunta por una medida temporal de aislamiento: restringir el acceso público, colocar el servicio detrás de controles de acceso apropiados o detener temporalmente la aplicación expuesta si el riesgo lo justifica. La medida exacta depende de si se trata de una web pública, un portal interno, una tienda o un servicio crítico.

Un apagado preventivo puede evitar que una aplicación vulnerable siga aceptando peticiones, pero también puede interrumpir servicios legítimos. Documenta quién autoriza el cambio, qué sistemas dependen de la web y cómo se recuperará el servicio. No mantengas una web expuesta solo porque el sitio “parece funcionar”: la ausencia de errores visibles no indica que sea segura.

4. Comprueba si hay señales de compromiso

Después de aplicar el parche, revisa los registros de acceso web, errores del servidor, autenticaciones del panel, cambios en archivos y procesos inesperados. Busca actividad anómala alrededor del periodo en que la versión vulnerable estuvo expuesta, sin limitar la búsqueda a una sola ruta o a un nombre de archivo conocido. Si no tienes experiencia forense, evita borrar archivos sospechosos o limpiar registros antes de conservar una copia para el análisis.

Entre las señales que merecen revisión están archivos PHP nuevos o modificados en directorios donde no deberían existir, cuentas administrativas desconocidas, cambios de configuración no autorizados, tareas programadas extrañas, tráfico saliente inusual y accesos anómalos a bases de datos. Ninguna señal aislada prueba por sí sola una intrusión; el objetivo es comparar los hallazgos con una línea base y con los cambios legítimos del equipo.

5. Si sospechas una intrusión, trata el caso como un incidente

Informa al proveedor y al responsable de seguridad. Conserva registros, marcas de tiempo y una copia del sistema afectado; limita el acceso desde redes públicas si el equipo técnico considera que sigue habiendo riesgo. Desde un dispositivo limpio, rota credenciales que pudieran haberse expuesto, empezando por hosting, SSH/SFTP, panel de WordPress, bases de datos y claves de despliegue. Revisa también tokens de API y secretos almacenados en archivos de configuración.

No te limites a cambiar la contraseña de WordPress si un atacante pudo ejecutar código en el servidor: podría haber creado persistencia, robado credenciales o modificado archivos. La recuperación debe incluir la causa raíz, la comparación con versiones limpias, la revisión de usuarios y claves, y una monitorización reforzada tras volver a publicar la web.

6. WordPress: qué revisar además del intérprete

Actualiza WordPress, temas y plugins desde fuentes oficiales, elimina extensiones abandonadas que no sean necesarias y comprueba las cuentas con permisos de administrador. Aun así, recuerda que una vulnerabilidad del runtime PHP no se arregla únicamente actualizando el CMS. Puedes consultar nuestra guía principal sobre PHP2Shell y los parches de PHP para las versiones afectadas y el contexto técnico.

También conviene comprobar que las copias de seguridad están aisladas de las credenciales de producción y que la restauración se ha probado recientemente. Una copia conectada con permisos excesivos puede verse afectada durante un incidente; conserva al menos una versión recuperable fuera del entorno comprometido.

7. Cómo priorizar las próximas 24 horas

1. Ahora: inventaria dominios y versiones de PHP; abre un ticket urgente con el hosting si no puedes actualizarlos.
2. Después del parche: valida la versión efectiva, comprueba el sitio y registra la hora de corrección.
3. El mismo día: revisa logs, usuarios, archivos modificados y actividad administrativa.
4. Si hay indicios: activa respuesta a incidentes y no borres evidencias.
5. Esta semana: define responsables, alertas y un proceso de actualización de seguridad con plazos claros.

Preguntas frecuentes sobre PHP2Shell

¿Actualizar PHP garantiza que mi web no haya sido atacada?

No. El parche corrige las vulnerabilidades, pero no revierte una posible intrusión anterior. Revisa registros y señales de persistencia.

¿Basta con actualizar WordPress?

No. Es necesario corregir la versión del intérprete PHP que procesa las peticiones. Las actualizaciones del CMS y sus extensiones son medidas complementarias.

¿Puedo esperar al próximo mantenimiento mensual?

No es recomendable. PHP ha calificado los fallos como críticos y recomienda actualizar de inmediato. Coordina una ventana urgente y controlada.

¿Sirve ocultar los errores de PHP?

No. Ocultar mensajes al visitante no corrige el fallo interno del intérprete.

¿Qué pasa si mi hosting no ofrece las versiones corregidas?

Solicita una fecha inmediata, pregunta por aislamiento temporal y evalúa migrar a un proveedor que mantenga versiones soportadas y parches de seguridad.

¿Las versiones antiguas también están afectadas?

Las ramas antiguas fuera de soporte no reciben necesariamente correcciones oficiales. Consulta el aviso de PHP y el proveedor de tu distribución; planifica la migración en lugar de mantener una versión obsoleta expuesta.

Fuentes oficiales

• PHP.net: avisos y versiones publicadas el 21 de octubre de 2026.
• PHP Foundation: explicación de la publicación de seguridad.
• NHS England Digital: alerta sobre las vulnerabilidades críticas.
• CERT-EU: aviso de seguridad 2026-018.

Nota: esta guía es informativa y no sustituye la respuesta técnica de tu proveedor ni un análisis forense profesional. En sistemas críticos o cuando existan indicios de intrusión, activa al equipo responsable de seguridad.