Comprobador PHP2Shell

1. Por qué comprobar PHP2Shell aunque no exista un formulario de carga

La vulnerabilidad PHP2Shell no es un fallo de un único complemento de CMS ni de una pantalla de carga. Afecta al propio PHP, al procesamiento de las peticiones y a la gestión de estado. Inventaría todos los puntos PHP expuestos, las SAPI utilizadas, las extensiones, el tratamiento de errores y los archivos de configuración efectivos. El inicio de sesión o la verificación CSRF pueden ejecutarse después de que el entorno haya procesado partes de la petición. Por eso, ni la ausencia de una función visible de carga ni la falta de un marcador concreto demuestran seguridad.

multipart/form-data y session.upload_progress ayudan a entender algunas vías de PHP2Shell. Sin embargo, los avisos oficiales describen dos problemas: corrupción al limpiar después de un agotamiento de memoria y estado global que permanece entre peticiones. Bloquear un solo campo POST no implica corregir ambos. Verifica si el paquete instalado contiene las dos correcciones completas. Incluye en la comprobación las revisiones de distribución, las adaptaciones del proveedor y la procedencia de las imágenes de contenedor.

2. Desactivar el progreso de carga: efecto y limitaciones

PHP puede registrar en la sesión el progreso de una carga en curso. session.upload_progress.enabled = Off desactiva esa función y reduce la superficie de una vía de sesión relevante. El procesamiento habitual de $_FILES es independiente: no equivale a desactivar todas las cargas de archivos. Aun así, las barras de progreso propias, las consultas periódicas, los complementos y las transferencias grandes pueden depender de esta función. Prueba la publicación de medios y los flujos completos de negocio antes de desplegar el cambio en todos los servidores.

La opción debe aplicarse a la SAPI web, no solo a la terminal. Los grupos FPM y los contenedores pueden cargar INI distintos; después de una recarga gradual aún pueden quedar procesos antiguos. Separa la verificación de la configuración de la del binario corregido. Para solucionar PHP2Shell, todos los procesos deben ejecutar una compilación parcheada. En PHP 8.5, evalúa las opciones adicionales de arranque, como fatal_error_backtraces, junto con los avisos oficiales y las necesidades concretas de la aplicación.

Cómo solucionar PHP2Shell: parches completos frente a mitigación temporal

Compara cobertura, impacto operativo y uso en sistemas sin soporte. Selecciona una fila para ver sus límites y la configuración correspondiente. Desactivar el progreso de carga no constituye una solución completa de PHP2Shell.

3. Defensa en profundidad: combinar filtros perimetrales y parches de PHP

La respuesta a PHP2Shell combina reducción de exposición, actualización completa e investigación de incidentes. Inventaría todos los orígenes, procesos, contenedores, paneles de alojamiento y servicios en segundo plano. Comprueba permisos del WAF, límites de análisis y rutas que eviten el proxy. Observa el tráfico legítimo antes de imponer reglas más estrictas para que los falsos positivos no provoquen interrupciones innecesarias. Un despliegue gradual y verificable resulta especialmente importante cuando administras sitios de varios clientes.

Para mantener disponibilidad necesitas réplicas sanas de reserva, comprobaciones de preparación y retirada ordenada de conexiones existentes. Un restart o reload por sí solo no garantiza continuidad. Conserva un plan de reversión operativa sin volver a una versión vulnerable de PHP. Los parches evitan reutilizar los fallos corregidos, pero no eliminan puertas traseras existentes ni credenciales robadas. Preserva registros e investiga archivos, procesos hijos y conexiones salientes inesperadas. La ausencia de bloqueos o marcadores no demuestra que nunca se produjera una intrusión.