Un NAS para acceso remoto, un puerto de contenedor publicado o una pasarela abierta temporalmente hace tiempo: estos servicios se olvidan con facilidad. Ante PHP2Shell importan tres preguntas: qué es accesible, qué entorno procesa las peticiones web y a qué otros sistemas puede acceder ese servicio.
Los dos primeros artículos explican la situación de seguridad de PHP y nuestra respuesta y el apoyo de la IA para revisar el inventario. Aquí abordamos las comprobaciones prácticas para empresas y particulares que administran un NAS. Una marca no sustituye un inventario. Tampoco un firmware actualizado demuestra que todos los paquetes y contenedores en ejecución estén al día.
PHP2Shell afecta al entorno que realmente atiende las peticiones web
CVE-2026-109618 y CVE-2026-109619 pueden permitir ejecutar código antes de autenticarse en la aplicación; ambas tienen una puntuación CVSS v4.0 de 9,2. El proyecto PHP publicó el 21 de octubre de 2026 las versiones corregidas 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Los proveedores pueden ofrecer paquetes propios con correcciones adaptadas a versiones anteriores. Por ello, lo determinante es el aviso correspondiente, no solo el número de versión.
Una página de inicio de sesión no garantiza protección en este caso. Hay que comprobar el intérprete que procesa realmente las peticiones web, incluidos los procesos activos. Una versión actualizada de PHP en la línea de comandos no basta para acreditarlo. Esto se aplica tanto a servidores web convencionales como a entornos incluidos en aplicaciones, dispositivos e imágenes.
La exposición pública va más allá del reenvío de puertos
El inventario debe incluir IPv4 e IPv6, reglas del router, UPnP, nombres DDNS, destinos del proxy inverso, túneles y accesos remotos intermediados por la nube. En cada caso hay que determinar la ruta real: una IP pública no es por sí misma una aplicación vulnerable. Tampoco un servicio de retransmisión del fabricante implica automáticamente la misma vía de ataque. En cambio, una regla olvidada puede exponer un servicio pensado para uso interno.
Incluya sitios web, CMS, portales de clientes, paneles de alojamiento e interfaces de copias de seguridad, monitorización y administración. Lo mismo vale para plataformas NAS, VoIP, cámaras, impresoras y sistemas de control. Los dispositivos sin un componente PHP relevante no quedan afectados automáticamente por estas dos CVE. Aun así, conviene revisar su accesibilidad pública.
Synology: separar sistema operativo y paquetes
Synology limita la afectación a determinados paquetes dependientes de PHP, como Web Station, WordPress, Calendar y MailStation. El comunicado del 22 de octubre anuncia actualizaciones de paquetes PHP para DSM 7.4, 7.3 y expresamente DSM 7.2, aunque esta última versión ya alcanzó el fin de su vida útil. Para versiones anteriores de DSM, recomienda desactivar temporalmente los paquetes afectados.
PHP se actualiza mediante el Centro de paquetes; MailStation necesita además una actualización manual del paquete. El aviso no indica una corrección para el paquete PHP 7.3 de Synology. Según el fabricante, el PHP interno de DSM presenta una exposición distinta y no dispone de módulos accesibles desde el exterior. También importan los nombres: IDrive es un paquete de terceros y no es Synology Drive; el comunicado identifica Synology Drive como no afectado.
En instalaciones no oficiales de DSM mediante XPEnology hay que evaluar por separado el dispositivo, el cargador, DSM y los paquetes. No constituyen un sistema Synology completo con soporte ordinario. Eso no implica que nunca puedan actualizarse ni que todas sean vulnerables. Sin embargo, la incertidumbre sobre su mantenimiento justifica limitar el acceso directo desde internet y planificar una operación con actualizaciones fiables.
QNAP: comprobar el estado actualizado
Desde su actualización del 24 de octubre, el aviso QNAP QSA-26-18 recoge correcciones para varias ramas de QTS, QuTS hero y QuTScloud. Otras aplicaciones indicadas siguen en estado «Fixing». Ni «QNAP aún no tiene parche» ni «todo está resuelto» describen correctamente la situación. Hay que identificar el producto concreto, su rama y la versión corregida correspondiente. Una actualización del sistema QNAP no repara automáticamente el PHP de aplicaciones de terceros o contenedores propios.
En los contenedores hay dos preguntas distintas
Primera: ¿está corregido el entorno del contenedor en ejecución? Actualizar el host no sustituye una imagen antigua. La imagen base, los paquetes adicionales y el despliegue activo deben concordar. Descargar una imagen nueva solo ayuda cuando el servicio se vuelve a desplegar con ella y supera las pruebas funcionales.
Segunda: ¿qué permisos y rutas de red tiene el servicio? Las redes bridge de Docker permiten normalmente conexiones salientes; los contenedores de una misma red bridge pueden comunicarse entre sí. Los destinos internos accesibles dependen, entre otras cosas, del enrutamiento y del cortafuegos. Un contenedor comprometido no toma automáticamente el control de toda la LAN. Sin embargo, credenciales compartidas, montajes innecesarios del host, privilegios adicionales o un socket de Docker expuesto pueden ampliar mucho las consecuencias. Las redes separadas, las reglas de salida específicas y los permisos mínimos deben verificarse en la práctica.
Siete comprobaciones para la próxima ronda de trabajo
- Inventariar accesos: documentar dispositivos, aplicaciones, puertos publicados y servicios intermediarios, con sus responsables. Incluir IPv6 y aperturas temporales olvidadas.
- Identificar entornos: registrar sistema, paquetes, complementos y PHP web por servicio. Revisar avisos del proveedor y estado de mantenimiento.
- Corregir y verificar: instalar actualizaciones o imágenes adecuadas, reiniciar correctamente los servicios afectados y comprobar la versión realmente activa.
- Reducir la exposición: cerrar accesos públicos de administración innecesarios. Una VPN o una red de administración de confianza pueden limitar el acceso; las actualizaciones siguen siendo necesarias detrás de ellas.
- Probar rutas y permisos: limitar el acceso a bases de datos, NAS, copias y administración a lo necesario. Cambiar las reglas de forma controlada y verificar después las aplicaciones legítimas.
- Revisar indicios y recuperación: evaluar accesos, cuentas y conexiones salientes anómalas. Mantener copias independientes protegidas frente a cambios no autorizados y restauraciones probadas; las instantáneas por sí solas no bastan.
- Seguir las excepciones: documentar los sistemas sin corrección disponible, con responsable, medida provisional y plan de sustitución o retirada.
Un parche no cierra automáticamente la investigación del incidente
Sophos remite a un intento de explotación observado por Amazon Threat Intelligence el 17 de octubre, antes del anuncio público. En sistemas realmente expuestos, la evaluación debe incluir la actividad anterior. Una actualización satisfactoria no demuestra que antes no hubiera acceso no autorizado. Si hay indicios sospechosos, corresponde gestionar el incidente de forma ordenada, preservando las evidencias y realizando una recuperación controlada.
Además, desde el 23 de octubre PHP señala otro caso poco frecuente que depende de la configuración del seguimiento de carga en las sesiones. Los avisos actuales del fabricante siguen siendo relevantes después de la primera actualización. Modificar configuraciones de forma general sin conocer las consecuencias operativas no es un buen atajo.
Lo que no necesite ser público debería permanecer inaccesible desde internet hasta su revisión. Eso reduce la superficie de ataque, pero no sustituye la corrección. DAXS ayuda a identificar servicios, priorizar medidas y comprobar su eficacia de manera trazable. Hablemos de su entorno concreto.
Fuentes: PHP: avisos de seguridad y versiones corregidas · ENISA: identificar aplicaciones PHP y limitar su exposición · Synology: paquetes afectados y versiones de DSM · Synology-SA-26:14 · QNAP QSA-26-18: correcciones por producto · Docker: propiedades de las redes bridge · Sophos: exposición, actividad e investigación de incidentes · NCSC-NL: dependencias de PHP · Red Hat: entornos y correcciones adaptadas.
