PHP2Shell requiere atención urgente: dos vulnerabilidades críticas de PHP, calificadas con 9.2 sobre 10, pueden permitir que un atacante ejecute código sin autenticarse en entornos vulnerables. Si tu sitio o aplicación utiliza PHP, solicita de inmediato la revisión de la versión que atiende las peticiones web y prioriza la instalación de los parches publicados el 21 de octubre de 2026. Aviso oficial de PHP (abre en otra pestaña).
Para una empresa, la primera decisión es identificar quién puede revisar ese motor y acreditar el cambio. Que la página abra, que tenga contraseña o que alguien haya actualizado sus contenidos no responde esa pregunta. Esta guía explica el alcance documentado y propone una forma de organizar la comprobación con el proveedor.
Las versiones que contienen la corrección
| Rama | Versiones anteriores afectadas | Primera versión corregida |
|---|---|---|
| 8.2 | 8.2.x anterior a 8.2.35 | 8.2.35 |
| 8.3 | 8.3.x anterior a 8.3.36 | 8.3.36 |
| 8.4 | 8.4.x anterior a 8.4.27 | 8.4.27 |
| 8.5 | 8.5.x anterior a 8.5.12 | 8.5.12 |
PHP 8.1 y anteriores están fuera del soporte normal del proyecto. Para esta emergencia se publicaron parches mínimos de código fuente para 7.4, 8.0 y 8.1; eso no equivale a restablecer su mantenimiento habitual. El proveedor puede ofrecer paquetes corregidos propios. Versiones, soporte y opciones oficiales (abre en otra pestaña).
La numeración exige cuidado. Ubuntu identifica, para Ubuntu 24.04 LTS, el paquete 8.3.6-0ubuntu0.24.04.13 como corregido para ambos CVE. Conserva “8.3.6” porque incorpora la solución en su paquete de distribución. Por eso hay que comparar la versión completa, el origen y el aviso del proveedor; la tabla anterior no debe usarse para descartar estos parches. Estado de CVE-2026-109618 en Ubuntu (abre en otra pestaña) y estado de CVE-2026-109619 (abre en otra pestaña).
Por qué el problema puede aparecer antes del login
Un servidor realiza trabajo antes de entregar una solicitud al código de la aplicación: recibe datos, prepara estructuras y organiza memoria. En ciertas condiciones, PHP2Shell compromete ese trabajo previo o la limpieza de una petición interrumpida. La autenticación de la aplicación puede llegar después del punto vulnerable.
CVE-2026-109618 aparece cuando un fallo de asignación de memoria interrumpe una operación con datos internos todavía incompletos. La limpieza posterior puede interpretarlos como válidos. El aviso oficial confirma ejecución remota con los permisos de la cuenta del proceso web y asigna una severidad CVSS 4.0 de 9.2. Eso no significa acceso automático como administrador del sistema. Aviso técnico del primer fallo (abre en otra pestaña).
CVE-2026-109619 permite que un proceso conserve referencias a memoria de una petición ya terminada. Cuando atiende otra, puede reutilizar ese estado antes de reinicializarlo. También tiene severidad 9.2. Sus condiciones dependen del estado retenido, de errores y de operaciones alcanzables en cada instalación. Aviso técnico del segundo fallo (abre en otra pestaña).
El seguimiento de progreso de cargas es una de las rutas implicadas. El manual de PHP explica que escribe información de sesión antes de ejecutar scripts. Esto ayuda a entender por qué cambiar una opción desde el código de la página puede ocurrir demasiado tarde. Funcionamiento del progreso de cargas (abre en otra pestaña).
Apache y PHP-FPM requieren decisiones con matices
Con Apache y mod_php, el primer aviso confirma una explotación anterior al código de la aplicación. En PHP-FPM, un fallo durante el arranque elimina el proceso hijo y corta esa secuencia concreta; el mismo aviso mantiene a FPM como susceptible por otras rutas, aunque no demuestra una explotación completa de ese primer CVE para esa modalidad. Condiciones de susceptibilidad (abre en otra pestaña).
El segundo aviso sí documenta una ruta validada en PHP-FPM: depende de una operación adecuada de la aplicación después del arranque, un error fatal y una petición posterior atendida por el mismo proceso. Usar FPM no justifica cerrar la revisión como “no aplica”. Caso validado de sesiones en FPM (abre en otra pestaña).
También deben inventariarse PHP-CGI, FrankenPHP y LiteSpeed, además de productos que incorporan PHP internamente. NCSC-NL recuerda que el alcance incluye dispositivos, interfaces de administración e imágenes de terceros, donde la actualización puede depender de su fabricante. Orientación operativa de NCSC-NL (abre en otra pestaña).
Qué demuestra el análisis de Datadog
Datadog reprodujo el primer fallo con PHP 8.5.11 y Apache. Su petición utiliza application/x-www-form-urlencoded, el formato de formularios habituales. Limitar la atención a las cargas de archivos dejaría fuera esa demostración. También observó ejecución de comandos con respuesta HTTP 200 y sin que el proceso dejara de funcionar. Son resultados de su laboratorio, no una prueba de que cualquier sitio haya sido atacado. Investigación original de Datadog (abre en otra pestaña).
Conviene separar tres preguntas: ¿la instalación contiene el defecto?, ¿existe una forma de explotarlo en sus condiciones?, ¿hay evidencia de que alguien lo hizo? El aviso de una vulnerabilidad responde principalmente la primera; una demostración aporta a la segunda; investigar una intrusión exige evidencia del entorno. Confundirlas puede producir tanto alarmismo como una tranquilidad injustificada.
Las medidas temporales tienen límites concretos
PHP indica que actualizar es la solución completa. Si no puede hacerse inmediatamente, contempla medidas para reducir rutas específicas: desactivar session.upload_progress.enabled y, en PHP 8.5, fatal_error_backtraces, con configuración temprana y reinicio de los procesos. Ninguna cubre todas las variantes. Recomendaciones temporales oficiales (abre en otra pestaña).
La propuesta de memory_limit=-1 requiere especial cuidado: elimina un límite controlable que interviene en el primer fallo, pero no impide todos los errores de asignación. Debe acompañarse de límites apropiados fuera de PHP; RLIMIT_AS y RLIMIT_DATA no son sustitutos seguros para este propósito. No es una receta para copiar sin evaluar capacidad y disponibilidad. Alcance de la mitigación de memoria (abre en otra pestaña).
El lugar donde se configura una medida importa. En FPM, los valores administrativos del pool no pueden sobrescribirse con ini_set(); son distintos de una modificación realizada por la aplicación. El responsable debe comprobar qué configuración se aplica realmente a cada servicio. Configuración oficial de FPM (abre en otra pestaña).
Un filtro web puede formar parte de la contención, pero no constituye evidencia de que el motor esté corregido. Si se necesita restringir temporalmente el acceso, la decisión debe indicar qué servicio seguirá disponible, quién autoriza el impacto y cuándo se revisará la excepción. Evita convertir una medida de emergencia en una configuración indefinida que nadie recuerda.
La ficha que puedes pedir a tu proveedor
Proponemos reunir la evidencia por sitio o aplicación, con una fila por entorno. Es una herramienta de coordinación editorial; no certifica seguridad ni sustituye el procedimiento técnico del proveedor.
| Pregunta | Evidencia que conviene recibir |
|---|---|
| ¿Qué servicio se revisó? | Dominio o aplicación, entorno y responsable. |
| ¿Qué PHP lo atiende? | Modalidad de ejecución, versión completa y origen del paquete o imagen. |
| ¿Qué corrige ambos fallos? | Aviso del proveedor que cubra CVE-2026-109618 y CVE-2026-109619. |
| ¿La corrección está ejecutándose? | Registro del cambio y comprobación de los procesos o instancias activos. |
| ¿El servicio sigue funcionando? | Resultados de acceso, formularios y operaciones acordadas. |
| ¿Quedaron excepciones? | Servicio pendiente, medida temporal, responsable y siguiente revisión. |
Por ejemplo, en un entorno hipotético con un portal y una API, una respuesta única de “servidor actualizado” puede ocultar que cada uno usa una instalación distinta. La ficha obliga a identificar ambos. El resultado útil es saber qué se comprobó y qué falta, sin exigir al responsable del negocio interpretar toda la configuración.
Datadog recomienda incluir contenedores e intérpretes empaquetados: php -v en una consola puede mostrar un PHP diferente al que atiende la web. También indica reconstruir y desplegar las imágenes afectadas y reiniciar o reemplazar los procesos antiguos. Inventario y actualización del runtime (abre en otra pestaña).
Corregir la versión e investigar actividad sospechosa son trabajos distintos
Para investigar, Datadog propone correlacionar formularios anómalos, errores de agotamiento de memoria y procesos de shell inesperados iniciados por el servidor web. Un error aislado no demuestra un ataque. La ausencia de caídas tampoco lo descarta. Señales y límites de detección (abre en otra pestaña).
Si aparecen indicios, conviene preservar registros y definir la respuesta al incidente con el responsable técnico. Instalar un parche impide volver a depender de esa versión vulnerable, pero no responde por sí solo qué ocurrió antes. El cierre debe distinguir la corrección aplicada, la revisión realizada y cualquier investigación pendiente.
Cómo ayuda la infraestructura de Acinsoft a mitigar ataques
En los dos servidores de alojamiento revisados para este artículo, las conexiones web públicas llegan primero a AcinsoftGateway, una capa de entrada implementada en .NET. Desde allí se dirigen a los servicios internos. En los entornos PHP inspeccionados, Apache utiliza PHP-FPM mediante sockets locales, dentro de espacios de ejecución separados. El recorrido observado es: Internet → AcinsoftGateway → servicio web interno → PHP-FPM.
La ventaja para los sitios alojados es contar con varias capas de protección y administración. Una solicitud puede ser rechazada en la entrada antes de consumir recursos de la aplicación; los servicios internos mantienen una separación de ejecución, y los registros permiten revisar qué decisiones tomó el filtro. Cada capa cumple una función concreta:
- Filtrar solicitudes antes de llegar a PHP. AcinsoftGateway aplica reglas sobre rutas, parámetros de URL, encabezados y métodos. Cuando una solicitud coincide con una regla de bloqueo, puede detenerse antes de llegar al servicio web interno. Esto ayuda, por ejemplo, frente a intentos de acceder a rutas restringidas y patrones de exploración reconocidos. En los registros inspeccionados encontramos rechazos efectivos por reglas de acceso a rutas.
- Limitar el tamaño de las solicitudes. Los destinos revisados tienen límites configurados para el cuerpo de las peticiones. Estos controles ayudan a restringir entradas demasiado grandes y a reducir parte del trabajo que recibe la aplicación. El tamaño de una petición y la memoria que PHP necesita para procesarla son medidas diferentes: este límite no garantiza bloquear un ataque de agotamiento de memoria ni toda variante de PHP2Shell.
- Separar la entrada pública del procesamiento PHP. Gateway recibe las conexiones web y dirige las solicitudes hacia servicios internos; PHP-FPM se comunica con Apache mediante sockets locales. La separación observada permite controlar el recorrido de las peticiones y administrar los componentes por separado. Puede contribuir a reducir la exposición y limitar el alcance de un incidente, pero comprobar esa contención exige revisar también permisos, redes y accesos entre servicios.
- Conservar señales para investigar. Los registros de Gateway permiten identificar solicitudes y reglas que las rechazaron. Al relacionarlos con los registros de la aplicación y del sistema, ayudan a evaluar actividad sospechosa y orientar la respuesta. Un rechazo aislado no demuestra un intento de explotar PHP2Shell, y la ausencia de rechazos tampoco demuestra que un servicio esté libre de ataques.
Estas capas aportan protección incluso durante la revisión de una nueva vulnerabilidad, al mantener controles sobre el tráfico que llega a los servicios. Su eficacia depende de las reglas activas y de la forma del ataque. Las firmas inspeccionadas en Gateway analizan rutas y parámetros de URL; no inspeccionan íntegramente el contenido de cada formulario POST. Por ello, no afirmamos que AcinsoftGateway bloquee todas las variantes de PHP2Shell. La protección específica frente a estas vulnerabilidades requiere instalar la corrección correspondiente de PHP y verificar que el servicio la está utilizando.
Revisar avisos y aplicar los parches disponibles
En Acinsoft revisamos las vulnerabilidades que pueden afectar a los servicios que administramos y aplicamos los parches conforme van estando disponibles para sus entornos. Esa labor requiere comprobar qué paquete corresponde a cada instalación y verificar el servicio después del cambio. La disponibilidad de una corrección del proyecto PHP y la entrega del paquete por un proveedor pueden ocurrir en momentos distintos.
Esta práctica de mantenimiento no significa que todos los entornos queden corregidos desde el primer anuncio. Ante una alerta como PHP2Shell, el estado debe comprobarse por servicio: corrección aplicada, actualización pendiente o medida temporal. El filtrado previo ayuda a gestionar la exposición, pero no debe utilizarse como motivo para posponer indefinidamente el parche.
Desde nuestro servicio de hosting e infraestructura (abre en otra pestaña) podemos delimitar contigo qué corresponde al alojamiento y qué requiere trabajo sobre la aplicación. La entrega útil conserva la versión instalada, las comprobaciones realizadas y las excepciones pendientes; no se reduce a decir que el sitio sigue abriendo.
Información verificada el 21 de octubre de 2026. Incluye avisos oficiales, investigación publicada y una inspección de sólo lectura de dos servidores de alojamiento y el servidor principal de Acinsoft. No se ejecutaron pruebas de explotación ni una auditoría completa de todos los servicios. Las observaciones arquitectónicas corresponden a los entornos inspeccionados; la práctica de mantenimiento fue confirmada por la dirección de Acinsoft. Antes de intervenir, consulta las actualizaciones del fabricante y del proveedor de tus paquetes.
