Actualmente todos los servidores de Prosit tienen los parches de seguridad
El ecosistema de desarrollo global se encuentra bajo una alerta máxima debido a dos fallos críticos en el núcleo de PHP denominados colectivamente “PHP2Shell”, identificados como CVE-2026-109618 y CVE-2026-109619. Ambos bugs tienen una puntuación de gravedad casi perfecta de 9.2 sobre 10 en la escala CVSS. Ref: [1, 2]
Estos fallos, descubiertos inicialmente con la ayuda de herramientas de inteligencia artificial avanzada por firmas de seguridad como Wiz y OpenAI, representan una de las mayores amenazas de la década para la infraestructura web. Permiten la ejecución remota de código (RCE) sin autenticación, lo que significa que un atacante puede tomar el control total del servidor web o robar credenciales de la memoria simplemente enviando una solicitud HTTP maliciosa, sin necesidad de contraseñas.
Versiones corregidas y parches de emergencia
El equipo de seguridad de PHP liberó parches de urgencia el pasado 21 de octubre de 2026. Debes actualizar de inmediato a una de las siguientes versiones estables según la rama que utilices: Ref: 1, 2
- PHP 8.2 → Actualizar a 8.2.35
- PHP 8.3 → Actualizar a 8.3.36
- PHP 8.4 → Actualizar a 8.4.27
- PHP 8.5 → Actualizar a 8.5.12 Ref: 1
⚠️ Nota crítica: Las versiones obsoletas (como PHP 5.x, 7.x u 8.1) no recibirán parches oficiales. Si tu servidor corre en alguna de ellas, se encuentra completamente expuesto y la única solución definitiva es migrar a una rama con soporte activo. Ref: 1
¿En qué consisten estos dos bugs?
| Vulnerabilidad | Mecanismo del fallo | Impacto |
|---|---|---|
| CVE-2026-109618 (OOM Corruption) | Se activa cuando el servidor se queda sin memoria en mitad del procesamiento de una solicitud. Al abortar abruptamente mediante longjmp(), deja estructuras internas a medio inicializar que el proceso de limpieza posterior confunde con datos válidos. | RCE. Permite a un atacante forzar fallos de memoria estructurados para inyectar y ejecutar sus propios comandos. |
| CVE-2026-109619 (Stale Global State) | Se produce un “uso de memoria después de ser liberada” (Use-After-Free). Ciertas variables globales de PHP siguen apuntando a zonas de memoria de una solicitud que ya terminó y fue destruida, sobreviviendo en el subproceso (worker). | RCE y fuga de datos. La siguiente solicitud legítima o maliciosa lee o sobrescribe esa memoria huérfana, exponiendo contraseñas, tokens y claves API de otros usuarios. |
¿Qué sistemas están en riesgo?
Prácticamente cualquier servidor configurado para responder solicitudes web: Ref: [1]
- Entornos de ejecución: PHP-FPM, Apache (
mod_php), php-cgi, FrankenPHP y LiteSpeed. El riesgo es calificado como extremo enmod_phpporque el ataque se ejecuta antes de que tu propio código de aplicación empiece a correr. Ref: [1] - Plataformas populares: Sitios basados en WordPress, Laravel, Drupal, Magento y Joomla se ven directamente afectados si el PHP subyacente no está actualizado. Ref: [1]
Mitigaciones temporales (si no puedes actualizar ya)
Si dependes de un proveedor externo o requieres tiempo para compilar las nuevas versiones, puedes aplicar estas medidas paliativas de emergencia en tu php.ini o configuraciones de servidor (requiere reiniciar los procesos de PHP posteriormente): Ref: [1, 2]
- Desactivar el progreso de subida de archivos: Para mitigar vectores conocidos de la vulnerabilidad de estado global, añade esto a tu configuración global:ini
session.upload_progress.enabled = 0Usa el código con precaución.(Asegúrate de hacerlo a nivel de servidor o pool de FPM; no confíes enini_set()dentro del código de la app). Ref: [1] - Desactivar backtraces en PHP 8.5: Si usas la rama experimental 8.5, apaga los reportes detallados de errores fatales: [1]ini
fatal_error_backtraces = 0Usa el código con precaución. - Límites en el Proxy/WAF: Configura reglas en tu proxy inverso o Firewall de Aplicaciones Web (WAF) para bloquear peticiones con archivos adjuntos sospechosos o cuerpos extremadamente pesados (multipart forms) si tu aplicación no los necesita. Ref: [1]
