Dos zero-days en software que corre en el 30-40% de toda internet, según W3Techs. Uno en el reverse proxy que protege su sitio. Otro en el Git autohospedado que guarda su código. Ambos explotables remotamente, sin autenticación, sin interacción. En Tech86 ya vimos esta combinación, y el patrón es claro: los puntos de entrada más obvios son los que nadie audita.
NGINX PoolSlip: heap overflow en el rewrite module
El CVE-2026-9256 es un heap buffer overflow en el ngx_http_rewrite_module, el módulo que procesa rewrite rules y redirects en toda configuración NGINX. CVSS v4.0: 9.2. Pre-auth, remoto, sin interacción. Un único HTTP request manipulado.
El detonante: una directiva rewrite con regex de capturas PCRE sin nombre superpuestas (^/((.*))$) combinada con una replacement string que referencia múltiples capturas ($1$2). NGINX subestima el tamaño del output después del URI escaping: cada byte escapable se expande de 1 a 3 bytes. El buffer se asigna para el tamaño raw. La copia escribe más allá. Out-of-bounds write en la memoria del worker.
El impacto inmediato es DoS por crash repetido del worker. Con ASLR deshabilitado o vulnerable a bypass, el camino hacia RCE en el contexto del worker queda abierto. Y el investigador observa: el master hace fork de workers con layout idéntico, tumbar un worker y reintentar es viable.
El patrón de configuración que activa el PoolSlip no es exótico. Las rewrite rules con capturas superpuestas y múltiples backreferences son comunes en API gateways, enrutamientos dinámicos y migraciones de URL. Si su nginx.conf tiene algo como rewrite ^/((.*))$ /new-path/$1$2;, usted está en la superficie de ataque. Y la probabilidad de que alguien ya haya escaneado esa configuración con herramientas automatizadas es alta.
Nueve días, dos heap overflows en el mismo módulo
Aquí está el punto que no puede ignorarse: CVE-2026-42945, el primer heap overflow en el rewrite module, recibió parche en las versiones 1.31.0 y 1.30.1. Quien actualizó a esas versiones sigue vulnerable a PoolSlip. Bugs diferentes, mismo código. Dos heap overflows en 9 días en el mismo módulo no es coincidencia: es señal de que el rewrite engine necesita una auditoría profunda, no parches incrementales.
El parche para PoolSlip está en las versiones 1.31.1 y 1.30.2. El branch 0.x está EOL y no recibirá corrección. Verifique la versión del binario, no la versión del paquete del sistema operativo: la diferencia es frecuente y cara.
La mitigación inmediata es sustituir capturas sin nombre por capturas con nombre en las directivas rewrite. Esto elimina el code path vulnerable sin necesidad de reboot. Pero es un workaround, no una solución estructural. El rewrite engine de NGINX es un subsistema con estado compartido entre passes, escaping condicional y múltiples code paths: exactamente el tipo de superficie donde los bugs lógicos se acumulan sin ser detectados durante años.
Gogs: argument injection con RCE y sin parche
Mientras NGINX corrige en días, Gogs sigue otro camino. CVSS 9.4. Argument injection vía branch name en pull requests. El atacante crea un branch con --exec en el nombre. Cuando el merge usa "Rebase before merging", el comando se ejecuta después de cada commit replayed. RCE con los privilegios del proceso Gogs.
Lo que vuelve esto crítico: registro abierto por default, sin límite de repositorios. El atacante crea cuenta, crea repo, habilita rebase, explota. Ninguna interacción de otro usuario. Es RCE self-contained. Con acceso al proceso, el atacante lee repos privados, extrae credenciales, pivota hacia otros sistemas y modifica código en silencio.
Rapid7 notificó al mantenedor a mediados de marzo. Hasta el 29 de mayo: ningún parche. Más de dos meses. Y este es el segundo zero-day de Gogs en 6 meses: el primero, CVE-2025-8110, lo reportó Wiz en diciembre. Dos zero-days en medio año, con respuesta lenta en ambos, es un patrón que indica un problema estructural de mantenimiento, no un incidente aislado.
Para los equipos que dependen de Gogs como repositorio central de código, la implicación es directa: cada día sin parche es un día en que la superficie de ataque crece. Las herramientas de explotación automatizada hacen que descubrir y abusar de vulnerabilidades como esta sea cada vez más rápido.
La lección: conveniencia sin mantenimiento es objetivo fácil
Gogs es popular porque ofrece la conveniencia de un GitHub privado sin costo. Los equipos pequeños lo adoptan por la simplicidad. Pero la combinación de registro abierto por default, ausencia de parche durante meses y dos zero-days en medio año convierte esa conveniencia en riesgo calculado, y el cálculo no favorece a quien mantiene la instancia corriendo.
En Tech86, nuestra recomendación es directa: migre a Gitea o Forgejo. Son forks de Gogs con mantenimiento activo, correcciones de seguridad consistentes y comunidad comprometida. La migración es relativamente simple: ambos soportan importación directa de repositorios Gogs. Si la migración no es inmediata, deshabilite el registro abierto, deshabilite el rebase merging y restrinja el acceso por red. Estas tres medidas reducen drásticamente la superficie, pero no eliminan la vulnerabilidad.
Conclusión
Dos zero-days. Dos softwares que corren a escala global. NGINX: dos heap overflows en 9 días en el mismo módulo, parche en días, pero la ventana de explotación es real. Gogs: RCE sin parche desde hace más de 2 meses, segundo zero-day en 6 meses. Su reverse proxy y su Git autohospedado no pueden ser los puntos de entrada de su infraestructura.
En Tech86 auditamos infraestructura web y pipelines de código con security-by-design. Identificamos configuraciones vulnerables antes de que se conviertan en exploits y, cuando el parche no llega, construimos las capas de defensa que protegen mientras el problema estructural no se resuelve. Porque en infraestructura, lo que no se audita se explota.