ACTUALIZACION
Mentira que todo el mundo pudo parchear cuando PHP 5.4, 5.6, 7.4 sigue gobernando el mundo, entonces para mitigar minimamente esto comparto algunas sugerencias para evitar PHP2Shell | CVE-2026-109618 y CVE-2026-109619. Este post es estrictamente técnico.
1. php.ini
Hay que tocar estos valores, pero ojo depende de cada caso.
Lo principal, sin lugar a dudas:
session.upload_progress.enabled = Off
A continuación ojo, si tenes un solo sitio en un servidor, no deberias tener mucho problema por mas que no esté bien, es decir quedan los procesos sin limite de memoria.
memory_limit = -1
Ahora si estas en un hosting compartido, puede ser un arma de doble filo. Cada uno sabra.
post_max_size = 32M
upload_max_filesize = 16M
Podes bajarlo a 16 tambien, pero vas a tener limitaciones en la subida de archivos obviamente.
Estas configuraciones pueden contribuir a reducir determinados riesgos, pero no corrigen las vulnerabilidades en su totalidad, aunque las PoC que están dando vueltas dejan lugar a dudas.
2. WAF y Proxy Reverso.
El WAF se hizo para usarse, no es la cura de todos los males, pero siempre es mejor tenerlo que no tenerlo.
Actualizado y configurado para bloquear solicitudes maliciosas. Pueden usar ModSecurity con reglas Comodo, verificando que las solicitudes PHP efectivamente atraviesen el WAF y no existan rutas alternativas que permitan evitarlo. Incluso la suma de un Apache con usando como proxy reverso NGINX.
En NGINX tambien pueden proteger mas cosas como
# Evitar ejecutar PHP desde directorios de archivos subidos
location ~* ^/(uploads|files|media|oloquesea)/.*\.php(?:/|$) {
return 403;
}
# Proteger archivos internos
location ~ /\.(?!well-known(?:/|$)) {
deny all;
}
# Limitar el tamaño de las solicitudes
client_max_body_size 10m;
3. Cloudflare Free y protección del servidor de origen
Cloudflare acaba de poner protecciones contra estas vulnerabilidades, disponibles y activadas por defecto también en su plan gratuito. Sin embargo, utilizar Cloudflare no alcanza si el servidor de origen sigue aceptando conexiones directas desde Internet.
RECUERDEN QUE CLOUDFLARE si no esta bien configurado o con un escaneo de las ramas de DNS puede "bypasearse".
Por eso, es especialmente importante configurar el firewall del servidor para permitir conexiones HTTP/HTTPS únicamente desde los rangos oficiales IPv4 e IPv6 de Cloudflare, contemplando las excepciones necesarias para otros servicios y accesos legítimos.
También es recomendable implementar Authenticated Origin Pulls cuando la arquitectura lo permita.
4. Monitoreo permanente
Complementar las medidas con monitoreo de procesos, revisión de logs, detección de malware, análisis de solicitudes sospechosas y verificación del funcionamiento de las aplicaciones. Que un sitio responda HTTP 200 no garantiza que todos sus componentes funcionen correctamente. Aplica a plugins y subidas de archivos especialmente en Wordpress, Moodle, Drupal, Laravel, Symphony y la lista es larga que ya todos conocemos, ni hablar de lo legacy sin documentación.
5. Si tenes la suerte $$$ de usar Plesk en servidores compartidos o propios.
TuxCare Extended Lifecycle Support for PHP, que requiere una licencia específica por USD 10 mensuales y te permite usar las compilaciones PHP correspondientes.
Si no podes cambiar el codigo fuente migrar a Plesk puede con Cloudflare puede ser una buena opcion para versiones de PHP viejas.
También más complejo podes dockerizar y meterle una capa más de protección adicional para los requests.
6. Servidores Debian / Ubuntu con el repo de Surý
Ondřej Surý se puso la 10 y sacó los parches para 5.6 como para 7.4. En el log aparece: "Backported from 8.2.35".
Conclusión
Estas medidas son mitigaciones temporales y no eliminan el 100 % de los riesgos, ni garantizan protección frente a futuras vulnerabilidades. La solución de fondo sigue siendo utilizar versiones de PHP efectivamente parcheadas y con soporte, actualizar las aplicaciones y retirar progresivamente las tecnologías obsoletas. Mitigar no es parchear. Pero esto es Argentina y nosotros somos gordos sysadmin que nadie nos ve intentar apagar estos incendios.
POSDATA> Mas de uno vuelva a la universidad y apreda que sistemas !== infra , digamos, o sea, parchear con las versiones de PHP que salió hoy lleva literalmente cinco minutos. El problema es que casi nadie esta en esas ramas y los sistemas estan en versiones viejas. Infra puede parchear lo que quieras, porque algun CISO diga parchea, pero SISTEMAS no tiene como reescribir codigo viejo ni en cinco minutos ni en un dia. La IA tampoco, excepto minimas excepciones.
POSDATA 2> Esto es para el quilombo de PHP, todavia ni analicé lo de Node.js ni lo de los TLS ni lo que pueda surgir mañana. Ni hablemos del CVE del Kernel de Linux de la semana pasada que fue bastante doloroso.
Sugerencias para enfrentar el dia de hoy en ciberseguridad con lo de la vulnerabilidad en PHP.
Primero: somos todos colegas, dejense de putear uno a otro. Esta falla como miles de CVE existian desde hace decadas. La IA la descubrio, ningun humano mortal, asi que nadie es mas que otro.
Segundo: Parchear no resuelve nada, incluso puede complicar mas las cosas, a quien le resuelve la vida parchear hoy? al minimo porcentaje que tenia todo actualizado hasta la semana pasada, y todo incluye codigo fuente y sistema operativo, dudo que sea el 5% con suerte. Si sos de ese minimo porcentaje, si parchea. Sino:
Tercero: muchos servidores corren muchos servicios al mismo tiempo, no tienen servicios distribuidos, entonces para que el exploit no te afecte por un ataque directo o de bots es preferible perder disponibilidad que integridad y confidencialidad, una de los tres pilares de la ISO 27001, y este debate sera algo que vendra a futuro. Yo elijo la indisponibilidad en este escenario caotico antes que poner en riesgo la otras dos. Por eso apaga Apache, NGINX u OpenLight Speed. No alcanza con un WAF, ahora. Con eso el servidor, menos las webs quedan operativos.
Cuarto: La falla viene desde PHP 5 que sigue recontra productivo como el 7, si bien dicen que el soporte solo es de 8.2 en adelante, es posible que se den dos escenarios debido a la gravedad el asunto: que en breve salga un update para versiones viejas de manera extraordinaria o que podamos aplicar un cambio de configuracion en PHP que permita que esa vulnerabilidad no se pueda explotar.
Quinto: Quienes piensen que dejar todo expuesto esta ok y un backup te salva, estan en un grave error, pueden crear persistencia, robo de informacion, inyectar codigo malicioso para terceros, es decir, solo vas a agrandar tu problema.
Sexto: PHP es un gran lenguaje, por algo es el mas utilizado en Internet, los detractores son personas que les molestan cositas como que la variable no tenga que obligatoriamente declararse por tipo o que simplemente su curva de aprendizaje sea facil. Ojo que Node.js hoy justamente tambien esta en el horno y asi otros lenguajes como .NET y IIS.
Septimo: no rompan mas las pelotas, si van a comentar: aporten y ayuden, si van a criticar y jamas en su vida gestionaron nada, corranse del camino, que no nos perdemos de nada.