Saltar al contenido
folhas.io
secure by design para productos conectados· Artículos

Artículos

PHP2Shell y Node.js: lo que piden a quien fabrica equipos

El 21 de octubre de 2026, PHP y Node.js publicaron correcciones de seguridad graves. Quien fabrica equipos con panel web, gateways o ejecutables Node tiene tres preguntas que responder: si el producto incluye el componente, si hay obligación de notificar en virtud del artículo 14 y cómo llega la corrección a las unidades que ya están en campo.

Publicado

El 21 de octubre de 2026, dos runtimes que muchos productos conectados llevan dentro publicaron correcciones de seguridad el mismo día. PHP corrigió dos vulnerabilidades críticas, conocidas como PHP2Shell, que pueden permitir la ejecución remota de código sin autenticación. Node.js corrigió diez, entre ellas una escritura fuera de límites en el descodificador Brotli que, según el proyecto, permite la ejecución remota de código.

Este texto mira el caso desde el lado de quien fabrica equipos con uno de estos runtimes embebido (un panel de gestión web, un gateway, una aplicación Node empaquetada en un ejecutable) y sigue las tres preguntas que plantea a la vez: si el componente está en el producto, si hay obligación de notificar en virtud del artículo 14 del CRA y cómo llega la corrección a las unidades ya vendidas.

Lo que pasó el 21 de octubre

PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen la CVE-2026-109618 y la CVE-2026-109619, después de haberlas preanunciado la víspera. Los fallos fueron descubiertos y comunicados por investigadores de Calif, Wiz y OpenAI, y el proyecto, que asignó las dos CVE, dio a cada una un 9,2 en CVSS v4.0. El NVD las evalúa en otro sistema de puntuación, el CVSS v3.1: 9,8 para la CVE-2026-109618, el valor que algunos fabricantes usan en sus avisos, y 8,1 para la CVE-2026-109619. Las distribuciones Linux y los proveedores de soporte extendido recibieron las correcciones antes del lanzamiento.

Según el aviso de php.net, están en riesgo todas las instalaciones de PHP que sirven peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Los advisories técnicos del proyecto validan la ejecución remota de código en mod_php en los dos fallos, sin depender de la aplicación. En PHP-FPM, el advisory de la CVE-2026-109619 la validó también, por un camino que depende de una operación adecuada de la aplicación; el de la CVE-2026-109618 concluye, por el análisis del código, que PHP-FPM es susceptible, aunque sin un exploit completo demostrado. PHP 8.1 y anteriores ya no reciben versiones nuevas, pero, dada la gravedad, el equipo de seguridad del proyecto publicó correcciones mínimas para las ramas 7.4, 8.0 y 8.1, en código fuente y sin número de versión nuevo.

El mismo día, Node.js publicó las versiones 22.23.4, 24.22.1 y 26.12.1, con diez CVE corregidas. El proyecto clasifica los fallos por gravedad, sin puntuación CVSS, y la gravedad más alta en cada línea es «high». Uno de los cuatro de gravedad alta es la CVE-2026-111497, la escritura fuera de límites en el descodificador Brotli, comunicada por OpenAI Codex Security (Khai Tran y Sylvie Mayer) y corregida, según el aviso de Node.js, por Matteo Collina y Antoine du Hamel. El fallo está en la propia biblioteca Brotli de Google, en las versiones 1.0.3 a 1.2.0, y Google publicó el 21 oct las versiones corregidas 1.2.1, 1.1.1 y 1.0.10. El registro CVE de la biblioteca, asignado por Google, le da un 9,2 en CVSS v4.0. Entre los restantes hay dos fallos de gravedad alta que eluden la verificación del nombre de host en los certificados TLS, y la CVE-2026-106074, de gravedad media, que afecta a los snapshots de arranque y a los ejecutables SEA y vuelve a aparecer más abajo. Node.js 20, en fin de vida desde el 30 abr 2026, no recibió corrección, y el proyecto recuerda que las versiones en fin de vida quedan siempre afectadas cuando hay un lanzamiento de seguridad.

Sobre la explotación, las fuentes divergen, y cada afirmación tiene fecha. En la alerta del 21 oct 2026, la CISA escribió que aún no había observado explotación de PHP2Shell. El mismo día, Amazon Threat Intelligence dijo haber registrado en sus honeypots un intento de explotación fechado el 17 oct, cuatro días antes de la divulgación, y otros en la madrugada del 21 oct, todavía bajo embargo, admitiendo no saber si alguno habría tenido éxito en sistemas reales. Después del lanzamiento, vio surgir en pocas horas nuevas pruebas de concepto, usadas casi de inmediato contra sus sensores, y describió intentos de explotación a gran escala. Cloudflare dijo haber observado tráfico de ataque contra sus clientes. A fecha de 23 oct 2026, ninguna de las dos CVE de PHP figuraba en el catálogo KEV de la CISA.

Para los fallos de Node.js no se conoce explotación activa: tampoco estaban en el KEV en esa fecha. Existe, no obstante, prueba de concepto pública para la CVE-2026-111497, y el 22 oct Imperva demostró ejecución de código en una imagen oficial de Node.js 24.22.0 para Linux arm64, lo que por sí solo no indica explotación activa. La evaluación SSVC de la CISA en el registro de esa CVE no sirve aquí de referencia: el 23 oct pasó de «none» a «poc» y, en la revisión siguiente del mismo día, volvió a «none».

LíneaVersión corregida el 21 oct 2026Fin de soporte del proyecto
PHP 7.3 y anterioresninguna6 dic 2021 o antes
PHP 7.4, 8.0 y 8.1ninguna; solo correcciones mínimas en código fuente28 nov 2022, 26 nov 2023 y 31 dic 2025
PHP 8.28.2.3531 dic 2026
PHP 8.38.3.3631 dic 2027
PHP 8.48.4.2731 dic 2028
PHP 8.58.5.1231 dic 2029
Node.js 20 y 25ninguna30 abr 2026 y 1 jun 2026
Node.js 2222.23.430 abr 2027
Node.js 2424.22.130 abr 2028
Node.js 2626.12.130 abr 2029

Las fechas de Node.js son las del calendario del proyecto, que advierte de que pueden cambiar.

Primera pregunta: ¿está el componente en el producto?

La CISA advirtió de que PHP es a menudo un componente de otro software y de que su presencia puede no ser directamente observable. El NCSC-NL, el centro nacional de ciberseguridad de los Países Bajos, fue más concreto: PHP viene también embebido en appliances, equipos de red e interfaces de gestión, donde el administrador puede no tener forma de actualizarlo directamente. Para el cliente de un equipo, la pregunta puede no tener respuesta a la vista; quien puede darla es el fabricante.

Con una SBOM generada en el build (el artículo 01 explica por qué), la respuesta se obtiene consultando el inventario, sin abrir ningún equipo. En este caso, cada entrada necesita algo más que el nombre: la versión exacta; las correcciones aplicadas, porque las correcciones mínimas para ramas en fin de vida no traen número de versión nuevo (en la 7.4, el binario compilado a partir de ellas se identifica incluso como 7.4.31-dev, por debajo de la última versión oficial, la 7.4.33); la forma en que se ejecuta el runtime (en PHP, mod_php, PHP-FPM o php-cgi; en Node.js, el runtime del sistema o un ejecutable SEA); y si el código vulnerable es alcanzable en el producto. Para la CVE-2026-111497, la entrada que hay que buscar es también la biblioteca Brotli, que puede estar en el firmware sin Node.js. El registro CVE sitúa el fallo en el descodificador: lo que importa es dónde descomprime el producto datos Brotli de origen no fiable, como respuestas HTTP comprimidas o cuerpos de petición descomprimidos por middleware.

La respuesta pública es un estado por producto y versión (afectado, no afectado, corregido o en investigación), preferiblemente en formato legible por máquina, como VEX. La lista que el NCSC-NL abrió el 21 oct, y que el aviso 2026-018 del CERT-EU y la declaración conjunta del 21 oct recomiendan consultar, sigue esta lógica: es un inventario en SPDX, trata cada entrada como pista de investigación y solo la da por corregida o no afectada con una fuente del proyecto o del fabricante. El aviso que publica el fabricante es lo que permite cerrar su línea.

Incluso una evaluación de riesgo mínimo tiene trabajo detrás. Synology confirmó impacto en diez paquetes que dependen de PHP y que se corrigen actualizando PHP desde el Package Center. Sobre el componente PHP de uso interno de DSM, concluyó que no tiene superficie de ataque expuesta y evaluó el riesgo como mínimo, pero, aun así, programó la corrección para una versión posterior, para que los resultados de los escáneres de vulnerabilidades y el estado de conformidad sean coherentes.

Varios de los equipos con PHP embebido que aparecen en los avisos de estos días (cortafuegos, appliances de red, sistemas de gestión de redes) coinciden con categorías de productos importantes del Anexo III del CRA: los cortafuegos en la clase II y los sistemas de gestión de redes en la clase I, según las descripciones técnicas del Reglamento de Ejecución (UE) 2025/2392, cuando esa es la funcionalidad principal del producto (art. 7, apartado 1). En esas categorías, la evaluación de la conformidad puede exigir la intervención de terceros: en la clase I, cuando no se aplican en su totalidad normas armonizadas, especificaciones comunes o certificación europea; en la clase II, siempre (art. 32, apartados 2 y 3), como muestra el artículo 03.

Los paneles de gestión con php-cgi

El aviso de php.net incluye expresamente php-cgi entre las instalaciones en riesgo. Es la forma que usa la documentación de lighttpd para conectar PHP a ese servidor web: el servidor arranca el ejecutable /usr/bin/php-cgi como procesos FastCGI persistentes, que atienden peticiones sucesivas. En OpenWrt, PHP no forma parte de la imagen por defecto: es un paquete opcional del feed de paquetes (php8-cgi), y la configuración por defecto del servidor uHTTPd trae comentada, y por tanto desactivada, la línea que entrega los ficheros .php a php-cgi. Quien añade un panel PHP a su imagen hereda esta elección.

Los dos advisories técnicos de PHP analizan mod_php, PHP-FPM, LSAPI y FrankenPHP y no tratan php-cgi por separado. Sin ese análisis, la posición prudente es tratarlo como afectado, en cualquier modo en que se ejecute, y actualizar. Hasta que la actualización llegue a los equipos en campo, la interfaz de gestión debe quedar restringida a la red de administración: el CERT-EU y la declaración conjunta del 21 oct recomiendan considerar el aislamiento de las aplicaciones expuestas respecto de la red pública, y Netgate recuerda que, por defecto, la interfaz web de pfSense solo es accesible desde la red local. La propia Netgate pide a los usuarios del portal cautivo, expuesto por naturaleza a clientes no fiables, que actualicen PHP cuanto antes. Restringir la interfaz de gestión no protege las funciones que el equipo sirve por PHP a redes no fiables.

Una nota para quien limita la memoria del proceso PHP en el script de arranque, con ulimit, por ejemplo: el advisory de la CVE-2026-109618 desaconseja RLIMIT_AS y RLIMIT_DATA, porque pueden desencadenar el propio fallo, y dice que un límite de contenedor o de cgroup no impide con garantía el fallo de asignación ni es una mitigación completa; el aviso de php.net lo trata como frontera de disponibilidad. Las medidas temporales de PHP (memory_limit=-1 fijado de forma que las aplicaciones no lo cambien, post_max_size bajo, session.upload_progress.enabled=0 y, en PHP 8.5, fatal_error_backtraces=0, con reinicio de todos los workers) reducen la exposición a caminos concretos, y el propio proyecto dice que solo la actualización lo resuelve por completo.

Segunda pregunta: ¿hay obligación de notificar?

Desde el 11 sep 2026 (art. 71, apartado 2), el artículo 14 obliga al fabricante a notificar las vulnerabilidades aprovechadas activamente contenidas en su producto, también en los productos introducidos en el mercado antes del 11 dic 2027 (art. 69, apartado 3). La declaración conjunta del 21 oct de la Comisión, la ENISA, el CERT-EU, Europol y la red de CSIRT recordó, a propósito de PHP2Shell, que esa notificación se hace a través de la plataforma única de notificación de la ENISA. Los plazos están en el artículo sobre la notificación de 24h y 72h.

La pregunta propia de este caso es otra: ¿la explotación de un componente en otros sistemas obliga, por sí sola, a notificar a quien lo integra? Las orientaciones de la Comisión de 27 jul 2026, C(2026) 5252, responden en el punto 218, al que remite la FAQ de la ENISA sobre la plataforma (pregunta 14), junto con la sección 5.4 de las FAQ de la Comisión sobre la aplicación del CRA, de 3 dic 2025: el fabricante solo tiene que notificar vulnerabilidades aprovechadas activamente contenidas en su producto. Si la vulnerabilidad de un componente de terceros está siendo aprovechada en el producto, notifica. Si la vulnerabilidad no puede aprovecharse en el producto (por ejemplo, porque el código vulnerable no es alcanzable), o si no ha habido explotación en él, no queda sujeta a notificación obligatoria para ese fabricante.

Las FAQ de 2025 son más amplias: solo excluyen el caso en que la vulnerabilidad no puede aprovecharse en el producto, y la definición del art. 3, punto 42, habla de que se haya aprovechado en un sistema, sin decir cuál. Las orientaciones son el texto más reciente y más específico; ninguno de los dos es vinculante.

En la práctica, los intentos de explotación a gran escala contra servidores PHP son un detonante de evaluación, no la toma de conocimiento. Según las mismas orientaciones, el fabricante tiene conocimiento cuando, después de una evaluación inicial inmediata, tiene un grado razonable de certeza de que una vulnerabilidad de su producto está siendo aprovechada activamente, y la señal puede llegar de clientes, de autoridades o de los medios de comunicación. Las preguntas del triaje son concretas: en qué productos y versiones sirve PHP peticiones, si la interfaz queda accesible desde redes no fiables en las instalaciones conocidas, y si la telemetría, los registros o los informes de clientes muestran señales de explotación en unidades del propio producto. Si el triaje concluye, con un grado razonable de certeza, que hay explotación activa en unidades del producto, es esa hora la que abre el plazo de 24 horas de la notificación de alerta temprana; conviene registrarla, y registrar también la conclusión cuando es negativa. En el caso de Node.js, a fecha de 23 oct 2026 no había explotación activa conocida que planteara esta pregunta, pero la prueba de concepto pública para la CVE-2026-111497 justifica mantener el triaje abierto en los productos que descomprimen datos Brotli de origen no fiable.

Hay una asimetría que pesa en el parque instalado. Según las orientaciones (sección 9.1), la notificación se aplica a los productos introducidos en el mercado antes del 11 dic 2027 y continúa después de terminado el período de soporte, mientras que las obligaciones de tratamiento de vulnerabilidades del Anexo I, Parte II, no se aplican a esos productos. Un equipo vendido hoy puede, por tanto, tener obligación de notificar sin tener, en virtud del CRA, obligación de corregir. Después de tener conocimiento, el fabricante tiene además que informar a los usuarios afectados y, cuando proceda, a todos los usuarios, de la vulnerabilidad y, si es necesario, de las medidas paliativas y correctoras que pueden adoptar (art. 14, apartado 8). Según las orientaciones (punto 220), esta obligación se aplica de forma proporcional al riesgo y no obliga a hacer pública la información.

Para los casos sin notificación obligatoria, el punto 218 admite la notificación voluntaria del artículo 15, pero la plataforma todavía no la recibe: según la FAQ de la ENISA, llegará en una fase futura.

Nota de rigor. Las orientaciones C(2026) 5252 no son vinculantes: la propia Comisión recuerda que solo el Tribunal de Justicia de la Unión Europea puede interpretar el CRA con autoridad. Hasta el 23 oct 2026 no hemos encontrado ninguna posición oficial sobre este caso concreto. Lo expuesto arriba es la lectura de las orientaciones aplicada a él y no sustituye el análisis jurídico de cada producto.

Tercera pregunta: ¿cómo llega la corrección a los equipos en campo?

La misma CVE se corrige por caminos diferentes según la forma en que el runtime entró en el producto, y es la SBOM la que dice cuál se aplica.

Cuatro caminos por los que la corrección de un runtime llega al equipo, según la forma en que entró en el producto. Como paquete del sistema, procedente de una distribución o un feed: actualizar el paquete, reconstruir la imagen y enviarla, porque un paquete corregido todavía no es firmware en campo. Compilado en la imagen de firmware: actualizar la receta, reconstruir y enviar por OTA o localmente; en una rama en fin de vida no hay versión corregida. Dentro de un ejecutable SEA de Node.js: reconstruir con el Node.js corregido, rehacer los snapshots y redistribuir, porque actualizar el Node.js del sistema no basta. Como aplicación aparte o contenedor: actualizar la aplicación por su propio canal sin cambiar el firmware, lo que presupone un canal de aplicaciones en el equipo. En todos, la SBOM dice qué camino se aplica y la corrección solo cuenta cuando llega a cada unidad.
El trabajo que queda después de que el proyecto publique la corrección depende de cómo entró el runtime en el producto, y esa información tiene que estar registrada antes de que haga falta.

Cuando el runtime viene de una distribución o de un feed de paquetes, la corrección del proyecto llega primero al paquete, y en PHP las distribuciones la tuvieron antes del lanzamiento. Eso todavía no es firmware en las unidades. En OpenWrt, la receta de PHP en la rama principal del feed de paquetes ya está en la 8.4.27; quien construye sobre ella tiene que reconstruir la imagen de cada producto y enviarla. También hay casos en que la corrección del componente sortea el canal normal del producto: Netgate publicó paquetes PHP corregidos para pfSense, pero, en las instalaciones existentes, esa actualización no se hace desde la interfaz web, solo desde la línea de comandos (una instalación nueva, o una actualización a una versión actual, ya los trae). En Brotli, la corrección puede llegar por dos lados. Node.js trae por defecto su propia copia de la biblioteca, pero puede compilarse enlazado a la del sistema (opción --shared-brotli), y en ese caso la corrección llega con la actualización de esa biblioteca. Como el fallo está en la biblioteca, el registro CVE pide actualizar cualquier biblioteca o binario Brotli de las versiones afectadas, lo que incluye un firmware que use Brotli sin Node.js.

Si el runtime está compilado dentro de la imagen de firmware, la corrección solo llega con una imagen nueva, distribuida por OTA o localmente. En las ramas en fin de vida el trabajo crece: para PHP 7.4, 8.0 y 8.1 solo existen las correcciones mínimas en código fuente; para las ramas anteriores y para Node.js 20, ni eso. La tabla de arriba muestra además un problema que desarrolla el artículo sobre el período de soporte: ninguna línea actual de PHP o de Node.js tiene soporte del proyecto hasta el final de un período de soporte de cinco años que empiece en diciembre de 2027.

Un ejecutable SEA de Node.js es el propio binario de Node con la aplicación inyectada, y la documentación exige que el blob de la aplicación lo genere la misma versión del binario en el que se inyecta. De ahí deducimos que actualizar el Node.js del sistema no corrige un SEA ya distribuido: hay que reconstruirlo con la 22.23.4, la 24.22.1 o la 26.12.1 y redistribuirlo. Los snapshots de arranque siguen la misma lógica, porque Node se niega a cargar un snapshot generado por un binario de otra versión, y tienen que regenerarse con el binario corregido. La CVE-2026-106074 da una razón más: las cachés de entropía de crypto.randomUUID() y crypto.randomInt() quedaban grabadas en los snapshots y en los SEA, y todos los procesos arrancados a partir de ellos repetían los mismos valores. Si esos valores sirvieron para identificadores de unidad o para secretos, conviene revisarlos; la recomendación es nuestra, porque Node.js no ha publicado orientación sobre los valores ya generados.

El camino se acorta cuando el runtime se ejecuta como aplicación separada del firmware. En los dispositivos con u-OS, Weidmüller pasó Node-RED de servicio nativo del sistema a aplicación en contenedor, lo que permite, según el propio fabricante, actualizar Node-RED y el firmware de forma independiente.

El mismo lanzamiento de Node.js tocó también la confianza TLS: bloquea, con una lista compilada en el binario, ocho certificados intermedios de eMudhra cuyas claves privadas se dieron por comprometidas, y actualiza el almacén de certificados raíz embebido al de NSS 3.131.1. Un equipo con almacén de certificados raíz propio necesita también un camino de actualización para él. El incidente de eMudhra, y lo que la misma semana trajo para el kernel Linux y para Python, están en el artículo 10.

En cuanto a lo que el CRA exige aquí, las fechas cuentan. A partir del 11 dic 2027, para los productos introducidos en el mercado a partir de esa fecha (o modificados sustancialmente después de ella, art. 69, apartado 2), el Anexo I, Parte II, pide, durante el período de soporte (art. 13, apartado 8), que las vulnerabilidades se traten y corrijan sin demora en función de los riesgos que presenten, con actualizaciones de seguridad separadas de las funcionales cuando sea técnicamente viable, mecanismos de distribución seguros (automáticos, cuando proceda) y actualizaciones difundidas sin demora y, por regla general, sin coste, acompañadas de avisos a los usuarios. Para las unidades que ya están en campo, corregir es hoy una decisión técnica y contractual, que el CRA no impone. Fuera del CRA, en los bienes de consumo con elementos digitales, la Directiva (UE) 2019/771 (art. 7, apartado 3, transpuesta en Portugal por el Decreto-ley n.º 84/2021) obliga al vendedor a velar por que el consumidor reciba las actualizaciones, incluidas las de seguridad, necesarias para mantener la conformidad de los bienes durante el período que pueda razonablemente esperar.

La obligación de comunicar aguas arriba

El CRA dibuja también el sentido inverso. Para los productos introducidos en el mercado a partir del 11 dic 2027, el artículo 13, apartado 6, obliga al fabricante que detecte una vulnerabilidad en un componente integrado a comunicarla a quien lo mantiene y, si desarrolla una corrección, a compartirla. Las orientaciones de la Comisión (sección 9.2.1) dispensan de la comunicación cuando el fabricante puede confirmar que el mantenedor ya conoce la vulnerabilidad, como ocurre con los fallos que el propio proyecto ha publicado, y no exigen que la corrección compartida sea aceptada. Para los productos que hoy están en el mercado nada de esto es todavía obligación, pero compartir una corrección propia (un backport para una rama de PHP en fin de vida, por ejemplo) es una buena práctica. Cómo enviar y recibir estas comunicaciones es el tema del artículo sobre divulgación coordinada.

Qué hacer esta semana

Para quien tiene productos con PHP o Node.js en campo:

  • Consultar la SBOM de cada producto y versión en campo en busca de PHP (y de la forma en que se ejecuta), de Node.js (del sistema o en un SEA) y de la biblioteca Brotli, con la versión exacta y las correcciones aplicadas. Donde no haya SBOM, el manifiesto del build es el punto de partida.
  • Publicar el estado por producto y versión (afectado, no afectado, corregido o en investigación) y actualizarlo a medida que avanza el análisis.
  • Abrir el triaje del artículo 14 para los productos en los que PHP sirve peticiones, con responsable, criterio escrito y la hora de conclusión registrada.
  • Preparar las imágenes corregidas: PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35; Node.js 22.23.4, 24.22.1 o 26.12.1; Brotli 1.2.1, 1.1.1 o 1.0.10 donde la biblioteca esté presente; SEA y snapshots reconstruidos; almacén de certificados raíz, si el equipo tiene uno propio.
  • En las imágenes nuevas, seguir también el aviso informativo de PHP del 23 oct 2026, que recomienda mantener session.upload_progress.enabled=0 hasta la próxima versión regular, por un vector adicional que el proyecto considera improbable (CVE-2026-115560).
  • Hasta que llegue la actualización, indicar a los clientes las medidas a su alcance, empezando por restringir la interfaz de gestión a la red de administración.
  • Para los productos con PHP 8.1 o anterior, o con Node.js 20, decidir entre migrar de versión, contratar soporte extendido o mantener correcciones propias, y dejar la decisión por escrito.

Fuentes