CVE-2026-111497: Vulnerabilidad Node.js y lecciones

Qué cubre este artículo

• Qué es CVE-2026-111497, cómo funciona el error en el decodificador Brotli y qué versiones de Node.js están seguras.
• Por qué esta vulnerabilidad junto con PHP2Shell muestra un patrón: la IA encuentra errores que los humanos pasaron por alto durante años.
• La incómoda pregunta de si los agentes de codificación aprenden de las correcciones de seguridad o propagan el código defectuoso.
• Qué significa la vulnerabilidad para despliegues en Docker y Coolify, y por qué los contenedores por sí solos no son suficientes.
• Por qué fundamentos como Clean Code siguen siendo relevantes en la era de la IA, a pesar de críticas justificadas al libro.

El 21 de octubre de 2026 fue un doble golpe

El mismo día que PHP2Shell sacudió el mundo PHP, el proyecto Node.js publicó su lanzamiento de seguridad. La vulnerabilidad más grave: CVE-2026-111497, un error de memoria en el decodificador Brotli con CVSS 9,2. Lo interesante: ambas vulnerabilidades fueron descubiertas por equipos con asistencia de IA. PHP2Shell provenía de Wiz Research, OpenAI Codex Security y Calif, mientras que CVE-2026-111497 fue reportada por OpenAI Codex Security, específicamente por Khai Tran y Sylvie Mayer.

Este es el verdadero valor de la noticia. En una semana, sistemas de IA encontraron dos errores de memoria críticos en infraestructura que llevaba años ejecutándose en producción. Para desarrolladores que codifican con IA, surge una pregunta desde dos direcciones: ¿te ayuda esa misma tecnología a encontrar estos errores en tu código? ¿Y al mismo tiempo genera más código donde tales vulnerabilidades pueden ocultarse?

¿Qué es CVE-2026-111497?

La vulnerabilidad de Node.js reside en el descompresor Brotli. Brotli es el algoritmo de compresión de Google que reduce el tráfico web, respuestas HTTP y archivos más que gzip. Node.js incluye la biblioteca C y la expone a través de node:zlib.

El error es un clásico de seguridad de memoria, empaquetado en un contexto de streaming: cuando el decodificador encontraba un cambio de bloque inválido, debería haber reportado un error de formato permanente, pero en su lugar indicaba que solo necesitaba más datos de entrada. El decodificador de streaming permanecía así sobre el mismo búfer, escribiendo bytes adicionales en un búfer interno de ocho canales más allá del final real. El resultado es una escritura fuera de límites, un acceso de escritura fuera de la memoria reservada.

Si alguien logra pasar datos Brotli malformados a una aplicación (por ejemplo, a través del cuerpo de una solicitud HTTP, una carga o una respuesta que la aplicación obtiene de un servidor externo), puede corromper la memoria del proceso. Las consecuencias: bloqueos, lectura de memoria del proceso o, en el peor caso, ejecución remota de código con los permisos del proceso Node.js. El CVE lleva las designaciones CWE-787 (Out-of-bounds Write) y CWE-252 (Unchecked Return Value). La segunda es reveladora: un valor de retorno no fue verificado correctamente. Exactamente el patrón que las revisiones de código han perseguido durante décadas.

¿Qué versión de Node.js es segura?

Versión	Estado
Node.js 26.12.1 o más reciente	parcheada
Node.js 24.22.1 o más reciente	parcheada
Node.js 22.23.4 o más reciente	parcheada
Node.js 20.x y anteriores	Fin de vida, sin corrección
Biblioteca Brotli 1.0.10, 1.1.1, 1.2.1	parcheada
Brotli 1.0.3 a 1.2.0	vulnerable

Importante: la vulnerabilidad está en la biblioteca Brotli en sí. No afecta solo a Node.js, sino a cualquier software que incluya el mismo decodificador. La entrada NVD lista Google Brotli 1.0.3 a 1.2.0 como vulnerable. Si ejecutas proyectos Python, Rust o Go con enlaces Brotli, debes verificar la versión de biblioteca incluida.

Para contextualizar el registro CVE: Google asignó el identificador como CNA, no el proyecto Node.js, porque el error está en la biblioteca de Google. La actualización Vulnrichment de CISA del 23 de octubre califica la vulnerabilidad con tres puntos SSVC: sin explotación conocida en el momento de la notificación, no trivialmente automatizable, pero con impacto técnico total en el proceso si se explota con éxito. En resumen: actualmente no es un incendio controlado, pero es fundación para ataques graves una vez que existe un exploit estable.

¿Me afecta?

La superficie de ataque es más estrecha que en PHP2Shell: Node.js no descomprime datos Brotli de la red por sí mismo. Tu aplicación está afectada si aplica activamente brotliDecompress o el stream de Brotli desde node:zlib a datos que un atacante controla. Tres casos típicos:

• Cuerpos de solicitud o cargas que aceptas con Content-Encoding: br y descomprimyes.
• Respuestas que tu código obtiene de servidores externos y desempaqueta. Aquí el parche de runtime atrapa lo que un workaround no puede.
• Middleware que recibe cargas comprimidas de usuarios.

Comprueba la versión así:

node -v

En contenedores Docker, como con PHP2Shell, cuenta la versión en la imagen:

docker exec <container> node -v

En Vercel y plataformas administradas similares, el proveedor implementa la actualización. Un redeploy asegura que el nuevo runtime se aplique. Si usas Node.js 20.x: la rama está al final de su vida y no recibirá la corrección. Necesitas cambiar a 22.x o 24.x.

La comparación con CVE-2025-10966: dos vulnerabilidades, un patrón

Casi un año antes, en noviembre de 2025, apareció CVE-2025-10966: a curl le faltaba verificación de host para SFTP a través del backend de wolfSSH. Un atacante en el medio podía hacerse pasar por servidor sin que curl alertara. Severidad baja porque casi nadie usa este backend en producción, pero el hallazgo es interesante: lo reportó Stanislav Fort de Aisle Research, una empresa que realiza investigación de seguridad asistida por IA.

	CVE-2025-10966	CVE-2026-111497
Software	curl	Node.js (Brotli)
Tipo de error	Verificación de host faltante, CWE-322	Out-of-bounds Write, CWE-787 + CWE-252
Severidad	Baja	Crítica, CVSS 9,2
Descubierto con asistencia de IA	Sí, Aisle Research	Sí, OpenAI Codex Security
Antigüedad del código	Brecha de implementación de años	Error en código de decodificador hace mucho estable

El patrón común: ambos errores no eran nuevos. estaban en código que se ejecutaba en producción desde años atrás, en rutas que casi nadie usa o que casi nadie revisa. Los revisores humanos pasaron por alto ambos. Los sistemas de IA los encontraron porque recorren sistemática e incansablemente caminos de código para los que ningún humano tiene tiempo. Para entender cómo la IA está cambiando la ciberseguridad en ambos lados, consulta el artículo IA en ciberseguridad.

¿Aprenden los agentes de Vibe Coding de la corrección?

La respuesta más honesta es: no, no automáticamente. Un LLM que genera código no aprende del parche en tiempo real. Los pesos del modelo se entrenaron antes de la corrección. Si el modelo aprendió patrones de código de streaming Brotli, patrones de retorno sin verificación o configuraciones inseguras por defecto de los datos de entrenamiento, seguirá sugiriendo los mismos patrones hasta que se entrene un nuevo modelo con datos corregidos.

Esta es la diferencia estructural con un equipo humano: un desarrollador que una vez causó una brecha en producción se acuerda. Un modelo no se acuerda. Reproduce código estadísticamente probable, y el código estadísticamente probable contiene patrones de error históricos.

Tres consecuencias para ti como Vibe Coder:

• Ceguera de versiones: los agentes tienden a sugerir APIs y dependencias en versiones que conocen de los datos de entrenamiento. El agente no te dirá automáticamente que su ejemplo de Node tiene una vulnerabilidad de Brotli. Los controles de dependencias con npm audit, OSV-scanner o Dependabot siguen siendo obligatorios, incluso si el agente entrega código limpio.
• Ventana de contexto en lugar de memoria: lo que un agente corrija dentro de una sesión, lo olvida en la siguiente. Solo logras persistencia a través de reglas que van en cada sesión: reglas de proyecto, AGENTS.md, archivos de memoria. La sistemática detrás de esto está en seguridad de agentes.
• El parche no está en el modelo: hasta que aparezca la siguiente generación de modelo, la distribución de entrenamiento sigue conteniendo el código defectuoso. Si hoy solicitas “descompresión de streaming”, probablemente obtengas patrones que contengan el mismo error lógico que CVE-2026-111497 acaba de corregir.

La segunda pregunta es si los agentes propagan el código anterior vulnerable. También aquí: sí, mientras esté en los datos de entrenamiento y sea estadísticamente frecuente. La única contramedida de tu lado es que no adoptes ciegamente el código generado, sino que lo revises, lo pruebes y versionices y audites tus dependencias.

Por qué habrá más lagunas críticas en el futuro

Esta predicción no es alarmismo, sino la consecuencia de dos observaciones simples.

Primero, la base de código crece más rápido que la capacidad de revisión. El código generado por IA aumenta el rendimiento, pero no la comprensión por línea. Más código en producción significa más superficie de ataque, y una proporción creciente de ese código ha sido revisada superficialmente por humanos.

Segundo, la búsqueda de vulnerabilidades se abarata. Los mismos modelos que escriben código para desarrolladores ahora analizan sistemáticamente bases de código existentes. PHP2Shell y CVE-2026-111497 son los primeros resultados prominentes. Wiz habla de un punto de inflexión en la investigación de vulnerabilidades impulsada por IA. Lo que antes un equipo especializado buscaba durante meses, un equipo respaldado por IA lo encuentra en semanas. La consecuencia: el número de CVEs críticos reportados aumentará, no porque el software sea peor, sino porque la detección mejora. También es una buena noticia que se siente mal: cada laguna encontrada ya existía antes.

¿Tiene más sentido desplegar versiones en contenedores Docker como Coolify?

Los contenedores ayudan, pero no resuelven el problema. Lo transforman en una forma manejable.

Lo que los contenedores logran con CVE-2026-111497:

• Control sobre la versión de runtime: Fijas la versión de Node en la imagen (node:24.22.1-alpine), reconstruyes, despliegas atómicamente. Sin “el servidor sigue corriendo la versión antigua porque nadie lo reinició”.
• Camino de parche más rápido: La imagen oficial de Node se reconstruye con el fix. Actualizas el tag, docker compose up -d, listo. Igual que en la guía Docker de PHP2Shell: reiniciar no es suficiente, la imagen debe ser nueva.
• Contención del daño: Si la aplicación no corre como root, tiene filesystem de solo lectura y sin secretos en variables de entorno, una RCE en el contenedor es mucho menos valiosa. El componente de divulgación de memoria no puede leer un sistema raíz, solo el proceso.
• Rollback y reproducibilidad: Si el nuevo build falla, estás un tag atrás. Coolify lo hace especialmente cómodo en la interfaz.

Lo que los contenedores no logran: No parchean nada. Una imagen node:22-alpine construida antes del 21 de octubre sigue conteniendo la versión vulnerable de Brotli incluso después de un reinicio. Y el aislamiento es más frágil de lo que parece: una RCE en el contenedor alcanza los volúmenes montados, las variables de entorno y en el peor caso el socket de Docker. Los pasos de endurecimiento están en Docker-Container absichern y Rootless Docker.

Para usuarios de Coolify, el camino práctico es: desencadenar un redeploy para que Coolify traiga de nuevo la imagen base, y después verificar node -v en el contenedor en ejecución. Quien ejecuta su homeserver así encontrará los pasos concretos junto con la verificación de WordPress en PHP2Shell: WordPress, Docker, Coolify und Homeserver jetzt prüfen und absichern en IRC-Mania.de.

Aprender sin codificación por intuición: ¿Qué valor tiene hoy Clean Code?

El artículo estaría incompleto sin preguntarse qué se puede aprender sin herramientas de IA de CVE-2026-111497. Y ahí está la referencia clásica sobre la mesa: Clean Code de Robert C. Martin de 2008, vinculado en las recomendaciones de libros de IA.

Primero, la crítica legítima. El libro es antiguo. Los ejemplos son Java, los patrones son anteriores a Microservicios, algunas reglas son controvertidas. La actitud desfavorable hacia comentarios de Uncle Bob, su dogma de funciones pequeñas y las disertaciones sobre herencia ya no son indiscutibles hoy. Quien lee el libro como una ley produce dogmatismo en lugar de calidad.

Pero la respuesta justa sobre su actualidad: el núcleo se mantiene. El bug detrás de CVE-2026-111497 es un ejemplo de libro de lo que el libro enseña. Un valor de retorno no se trató adecuadamente, un estado de error se pasó como “necesito más datos” en lugar de “error de formato”, y quien llamaba la función hizo una suposición falsa sobre el estado del decodificador. Clean Code lo llama así: trata los errores como su propia clase de lógica, no devuelvas estados ambiguos, no hagas que quien te llamó adivine qué pasó. Estos principios son independientes del lenguaje y anteriores al libro.

Tres aplicaciones concretas para hoy:

• Nomenclatura y funciones pequeñas siguen siendo válidas, precisamente porque el código generado por IA a menudo produce funciones largas y difíciles de revisar.
• Manejo de errores es más importante que nunca en la era de la IA: los caminos de código generados suelen terminar en la ruta feliz. Quien hace las preguntas del libro encuentra la laguna: ¿qué pasa con entrada inválida, timeout, stream abortado?
• La parte que realmente ha envejecido son los idiomas Java específicos y los consejos de frameworks. El mensaje más amplio, que el código se escribe para lectores y los casos de error deben ser visibles, es tan actual como en 2008.

Para el ejercicio sistemático correspondiente, Programmieren lernen mit KI tiene un ejercicio donde la IA sugiere mejoras de Clean Code que luego implementas tú mismo.

Cómo seguir mejorando tus habilidades de programación a pesar de la IA

La última pregunta es la más importante: si la IA escribe el código, ¿qué te queda por aprender?

La respuesta honesta: la habilidad valiosa se desplaza de escribir a revisar. CVE-2026-111497 muestra por qué. El error estaba en código humano, pero el mismo error de pensamiento, un valor de retorno no verificado en una API de streaming, aparece igual en código generado. Quien no entiende qué hace un decodificador con un buffer no puede revisar el código, sin importar quién lo haya escrito.

Caminos de ejercicio concretos:

• Lee avisos de CVE como documentación. El aviso de Node.js explica el error en tres párrafos más claramente que cualquier tutorial. Una vez que entiendes qué es un escritura fuera de límites, reconoces el patrón en tu propio código.
• Haz que te expliquen el código generado, línea por línea. Pídele a la IA que te explique el código que acaba de escribir. Si no entiendes alguna parte, esa es la parte que debes aprender.
• Revisa código ajeno por un patrón. Toma un CVE como este, lee el parche e intenta explicar por qué el fix es correcto. Este es conocimiento de seguridad que ningún curso transmite de forma tan práctica.
• Escribe los caminos críticos tú mismo. Auth, descompresión, subidas de archivos, todo lo que toca entrada no confiable. La IA puede hacer el boilerplate, tú escribes las líneas donde un error es costoso.
• Construye una pequeña rutina de seguridad: npm audit, revisión de dependencias, inventario de runtimes de servidor una vez al trimestre. La rutina supera al conocimiento sin aplicación.

Y la actitud base: la IA no reemplaza la comprensión, la traslada. Quien desarrolla hoy necesita menos memoria de sintaxis, pero más criterio sobre el código que recibe. Exactamente para eso se escribió Clean Code, y exactamente por eso sigue siendo relevante.

Preguntas frecuentes sobre CVE-2026-111497 y seguridad en programación

La laguna de Node.js

¿Qué es CVE-2026-111497?

Una corrupción de memoria crítica en el decodificador Brotli que Node.js proporciona a través de node:zlib. Una escritura fuera de límites puede provocar crash, divulgación de memoria o ejecución remota de código. Afecta a Node.js 22.x, 24.x y 26.x anteriores a los lanzamientos de parche.

¿Qué versión de Node.js es segura?

22.23.4, 24.22.1 y 26.12.1 o superior. Node.js 20.x es fin de vida y no recibe correcciones, es necesario actualizar.

¿Cómo verifico mi versión de Node.js?

En el servidor con node -v. En un contenedor Docker con docker exec <container> node -v. En Coolify a través de la vista de logs o terminal del contenedor.

¿Se verá afectada mi aplicación si no uso Brotli?

Si tu código aplica brotliDecompress o streams Brotli a datos controlados por atacantes: sí. Quien usa Brotli solo para compresión de salida está menos expuesto. Las llamadas de biblioteca en dependencias cuentan también.

¿La IA encontró esta laguna?

Sí. Fue reportada por OpenAI Codex Security, específicamente por Khai Tran y Sylvie Mayer. Junto con PHP2Shell, es la evidencia más visible de que la investigación de seguridad respaldada por IA encuentra bugs críticos reales.

¿Qué es Brotli?

El algoritmo de compresión de Google, estándar para HTTP Content-Encoding junto a gzip. Node.js incluye la biblioteca C. La laguna está en la biblioteca misma, no en código específico de Node.

¿Es suficiente reiniciar el contenedor Docker para el parche?

No. La imagen debe reconstruirse para que la versión de Brotli parcheada llegue al contenedor. docker compose build --pull && docker compose up -d, después verificar la versión.

¿Qué hago con Node.js 20.x?

Planifica la migración a 22.x o 24.x. Node 20 es fin de vida, no recibirá la corrección y es un riesgo continuo de todos modos.

¿Es suficiente un firewall como protección?

No. Las reglas de WAF, por ejemplo de Vercel o Cloudflare, mitigan caminos de ataque conocidos, pero no reemplazan el parche de runtime. El vector de ataque está por debajo del nivel de la aplicación.

Vibe Coding y seguridad en IA

¿Aprenden los agentes de codificación de los parches de seguridad?

No automáticamente. Los pesos del modelo se entrenaron antes del parche. El código defectuoso sigue en los datos de entrenamiento. Solo un nuevo modelo con un corpus actualizado cambiaría el comportamiento.

¿Propagan los agentes de IA código antiguo y vulnerable?

Sí, mientras domine los datos de entrenamiento. El agente sugiere patrones estadísticamente frecuentes, no patrones seguros. La revisión y auditoría de dependencias siguen siendo obligatorias.

¿Es el código generado por IA fundamentalmente inseguro?

No. Es inseguro cuando va a producción sin revisión, sin pruebas y sin verificación de dependencias. La IA puede mejorar la seguridad si la usas para revisiones y análisis.

¿Puede la IA revisar mi código en busca de estas vulnerabilidades?

Como primer paso, sí. “Revisa este código en busca de errores de memoria y valores de retorno sin verificar” da resultados útiles. Los límites están en el contexto: los modelos pasan por alto problemas dependientes del sistema y pueden dar una falsa sensación de seguridad.

¿Veremos más CVEs críticos en el futuro?

Probablemente, por dos razones: la base de código crece más rápido que la capacidad de revisión, y la investigación impulsada por IA encuentra errores que los humanos pasaron por alto. Ambos aumentan la tasa de descubrimiento.

¿Cuál es la diferencia entre CVE-2026-111497 y PHP2Shell?

PHP2Shell estaba en el núcleo de PHP y permitía RCE en un área muy amplia. CVE-2026-111497 está en la biblioteca Brotli y afecta a aplicaciones que descomprimen activamente datos controlados por el atacante. Lo que comparten: ambos se encontraron con ayuda de IA.

¿Qué es Vibe Coding?

Desarrollar a través de prompts en lenguaje natural a un LLM, enfocándose en el resultado en lugar de la comprensión propia del código. Funciona para prototipos, es riesgoso para producción si faltan revisiones y pruebas.

¿Son los contenedores Docker más seguros para lanzamientos?

Más prácticos, sí. Te dan control sobre el runtime, despliegues atómicos y reversión. Pero no parchean nada: la imagen debe reconstruirse con la versión corregida y el contenedor debe endurecerse.

¿Es Coolify adecuado para despliegues seguros?

Sí, muy conveniente para el flujo de parches: redeploy trae la nueva imagen base, rollback funciona por tag. La seguridad depende de la configuración del contenedor: sin root, filesystem de solo lectura, secretos como archivos, no como variables de entorno.

Codificación y seguridad en general

¿Qué es una escritura fuera de límites (Out-of-bounds Write)?

Un programa escribe datos fuera del área de memoria reservada. Esto puede sobrescribir datos adyacentes, lo que causa un bloqueo, fuga de datos o, en el peor de los casos, ejecución de código.

¿Qué significa CWE-252, Unchecked Return Value?

No se verifica el valor de retorno de una función; el llamador hace una suposición falsa sobre el éxito. En CVE-2026-111497, se devolvió “error de formato” como “necesito más datos”, y el descompresor continuó escribiendo en un búfer demasiado pequeño.

¿Qué es Remote Code Execution?

Un atacante ejecuta su propio código en tu sistema sin acceso físico. En CVE-2026-111497 con los permisos del proceso Node, lo que significa acceso a volúmenes, variables de entorno y red.

¿Qué es Memory Disclosure?

El proceso expone el contenido de memoria que no está destinado al llamador, como tokens de sesión, claves o datos de usuarios. Incluso sin ejecución de código, es un daño grave.

¿Necesito revisión de código si la IA escribe?

Sí, más que nunca. El código de IA se ve limpio, pero contiene suposiciones no verificadas, valores por defecto inseguros y patrones de API obsoletos. La revisión es el único filtro.

¿Qué es un ataque a la cadena de suministro?

En lugar de atacarte directamente, el atacante infecta una dependencia que instalas. Ejemplo: la campaña de gusano npm 2025, que exfiltró tokens y credenciales de máquinas de desarrolladores.

¿Cómo me protejo de paquetes npm comprometidos?

Crea un commit con lockfiles, usa npm audit y Dependabot, implementa actualizaciones con retraso en lugar de inmediatamente, verifica paquetes por estado de mantenimiento y no almacenes secretos localmente en máquinas de desarrollo.

¿Qué es Secrets-Rotation?

El intercambio regular de claves API, contraseñas y tokens, para que las credenciales filtradas se vuelvan inválidas. Con vulnerabilidades de Memory Disclosure como CVE-2026-111497, es el primer paso después del parche, ver Secrets-Rotation automatisieren.

¿Qué trae un filesystem de solo lectura en el contenedor?

Después de una RCE, el atacante no puede reemplazar binarios ni desplegar webshells. La persistencia se vuelve más difícil, la investigación forense más fácil.

¿Por qué no root en el contenedor?

Una RCE como root en el contenedor puede abusar de interfaces del kernel, alcanzar el daemon de Docker o escalar en el host. Como usuario sin privilegios, la superficie de ataque es mucho más pequeña.

¿Qué es un proceso de gestión de parches?

Rutina regular: inventario de runtimes, monitoreo de lanzamientos de seguridad, actualización oportuna con verificación de reinicio, verificación de compromiso. Para CVEs críticos como PHP2Shell en horas, no semanas.

Aprender a programar y Clean Code

¿Vale la pena Clean Code en la era de la IA?

El núcleo sí: manejo de errores como lógica separada, nombres expresivos, funciones pequeñas, sin adivinar del llamador. Los ejemplos y dogmas de Java envejecieron, pero los principios son exactamente los que CVE-2026-111497 violó.

¿Cuáles son las debilidades de Clean Code?

Centrado en Java, escrito antes de Microservices, dogmáticamente contrario a comentarios, algunas reglas son controvertidas. Como ley inadecuado, como marco de pensamiento sigue siendo fuerte.

¿Cómo permanezco relevante como desarrollador si la IA escribe?

Desplaza el enfoque de escribir a revisar: capacidad de revisión, conocimiento de seguridad, diseño de sistemas, depuración. La IA reemplaza escribir, no el juicio.

¿Cómo aprendo de un CVE para mi trabajo?

Lee el boletín, entiende el error, mira el parche y explícate por qué la corrección es correcta. Siguiente paso: busca el mismo patrón en tu propio código.

¿Debo escribir código crítico yo mismo en lugar de la IA?

Sí. Autenticación, descompresión, manejo de cargas, lógica de pagos, todo lo que procesa entrada no confiable. La IA puede hacer boilerplate, los caminos críticos de seguridad son tuyos.

¿Puede la IA ayudarme a aprender?

Sí: deja que explique, haz pasadas de revisión, genera ejemplos, muestra variantes. El efecto de aprendizaje llega cuando entiendes qué hizo la IA, no cuando simplemente lo adoptas.

¿Cuáles son los principios de seguridad más importantes para desarrolladores?

Nunca confíes en entradas, verifica valores de retorno, haz explícitos los estados de error, permisos mínimos necesarios, crea inventario de dependencias, secretos no en código, logging para patrones de ataque. CVE-2026-111497 viola tres de estos.

¿Necesito un título en seguridad para escribir código seguro?

No. Los patrones son aprendibles: CWE-Top-25, guías OWASP, CVE writeups, reportes de bug bounty. Lo que cuenta es rutina en revisión, no un título.

¿Dónde encuentro más sobre desarrollo seguro en PHP y Node.js?

Para el lado técnico IRC-Coding.de con sus tutoriales de programación, para Incident Response y compromiso IRC-Security.de. El artículo PHP2Shell en BotServ trata la parte de PHP del mismo tema.

Fuentes y enlaces relacionados

• Node.js Security Release, 21 de octubre de 2026: Aviso oficial sobre CVE-2026-111497 y nueve correcciones adicionales.
• Registro CVE-2026-111497: La entrada CVE con CWE-787 y CWE-252, incluido el enriquecimiento CISA (sin explotación conocida, impacto total).
• GitHub Advisory GHSA-9v8h-qqgm-4m35: La asesoría sobre la biblioteca Brotli con las versiones afectadas.
• Vercel Security Bulletin: Contexto de explotación y estado del runtime gestionado.
• CSA Singapore Alert: La evaluación crítica con CVSS 9,8.
• curl CVE-2025-10966 Advisory: El ejemplo comparativo, también descubierto con asistencia de IA.
• PHP2Shell en BotServ.de: El caso similar del mismo día.
• PHP2Shell en IRC-Coding.de: La guía de actualización de PHP en detalle.
• PHP2Shell en IRC-Mania.de: Práctica con Docker, Coolify y servidores locales.
• IRC-Security.de: Respuesta ante incidentes, análisis de logs y análisis forense tras una compromisión.