PHP2Shell en México: qué nos dicen los escáneres y qué falta comprobar He estado viendo cuentas publicar cifras sobre sobre sitios y servicios mexicanos afectados por PHP2Shell. La alerta merece atención, pero también debemos dimensionarla sin adelantarnos a las conclusiones: una versión antigua detectada no confirma, por sí sola, que un servidor sea explotable o haya sido comprometido. Vamos a tomar como ejemplo Shodan, un buscador de servicios expuestos en Internet. Sus resultados no son una comprobación en vivo de cada servidor al momento de consultar: el buscador principal muestra las observaciones más recientes de cada IP y puerto recopiladas durante los últimos 30 días, aunque la plataforma indica que rastrea Internet al menos semanalmente. Las consultas históricas por IP pueden mostrar hasta 90 días; las tendencias de varios años corresponden a otro producto. Un resultado podría describir el servicio antes de una actualización o un cambio de exposición. Si después deja de responder o restringe el acceso, esa observación anterior no permite conocer su estado actual. No significa que Shodan esté fallando: sus datos deben interpretarse junto con su fecha y alcance. Pero una observación reciente tampoco resuelve todo. Aunque la versión anunciada siga siendo la misma, el paquete podría contener correcciones de seguridad. Aquí entra el backporting. Consiste en adaptar una corrección a una versión anterior del software. El proveedor modifica el código y distribuye un paquete corregido, procurando conservar compatibilidad. La versión base puede mantenerse aunque el defecto ya esté reparado. Red Hat explica que ignorar estos parches puede generar falsos positivos en herramientas de seguridad que únicamente comparan números de versión. Por eso, Shodan u otro escáner pueden identificar correctamente una versión anunciada y aun así, esa información resultar insuficiente para confirmar vulnerabilidad. El falso positivo puede aparecer al interpretar “versión antigua” como “defecto sin corregir”, sin verificar los paquetes del proveedor. Un backport busca reducir los cambios, pero no elimina la necesidad de hacer pruebas. Si aparecen incompatibilidades, pueden requerirse ajustes en la aplicación o sus dependencias. Que una actualización provoque un fallo no significa que el sitio nunca pueda funcionar con ella: requiere identificar la causa y evaluar la adaptación necesaria. Para CVE-2026-109618 y CVE-2026-109619 hay ejemplos concretos: Ubuntu publicó 8.5.4-0ubuntu1.5 para Ubuntu 26.04 LTS. Conserva la base 8.5.4, pero esa revisión incluye las correcciones de ambos CVE. No significa que cualquier PHP 8.5.4 esté corregido: importan el proveedor y el identificador completo del paquete. PHP también publicó excepcionalmente backports mínimos de código fuente para 7.4, 8.0 y 8.1, ramas que ya estaban fuera del soporte del proyecto PHP. Esto no restablece su mantenimiento general. Cuando no existe un paquete preparado por un proveedor, construir, probar y mantener esa corrección requiere un equipo capacitado. Esto importa tanto en escaneos externos como internos: si una comprobación solo compara versiones, puede desconocer un backport. Trivy documenta el uso de paquetes y avisos del proveedor para reducir esos falsos positivos. Su cobertura depende del objetivo y del método de análisis; no verifica cualquier instalación ni garantiza reconocer parches personalizados. En los grupos monitoreados de ciberdelincuencia de LATAM, aún no he visto evidencia verificable de explotación exitosa en producción. En mis pruebas aisladas, algunos PoC sí funcionan, pero dependen de condiciones específicas que dificultan reproducirlos en otros entornos. Eso no significa que producción esté protegida ni que no existan casos fuera de lo que he observado. La actualización también debe contemplar la compatibilidad de la aplicación. Corregir estos defectos exige que el motor PHP utilizado por el servicio tenga el parche, pero puede ser necesario actualizar o adaptar el CMS, framework, plugins o dependencias para mantener el sitio funcionando. WordPress recomienda preparar sus componentes antes de actualizar PHP; Laravel publicó instrucciones específicas para actualizar sus entornos. Son tareas relacionadas, aunque cada una actúa sobre una capa distinta. PHP2Shell requiere atención y corrección. Pero antes de convertir una cifra de escaneo en miles de servidores explotables, revisemos fechas, paquetes, revisiones, parches y que el servicio ejecute la corrección. Ni dramatizar cada versión detectada ni descartar hallazgos como falsos positivos sin comprobarlos. Por eso, Shodan u otro escáner pueden identificar correctamente una versión anunciada y, aun así, esa información puede resultar insuficiente para confirmar que el servicio es vulnerable. Fuentes: Shodan: help.shodan.io/mastery/data_… Red Hat: access.redhat.com/security/u… Ubuntu: lists.ubuntu.com/archives/ub… PHP: php.net/archive/2026.php#202… Trivy: trivy.dev/docs/latest/scanne… WordPress: wordpress.org/support/update… Laravel: laravel.com/blog/php-critica… Vídeo de: @SocketSecurity