Cómo comprobar si tus aplicaciones autohospedadas usan una versión vulnerable de PHP

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Conceptual guide: CHECK THE RUNNING PHP. Identify service; Inspect runtime; Verify vendor fix.

Un host puede ejecutar varias versiones de PHP a la vez. La versión que devuelve un shell SSH puede pertenecer a una herramienta de línea de comandos, mientras que un sitio web público usa otro entorno de ejecución. Para evaluar las vulnerabilidades de PHP de octubre de 2026, vincula cada resultado de versión con una aplicación y un servicio reales.

Comprueba el entorno que sirve la aplicación, no solo el PHP de línea de comandos del host. Compara la rama exacta del entorno de ejecución o la revisión del paquete de la distribución con el aviso correspondiente, teniendo en cuenta las correcciones retroportadas documentadas por el proveedor, y elimina cualquier página de diagnóstico temporal después de la comprobación.

1. Identifica las aplicaciones que usan PHP

Enumera las aplicaciones, los métodos de instalación y las vías de acceso externas. Consulta la documentación de la aplicación o los metadatos del paquete para determinar si usa PHP. Incluye servicios auxiliares, como los ejecutores de cron y las colas, cuando utilicen la misma imagen de la aplicación.

No deduzcas el uso de PHP a partir de la marca del NAS. Un dispositivo que ejecuta una combinación de aplicaciones requiere una evaluación por servicio.

2. Inspecciona una implementación de Compose

docker compose ps
docker compose images
docker compose exec -T app php -v
docker compose exec -T app php --ini

Ejecuta estos comandos desde el directorio del proyecto de Compose previsto; sustituye app por el servicio que contiene PHP. Los comandos identifican los contenedores actuales y consultan el binario dentro de ese servicio. Si PHP se ejecuta en un servicio independiente php o fpm, inspecciona ese servicio.

Que no exista un ejecutable php no demuestra que la aplicación sea segura. Las imágenes mínimas, las rutas de binarios alternativas o los servicios de ejecución independientes pueden requerir el método de inspección del responsable del mantenimiento. No instales paquetes en un contenedor de producción solo para completar una comprobación de versión.

3. Inspecciona el PHP instalado en el host

command -v php
php -v
php --ini

Estos describen el PHP del shell. A continuación, revisa la configuración del servidor web y el gestor de servicios para identificar el grupo de PHP-FPM, el módulo de Apache u otro controlador que sirve el sitio. Comprueba la versión del paquete de ese componente y el aviso del proveedor. La documentación de PHP indica que las ubicaciones y el comportamiento de la configuración varían según la interfaz del servidor.

Si un panel proporciona información privada sobre el entorno de ejecución del servicio web real, puede complementar el inventario. No dejes una página pública de phpinfo() en línea; puede revelar detalles ajenos a esta comprobación.

4. Compara las pruebas con el aviso de seguridad

Para el incidente del 21 de octubre, las versiones de seguridad oficiales son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Una versión posterior con soporte de la misma rama puede incluir esas correcciones. Si una distribución aplica parches de seguridad retroactivos, usa la revisión de su paquete y su aviso de seguridad, en lugar de aceptar o rechazar un paquete basándote únicamente en el número que parece corresponder a la versión oficial.

Registra uno de estos tres estados: corrección confirmada, afectación confirmada o pendiente de resolución a la espera de pruebas del proveedor. Para software que ya no tiene soporte, establece una actualización a una versión con soporte o una corrección explícita de un proveedor que lo mantenga. El estado pendiente de resolución debe seguir visible en tu lista de mantenimiento.

5. Confirma qué ocurre después de la actualización

Repite las mismas comprobaciones después de la implementación, incluidos los contenedores y procesos de trabajo independientes. Registra el identificador de la imagen o la revisión del paquete y el estado del reinicio. Prueba una solicitud autenticada normal y las funciones que realmente usa tu hogar.

En un ZimaCube 2 de nube personal, guarda este registro junto con la configuración de la aplicación y las instrucciones de copia de seguridad. El resultado útil es una declaración rastreable como «esta aplicación usa este entorno de ejecución con los parches aplicados», en lugar de «el NAS se actualizó». Si encuentras un contenedor afectado, consulta la guía de actualización enlazada antes de modificar sus volúmenes de datos.

Descubre ZimaCube 2 NAS en la nube personal para el hogar para tu configuración de almacenamiento privado y aplicaciones autohospedadas. La seguridad del software depende de los servicios instalados, su configuración y las actualizaciones verificadas.

Continúa la serie sobre seguridad de PHP

Fuentes y alcance

Verificado el 22 de octubre de 2026. Las recomendaciones de implementación deben ajustarse a la aplicación y a la documentación del proveedor; estos artículos no determinan la exposición específica de un producto.