La respuesta a las vulnerabilidades de PHP requiere identificar el software que realmente atiende cada sitio, instalar las correcciones y verificar su funcionamiento. Para quienes administran Joomla, actualizar el gestor de contenidos y corregir el PHP del alojamiento son tareas diferentes que deben coordinarse con el proveedor.
Una página puede funcionar normalmente y continuar expuesta a una vulnerabilidad del servidor. También puede mostrar un gestor de contenidos actualizado mientras utiliza una versión antigua de → PHP. Por eso, la revisión frente a PHP2Shell debe comenzar por identificar la instalación efectiva y a su responsable técnico.
El → Centro Nacional de Ciberseguridad del Reino Unido recomienda inventariar los sistemas que utilizan PHP, priorizar los accesibles desde internet, vigilar actividad maliciosa y seguir los avisos de los fabricantes de productos que lo incorporan.
1. Identificar el PHP de cada sitio
En → Joomla 5, la documentación indica el acceso desde Sistema, panel de información e Información del sistema. Allí puede consultarse la versión de PHP utilizada por esa instalación, junto con otros datos del entorno.
Esa pantalla es informativa: no sustituye el panel del alojamiento ni modifica por sí misma el servidor. Además, conviene comprobar cada dominio y subdominio. Un mismo servicio de alojamiento puede mantener configuraciones distintas para el sitio principal, una tienda, una aplicación antigua o un entorno de pruebas.
La comprobación debe corresponder al PHP que procesa las solicitudes web. Consultar únicamente una herramienta de línea de comandos puede ser insuficiente si el servidor mantiene varias instalaciones. El proveedor debe confirmar qué intérprete y qué configuración utiliza efectivamente cada sitio.
2. Solicitar una confirmación técnica concreta
El pedido al alojamiento debe mencionar CVE-2026-109618 y CVE-2026-109619, y solicitar la versión o revisión del paquete corregido, la fecha de aplicación y la confirmación de que los procesos activos fueron renovados. También corresponde consultar si se revisó el aviso adicional CVE-2026-115560.
Una respuesta genérica como «el servidor está actualizado» aporta menos información que la identificación del paquete y de las correcciones aplicadas. Algunas distribuciones mantienen un número de versión anterior e incorporan el arreglo mediante un backport: una adaptación del parche a su propia rama mantenida.
El → CERT-EU señala que distribuciones y proveedores de soporte prolongado recibieron las correcciones anticipadamente. También informa sobre adaptaciones mínimas de código para determinadas ramas antiguas. Esto no restablece su mantenimiento general ni elimina la necesidad de planificar una migración.
3. Separar la corrección urgente de una migración mayor
La documentación de Joomla 5 establece PHP 8.1.0 como mínimo técnico y PHP 8.3 como versión recomendada. Pero un mínimo de compatibilidad no garantiza que esa rama siga recibiendo mantenimiento de seguridad del proyecto PHP.
Según el calendario oficial, PHP 8.2 recibe soporte de seguridad hasta el 31 de diciembre de 2026; PHP 8.3, hasta finales de 2027; PHP 8.4, hasta finales de 2028; y PHP 8.5, hasta finales de 2029. Corregir una instalación 8.2 resuelve una necesidad inmediata, pero su horizonte de soporte ya es corto.
La rama de destino debe elegirse comprobando la compatibilidad del gestor, las extensiones y la plantilla. No corresponde cambiar automáticamente a la versión más nueva sin revisar esos componentes, ni postergar un parche disponible mientras se organiza una migración más amplia.
4. Preparar respaldo y pruebas funcionales
Como procedimiento de mantenimiento, corresponde disponer de una copia de archivos y base de datos, conocer cómo restaurarla y probar los cambios en un entorno separado cuando sea posible. El respaldo permite recuperar el servicio si aparece una incompatibilidad; no protege por sí solo de una explotación.
La validación debe cubrir las funciones que sostienen la actividad: portada, artículos, ingreso al administrador, formularios, carga de imágenes, buscador y componentes de negocio. En un medio digital también conviene comprobar la edición y publicación de noticias. Una portada visible no demuestra que el resto del sistema funcione.
5. Verificar que la corrección esté en ejecución
La guía de → Google Cloud, actualizada el 23 de octubre, advierte que reemplazar paquetes en disco puede dejar procesos antiguos funcionando en memoria. Debe reiniciarse o renovarse el servicio que realmente ejecuta PHP, mediante el procedimiento correspondiente al entorno.
En contenedores puede ser necesario reconstruir la imagen y desplegarla nuevamente. La comprobación final debe confirmar tanto el paquete corregido como su utilización por los procesos que atienden tráfico.
6. Revisar el aviso complementario sobre sesiones
Para el problema adicional comunicado el 23 de octubre, PHP recomienda desactivar temporalmente el seguimiento del progreso de cargas de archivos:
session.upload_progress.enabled = 0Es una configuración del servidor PHP, no un código para pegar en un artículo, módulo o plantilla de Joomla. Debe aplicarse en la configuración efectiva y renovarse los procesos. El administrador técnico debe comprobar su impacto y seguir el próximo aviso oficial; esta medida no sustituye las correcciones de las dos vulnerabilidades iniciales.
7. Reducir exposición si todavía no es posible corregir
CERT-EU recomienda considerar el aislamiento de las aplicaciones expuestas cuando no pueda instalarse y verificarse la corrección. Esa decisión debe coordinar continuidad y seguridad: retirar temporalmente un servicio, restringir accesos o establecer una alternativa informativa son opciones diferentes.
Poner Joomla en mantenimiento no equivale necesariamente a aislar PHP de internet. Tampoco basta con proteger la pantalla de administración cuando existen vías que pueden activarse antes del código de la aplicación.
Un cortafuegos de aplicaciones web, o WAF, puede aportar una barrera adicional. Sin embargo, las protecciones tienen condiciones de cobertura y deben acompañar la actualización. Copiar cambios de memoria, sesiones o cargas desde una guía genérica sin revisar el entorno puede introducir fallos operativos y no asegura una mitigación completa.
8. Investigar lo ocurrido antes del parche
Actualizar evita que continúe abierta una vía conocida, pero no elimina una intrusión previa. Google Cloud recomienda investigar comportamientos anómalos y preservar evidencia cuando exista sospecha de compromiso. Reiniciar sin coordinación puede destruir información volátil útil para el análisis.
La revisión debe considerar solicitudes sospechosas, procesos inesperados y actividad del servidor, interpretados por personal competente. Un error aislado no demuestra un ataque; la ausencia de errores visibles tampoco prueba que el sistema esté limpio.
Para el responsable de una organización, el cierre de la intervención debería dejar un registro verificable: qué sitios se revisaron, qué correcciones recibieron, quién las aplicó, qué pruebas se realizaron y si quedaron tareas de investigación o migración pendientes. Esa trazabilidad permite pasar de una afirmación de seguridad a una comprobación documentada.
Fuentes principales
→ PHP Group. (s. f.). Supported Versions. Consultado el 24 de octubre de 2026.
→ CERT-EU. (2026, 23 de octubre). Critical Vulnerabilities in PHP. Aviso 2026-018, versión 1.2.
→ National Cyber Security Centre. (2026, octubre). Critical security issue affecting PHP.
ICI Plus – Elaboración propia a partir de fuentes verificadas. Actualizado al 24 de octubre de 2026.
Crédito de imagen: ICI Plus. Ilustración generada con inteligencia artificial; no reproduce un panel real de Joomla ni documenta una actualización efectuada.
