Una vez que el incidente fue reportado de manera oficial por el equipo de PHP y las agencias de seguridad, publicamos en nuestro blog oficial el siguiente articulo:
https://blog.smartnethostingcolombia.com/alerta-de-seguridad-php-que-son-las-vulnerabilidades-php2shell-cve-2026-109618-y-cve-2026-109619-y-el-desafio-de-las-versiones-legadas/

Es importante aclarar que si bien, incluso las versiones parchadas de php de manera oficial, esto, como lo indican las agencias de seguridad y el mismo equipo de desarrollo de php, no es una garantía total ante las incidencias, que pudieron desde más de 60 días ser explotadas. Teniendo esto en cuenta y que la disponibilidad de versiones de php en servidor depende de varios factores, pero principalmente de compatibilidad entre al menos: firewall, panel de control, kernel, software de terceros, te compartimos las siguientes recomendaciones oficiales que puedes implementar:

Recomendaciones de seguridad oficiales para sistemas que no pueden actualizar su versión de PHP (CVE-2026-109618 y CVE-2026-109619 / PHP2Shell)

Con base en los avisos de seguridad oficiales del proyecto PHP y entidades de respuesta a incidentes (como CERT-EU) tras el reporte de las vulnerabilidades críticas PHP2Shell (CVE-2026-109618 y CVE-2026-109619), la solución sería actualizar a las versiones limpias. Sin embargo, para aquellos entornos y versiones legadas que por motivos estrictos de compatibilidad no pueden migrar a la versión PHP de inmediato, los canales oficiales y de la industria de ciberseguridad detallan las siguientes opciones de soporte retroactivo y mitigaciones temporales:

Mitigaciones temporales de configuración en el servidor

Si la actualización inmediata no es viable, los avisos técnicos recomiendan aplicar configuraciones perimetrales estrictas a nivel global del servidor (asegurándose de que las aplicaciones individuales no puedan sobrescribirlas mediante funciones como ini_set o archivos .user.ini):

  • Para mitigar el vector de corrupción de memoria OOM (CVE-2026-109618):
  • Configurar memory_limit = -1 mediante directivas estrictas como php_admin_value en el archivo de configuración del pool de PHP-FPM o de Apache. Esto evita el fallo directo por el límite de memoria controlable.

  • Establecer un valor bajo y estricto para post_max_size (por ejemplo, 8M si la aplicación no requiere subidas de archivos, o limitar de acuerdo con la necesidad estricta).

  • Para mitigar el vector de estado global obsoleto (CVE-2026-109619):

  • Deshabilitar el seguimiento de subidas configurando session.upload_progress.enabled = 0 en el archivo php.ini global o en la configuración del servidor web.
  • Reiniciar de inmediato todos los procesos de PHP (workers / PHP-FPM / Apache) para forzar la recarga de los cambios.


Aislamiento de red temporal

  • Las agencias de ciberseguridad internacionales sugieren que, si un sistema expuesto a internet no puede ser parcheado o mitigado adecuadamente de inmediato, se evalúe desconectarlo temporalmente de las redes públicas para evitar riesgos de explotación remota hasta contar con un entorno seguro, sin embargo, esta no es una opción real para la mayoría de las empresas y organizaciones, por lo que desde SNHC.cloud recomendamos la implementación de reglas de seguridad en el waf del cdn, como la restricción de acceso estricto solo a IP de Colombia, lo que crea una capa de seguridad a nivel de red de acceso.


Filtrado perimetral y WAF (Firewall de Aplicaciones Web)

  • Aunque los expertos aclaran que las mitigaciones perimetrales reducen la exposición pero no sustituyen un parche real , implementar reglas estrictas en firewalls de aplicaciones web o proxies inversos para bloquear solicitudes multipart/form-data anómalas, limitar el tamaño del contenido y filtrar peticiones excesivas antes de que alcancen el motor de PHP ayuda a disminuir la superficie de ataque.


Miércoles, Octobre 21, 2026







« Atrás

Powered by WHMCompleteSolution