Cómo confirmar que tu hosting aplicó un parche de seguridad de PHP
Pide evidencia del paquete corregido, del entorno que cubre y de los procesos actualizados. Un mensaje de mantenimiento o un número de versión aislado no bastan.
Para confirmar un parche de PHP necesitas relacionar el aviso de seguridad con el paquete o imagen instalado y con los procesos que ejecutan tu web. Una comunicación del hosting que diga actualizado puede referirse a una parte de su infraestructura y no aclarar la situación de tu cuenta.
Esta guía se centra en la evidencia de la corrección. Para identificar primero el entorno, consulta qué versión de PHP utiliza realmente una web.
Pedir confirmación para las instalaciones concretas
Indica dominios, aplicaciones y modalidades de hosting que quieres revisar. Pregunta qué paquete o imagen incorpora la corrección, qué aviso lo respalda y cuándo se aplicó en esas instalaciones.
Incluye subdominios y aplicaciones antiguas que aún reciban tráfico. Una actualización del servicio principal no demuestra que una cuenta con otra rama de PHP esté cubierta. Si el proveedor no administra un contenedor propio, su actualización del sistema puede no afectar a ese contenedor.
Entender qué significa un backport
Un backport incorpora una corrección en una base de software anterior sin adoptar necesariamente todas las características de una versión nueva. Ubuntu describe este enfoque en su documentación de actualizaciones de seguridad.
Por eso un número base aparentemente antiguo no demuestra por sí solo que falte un parche. Tampoco permite darlo por aplicado: hay que comprobar el paquete completo y el alcance de soporte de la distribución o proveedor.
La evidencia útil relaciona vulnerabilidad, distribución, revisión corregida e instalación efectiva. La frase tiene soporte extendido no sustituye esa correspondencia para un fallo concreto.
Separar disponibilidad, instalación y ejecución
Que un paquete esté disponible no significa que se haya instalado. Que esté instalado tampoco demuestra que todos los procesos hayan dejado de ejecutar el intérprete anterior.
Solicita confirmación de reinicio o sustitución de los procesos afectados y revisa instancias, pools y contenedores según el despliegue. La comprobación debe cubrir los destinos que pueden atender tráfico, no solo el servidor al que se conectó el administrador.
Para PHP2Shell, el aviso oficial distingue paquetes del proyecto y actualizaciones del proveedor. Utiliza la referencia aplicable a tu instalación, sin tratar una mitigación de tráfico como si fuera el parche del intérprete.
Conservar evidencia sin publicar configuración sensible
Guarda fecha, respuesta del proveedor, revisión instalada y resultado de las comprobaciones. Puede bastar un registro técnico redactado para ese alcance; no necesitas publicar capturas completas del panel o un diagnóstico de configuración accesible a cualquiera.
Si el proveedor gestiona PHP, la validación puede combinar su confirmación con información autenticada del entorno y pruebas de la aplicación. Si administras el servidor, conserva además el origen del paquete o imagen y el despliegue realizado.
Probar la aplicación después del parche
Verifica acceso, formularios y funciones críticas. En una tienda, incluye el recorrido de pedido en un mecanismo de prueba adecuado; en Moodle, cursos, archivos y tareas relevantes. La prueba funcional no demuestra por sí sola que el parche exista, pero permite detectar efectos operativos del cambio.
El resultado debe distinguir versión verificada, funciones probadas y pendientes. Si algo falla, sigue el recorrido de diagnóstico después de actualizar PHP antes de realizar cambios adicionales.
Qué hacer si la respuesta del proveedor no es suficiente
Pide una aclaración concreta y asigna un responsable al seguimiento. Si no hay corrección disponible para tu servicio, evalúa actualización de rama, adaptación de código o traslado a un entorno mantenido. Las restricciones temporales de acceso deben coordinarse según exposición y criticidad.
Podemos revisar esa evidencia dentro de la actualización de PHP, coordinar servidores Linux o comprobar compatibilidad mediante mantenimiento WordPress. No se requiere ejecutar un exploit contra producción para documentar que se aplicó el paquete corregido.