Cómo revisar la exposición de aplicaciones PHP antiguas
Localiza instalaciones olvidadas, revisa qué sigue accesible y asigna responsables y cobertura de parches. Prioriza mantenimiento sin confundir exposición con intrusión.
Revisar aplicaciones PHP antiguas empieza por saber cuáles siguen ejecutándose y quién responde por ellas. Una copia de pruebas, un panel bajo un subdominio o un contenedor antiguo pueden conservar exposición aunque la web principal esté actualizada.
El objetivo de esta guía es preparar un inventario y un orden de actuación. No equivale a un pentest ni permite concluir, por sí solo, que haya ocurrido una intrusión.
Inventariar más allá de la web principal
Revisa configuraciones de hosting y servidor, aplicaciones desplegadas y destinos conocidos. Incluye subdominios, staging, herramientas internas, cron y workers dentro del alcance autorizado.
Cruza las referencias con los procesos activos. Una carpeta antigua no demuestra que el servidor la publique; una URL poco utilizada tampoco demuestra que sea privada. Documenta la relación entre ruta, aplicación y entorno antes de decidir qué retirar.
Identificar accesibilidad y función
Clasifica qué servicios son públicos, cuáles requieren una barrera previa y cuáles solo son accesibles desde la red prevista. Comprueba que el comportamiento coincide con la configuración esperada.
Un login de aplicación no sustituye todas las protecciones del entorno. El aviso PHP2Shell muestra por qué la capa del intérprete también requiere revisión. Que una aplicación no tenga usuarios frecuentes no la exime del mantenimiento si sigue atendiendo peticiones.
Relacionar versiones con cobertura real
Anota intérprete, extensiones, framework o CMS y origen del paquete o imagen. Contrasta el ciclo del proyecto con la página oficial de soporte PHP y revisa aparte la cobertura documentada del proveedor.
No clasifiques un paquete únicamente por su número base ni des por hecho que una rama antigua tiene parches. La guía para confirmar un parche en el hosting explica la evidencia que conviene reunir.
Priorizar por exposición y operación
Valora qué peticiones recibe la aplicación, qué datos maneja, qué permisos tiene y qué dependencias necesita. Incluye criticidad comercial y capacidad de recuperación, además de la antigüedad del código.
Como ejemplo hipotético, un panel abandonado y público puede requerir una restricción inmediata, mientras una tarea interna activa necesita un plan de actualización compatible. La decisión depende del recorrido real, no solo de una etiqueta de versión antigua.
Asigna a cada instalación una acción: confirmar cobertura, aplicar parche, adaptar, restringir o retirar. Cada acción necesita responsable y fecha de revisión; una lista sin seguimiento no reduce por sí sola la exposición.
Tratar staging y copias con el mismo criterio
Una copia de producción puede conservar datos, credenciales o integraciones. Comprueba su acceso, separa secretos cuando corresponda y evita que envíe comunicaciones o ejecute operaciones reales durante pruebas.
Si ya no hace falta, prepara la retirada con inventario de dependencias y conservación de lo necesario. No borres una instalación por su nombre sin comprobar si sigue atendiendo una tarea o una integración.
Documentar excepciones y limitaciones
Si una aplicación no admite todavía una rama mantenida, describe el bloqueo: plugin, extensión, código o dependencia. Busca una ruta de adaptación y una cobertura temporal verificable, cuando exista. Una excepción debe revisarse, no convertirse en permiso indefinido para no actualizar.
Las medidas de red o un WAF pueden ayudar en determinados escenarios, pero no deben presentarse como equivalentes a corregir el software. Si aparecen indicios de compromiso, la investigación requiere otro alcance y manejo de evidencias.
Pasar del inventario a la continuidad
El resultado útil relaciona instalaciones, exposición, cobertura, decisiones y pruebas. Después de cada cambio, comprueba que la versión y la accesibilidad coinciden con lo acordado.
Podemos organizar la actualización de PHP, mantener el entorno dentro del soporte de aplicaciones o recuperar contexto mediante la continuación de proyectos existentes. Para el riesgo de fin de soporte, consulta también versiones EOL de PHP y Node.js.