Fastify EOL: versiones, fechas, riesgos y opciones (2026)

Principales conclusiones

• Fastify v3 dejó de estar disponible el 30 de junio de 2023, y la v4 hizo lo propio el 30 de junio de 2025.
• Solo la línea v5 sigue recibiendo correcciones por parte del equipo de Fastify, mientras que la v6 ya ha entrado en fase alfa.
• Fastify v5 requiere Node.js 20 o una versión posterior, y Node 20 llegará al final de su vida útil (EOL) en abril de 2026, por lo que la actualización del marco de trabajo conlleva una actualización del entorno de ejecución.
• El soporte de ciclo de vida ilimitado de TuxCare cubre las versiones 3.29.5 y 4.29.1 de Fastify con parches CVE continuos mientras planificas la migración.

Si realizas un inventario en un gran parque de servidores Node.js, lo normal es que encuentres servicios que siguen ejecutándose con Fastify v3, cuyo soporte a largo plazo (LTS) finalizó en junio de 2023. Eso supone más de tres años sin parches de seguridad para el marco de trabajo en un código que sigue en producción en este momento.

Fastify v4 tampoco cuenta ya con soporte, ya que su periodo de soporte a largo plazo (LTS) finalizó el 30 de junio de 2025. Esto deja a la versión v5, lanzada en septiembre de 2024, como la única versión para la que el equipo principal sigue realizando correcciones. Cambiar a esta versión también implica pasar a una versión de Node.js que siga contando con soporte, ya que Node 20 ha llegado al final de su vida útil (EOL) y Node 22 ya ha pasado a la fase de mantenimiento.

A continuación encontrarás qué significa realmente el fin de vida útil (EOL) de Fastify, qué riesgos son reales y cuáles teóricos para cada línea, cómo queda una flota de v3 cuando esa solicitud de migración se va posponiendo un trimestre tras otro, y cuáles son tus tres opciones realistas.

¿Qué es Fastify?

Fastify es un marco web de Node.js diseñado para reducir la sobrecarga por solicitud, con una arquitectura de complementos que mantiene todo encapsulado, de modo que los decoradores de una ruta no puedan interferir en los de otra. Realiza la validación y la serialización mediante JSON Schema y registra los datos a través de pino. Cuando se lanzó la versión 5, la OpenJS Foundation registró las descargas mensuales en 7,8 millones, con 296 complementos reconocidos oficialmente en el ecosistema. En julio de 2026, según npm-stat, esa cifra había superado los los 43 millones de descargas mensuales.

 

En comparación con los marcos de trabajo que probablemente ya hayas utilizado, Express es el más antiguo y el más grande, con unas descargas mensuales en npm aproximadamente doce veces superiores a las de Fastify, a pesar de no incluir prácticamente ninguna validación integrada, y es el marco desde el que suelen proceder la mayoría de los equipos. Hapi requiere una configuración más compleja y ofrece más funcionalidades de serie. Koa es un núcleo de middleware ligero en el que casi todo lo demás es una decisión independiente que debes tomar tú mismo. NestJS no es realmente un competidor, ya que es un marco de aplicaciones que se ejecuta sobre Express o sobre un adaptador de Fastify.

Si tu servicio es una aplicación NestJS que ejecuta el adaptador Fastify, Fastify forma parte de tu árbol de dependencias, independientemente de si el inventario de activos de tu equipo la denomina «aplicación Fastify» o no. Lo mismo ocurre con la versión de Node.js subyacente, que ha dejado de estar disponible sin que nadie se haya dado cuenta y que sigue ahí anclada por un marco de trabajo que alguien eligió hace dos equipos y una reorganización.

Consejo de experto: ejecuta npm ls fastify –all en todos los repositorios de servicios, no solo en aquellos en los que creas que se utiliza. Los adaptadores, los generadores y los SDK internos incorporan Fastify como dependencia transitiva, y esas copias rara vez tienen un propietario claro. Así es como suele aparecer una instalación errante de la versión 3.

¿Ha llegado Fastify al final de su ciclo de vida?

Las versiones v1, v2, v3 y v4 de Fastify ya han superado sus fechas de fin de soporte a largo plazo (LTS). La v5 es la única línea que recibe correcciones activas por parte del equipo central, y su entrada en el calendario oficial sigue indicando «por determinar». Sin embargo, eso no permanecerá así para siempre. Fastify 6.0.0-alpha.1 se lanzó en agosto de 2026 y, según la misma política, la v5 pasará a recibir únicamente actualizaciones de seguridad durante seis meses una vez que se lance la v6.

El calendario no es arbitrario, aunque desde fuera pueda parecerlo. La política de LTS de Fastify ofrece a cada versión principal un mínimo de seis meses de soporte activo, más otros seis meses de actualizaciones exclusivas de seguridad una vez que se lance la siguiente versión principal. Esa es la lógica que sitúa el fin del LTS de la v4 el 30 de junio de 2025.

Una vez finalizado ese plazo, la política establece que los responsables seguirán revisando y publicando correcciones de seguridad, pero solo cuando la comunidad las proporcione y siempre que no se encuentren con otras limitaciones, como la versión mínima compatible de Node.js. Se trata de un soporte condicional, impulsado por la comunidad, más que de una línea de versiones mantenida. Un error grave en la v4 hoy en día podría recibir un parche de la comunidad, una nota cortés para actualizar, o simplemente quedarse sin resolver como un issue en GitHub.

Apostar por una API de producción en función de cuál de esos tres resultados se produzca es precisamente lo que acaba costando caro a los equipos. Esa es, precisamente, la razón por la que existe el soporte de seguridad ampliado.

Ciclo de vida de las versiones de Fastify y fechas clave de fin de vida útil (EOL)

Estas fechas proceden directamente del calendario de versiones LTS publicado por Fastify. La columna de Node.js reproduce las líneas de lanzamiento que allí se enumeran para cada versión principal, por lo que incluye versiones «Current» de corta duración, como la 9 y la 11, junto con las líneas LTS.

Versión de Fastify	Fecha de lanzamiento	Fin del soporte a largo plazo (LTS)	Situación actual	Líneas de Node.js enumeradas
1.0.0	Marzo 6, 2018	Septiembre 1, 2019	EOL	6, 8, 9, 10, 11
2.0.0	Febrero 25, 2019	Enero 31, 2021	EOL	6, 8, 10, 12, 14
3.0.0	Julio 7, 2020	Junio 30, 2023	EOL	10, 12, 14, 16, 18
4.0.0	Junio 8, 2022	Junio 30, 2025	EOL	14, 16, 18, 20, 22
5.0.0	Septiembre 17, 2024	No se ha anunciado	Activo	20, 22

Una advertencia sobre la fila de la v5. En ella se recoge lo que se probó cuando se lanzó la v5, y la integración continua (CI) de Fastify en la rama «main» ahora ejecuta sus pruebas unitarias con Node 24 y 26. Node 20 también aparece en esa fila, pero dejó de estar en servicio (EOL) el 30 de abril de 2026, por lo que debes considerarlo como un mínimo de compatibilidad y no como un entorno de ejecución en el que realizarías un despliegue.

Ahora fíjate en la fila de la v3 que está junto a la fecha de hoy. Han pasado tres años desde el fin del soporte a largo plazo (LTS), en un rango de Node.js (del 10 al 18) que en sí mismo está totalmente en fin de vida útil (EOL), y dado que la v4 también ha dejado de estar disponible, ya no queda ningún paso intermedio al que recurrir. Por eso, «simplemente actualizar» supone un reto mucho mayor para un parque de servidores con v3 de lo que parece para uno con v4.

Riesgos de seguridad derivados del uso de Fastify (llegado al final de su ciclo de vida) en entorno de producción

El riesgo no radica en que haya un CVE concreto en tu node_modules en este momento. Es la asimetría la que entra en juego el día en que tu versión llega al fin de vida útil (EOL) y se agrava cada año a partir de entonces. La investigación en seguridad sobre Fastify sigue avanzando a toda velocidad, y las correcciones que genera se desarrollan para la línea v5, que cuenta con soporte. Para un conjunto de servidores en v4, eso supone ya más de un año de brecha acumulada. Para uno en v3, tres.

Las vulnerabilidades CVE del marco ya no afectan a tu versión

La familia de validaciones de tipo de contenido es un claro ejemplo de lo que eso supone en la práctica. En abril de 2025, CVE-2025-32442 documentó una vulnerabilidad por la que las aplicaciones que definían una validación por tipo de contenido podían ver cómo se omitía por completo dicha validación, simplemente enviando un encabezado Content-Type ligeramente modificado. El aviso indica que las versiones afectadas son Fastify 5.0.0 a 5.3.1 y 4.29.0, con correcciones en las versiones 5.3.2 y 4.29.1. La versión 4 recibió una versión parcheada porque aún se encontraba dentro de su periodo de soporte, y la versión 3 nunca se incluyó en la lista de versiones afectadas. Un año más tarde, la misma familia dio lugar a CVE-2026-33806, una vulnerabilidad de alta gravedad que permitía eludir precisamente esa corrección utilizando nada más exótico que un espacio inicial en el encabezado, corregida únicamente en la versión 5.8.5.

La Actualización de seguridad del primer trimestre de 2026 de la Fundación OpenJS recoge 18 CVE del ecosistema publicadas a través de sus operaciones de CNA durante ese trimestre, tres de ellas en el ecosistema de Fastify. Dos de ellas correspondían al propio Fastify. El CVE-2026-3419 era un problema de validación del campo «Content-Type» mal formado que afectaba a las versiones 5.7.2 a 5.8.0 y se corrigió en la 5.8.1, lo que lo convierte en una regresión exclusiva de la versión 5, en lugar de una adaptación retrospectiva que faltara. CVE-2026-3635 es el que merece la pena analizar: un falla de suplantación de encabezados que permite la suplantación de la cabecera, cuyo aviso de seguridad abarca todas las versiones de Fastify hasta la 5.8.2, mientras que la corrección solo se incluye en la 5.8.3. Todas las instalaciones de las versiones v3 y v4 se encuentran dentro de ese rango afectado, y ninguna de ellas recibió una versión parcheada.

El tercero, CVE-2026-2880, era una vulnerabilidad de alta gravedad que permitía eludir los controles de autorización en el módulo opcional @fastify/middie , en el que el middleware con ámbito de ruta podía omitirse porque el complemento normalizaba las rutas de solicitud de forma diferente al enrutador. La corrección está disponible en middie 9.2.0, y la línea 9.x se desarrolla para Fastify v5. La línea 8.x, en la que se ejecutan las aplicaciones v4, se detuvo en la versión 8.3.3 en septiembre de 2024 y nunca recibió la corrección.

Nada de esto parece que vaya a ralentizarse. OpenJS informa en su actualización del segundo trimestre de 2026 que su CNA publicó 3 CVE en la segunda mitad de 2025 y 49 en la primera mitad de 2026, con unas diez más a la espera de ser publicadas. La mayor parte de ese aumento se debe a una clasificación más rigurosa y a un análisis asistido por IA, más que a una oleada repentina de nuevos errores, pero el efecto sobre una línea de productos al final de su vida útil es el mismo en cualquier caso. Más revelaciones, ninguna de las cuales afecta a tu versión.

El entorno de ejecución subyacente tiene su propio reloj

Fastify v3 se ha comprobado con Node.js 10 a 18, versiones todas ellas que ya han llegado al final de su vida útil (EOL). Los equipos siguen utilizando versiones antiguas de Fastify porque actualizar resulta caro, y la misma presión presupuestaria que les obliga a quedarse ahí suele hacer que también sigan utilizando una versión antigua de Node. En el caso de un servicio v3, esto suele suponer dos versiones que ya han dejado de recibir soporte hace años, y es el entorno de ejecución el que presenta una superficie de ataque más amplia, desde el análisis de TLS y HTTP hasta las redes y todo lo demás que se encuentra por debajo del código de la aplicación.

Esta es la verdadera razón por la que los equipos se atascan, y rara vez es culpa del marco de trabajo. Nadie define el alcance de «actualizar el marco de trabajo web» como una migración en tiempo de ejecución más un cambio de imagen base más una recompilación de módulos nativos. Pero cuando alguien lo hace, la estimación se triplica y la tarea se aplaza al siguiente trimestre.

Cuando las restricciones de dependencia te limitan

El árbol de Fastify es realmente ligero, y conviene reconocerlo. A partir de la versión 5.12.0 de Fastify, la instalación de la versión 5 incluye 15 dependencias directas de tiempo de ejecución: avvio, find-my-way, fast-json-stringify, light-my-request, pino, secure-json-parse, semver, rfdc, toad-cache, process-warning, registro-abstracto, y cuatro paquetes @fastify/* . Para ser un marco de trabajo web, se trata de un conjunto de dependencias directas realmente reducido.

El hecho de alcanzar el fin de vida útil (EOL) no congela por sí solo ese árbol, y conviene ser preciso sobre lo que ocurre realmente. Fastify declara rangos de semver, y npm actualiza las dependencias a versiones más recientes que sigan cumpliéndolos, por lo que llegan numerosas correcciones de seguridad de los desarrolladores originales sin que nadie tenga que tocar Fastify. El problema es más concreto y más molesto que un árbol congelado. Cuando la única versión corregida se encuentra fuera del rango que acepta tu línea de Fastify, instalarla implica una anulación, un cambio directo en las dependencias o una actualización del marco de trabajo con la que tu versión nunca se ha probado.

Así que tu escáner detecta una advertencia transitiva y la solución más limpia resulta ser «actualizar Fastify», que es precisamente lo que intentabas evitar. Para una aplicación de la versión 3, eso suele implicar una actualización de Node.js, además de cambios en el esquema y la API, no una simple versión de parche. Esa diferencia es la que hace que una auditoría limpia se convierta en un trimestre de discusiones con tu equipo de seguridad sobre el riesgo aceptado frente a los falsos positivos.

Tus opciones tras el fin de la vida útil de Fastify

Hay tres opciones, y cuál es la más adecuada tiene menos que ver con las preferencias técnicas que con la versión que estés utilizando realmente y con el tiempo del que dispone tu equipo este trimestre.

Si te identificas con esto	Haz esto
Se está utilizando la versión 3 o la versión 4 en un entorno regulado, sin margen para llevar a cabo una migración del entorno de ejecución y del marco de trabajo este trimestre	Soporte ampliado para tu versión actual; después, realiza la migración cuando te convenga.
Ya está disponible en una versión compatible de Node.js, con pocas API obsoletas y complementos mantenidos	Actualiza ahora a la versión 5
El marco no resulta adecuado más allá del problema del fin de vida útil	Sustitúyelo y haz un presupuesto adecuado

 Soporte técnico de ciclo de vida ilimitado de TuxCare

El servicio «Endless Lifecycle Support» (ELS) de TuxCare cubre entornos de ejecución, bibliotecas y marcos de trabajo de código abierto que han llegado al final de su vida útil (EOL). Proporciona parches de seguridad adaptados a versiones anteriores para aquellas que el proyecto original ya no mantiene, a través de la gestión estándar de paquetes, lo que reduce al mínimo los cambios en su proceso de implementación. En el caso concreto de Fastify, las versiones cubiertas son la 3.29.5 y la 4.29.1, las últimas versiones de las líneas v3 y v4. Las correcciones llegan a través de npm y se registran públicamente en el CVE Tracker de TuxCare, de modo que su equipo de seguridad pueda ver exactamente qué está cubierto antes de dar el visto bueno.

Para un equipo que se encuentra atascado en una línea de Fastify al final de su ciclo de vida (EOL), ya sea una flota de v4 que haya superado el plazo de soporte a largo plazo (LTS) hace un año o una flota de v3 que lo haya superado hace tres años, esto supone la adquisición de correcciones de seguridad continuadas para la versión que ya está en producción, en lugar de un salto forzado a la v5 que conlleva una actualización de Node.js que abarca varias versiones. Además, permite disponer de documentación sobre los parches que se puede presentar en una auditoría SOC 2 o PCI DSS, así como de un calendario de migración que se establece uno mismo, en lugar de uno dictado por un calendario de divulgación o por las conclusiones de un auditor.

Los equipos que acaban en esta situación no son vagos. Se enfrentan a limitaciones reales: restricciones de compatibilidad entre plataformas, recursos de ingeniería ya asignados a otras tareas, la complejidad de las pruebas en docenas de servicios o normas regulatorias que convierten una actualización no planificada del marco de trabajo en un problema de control de cambios en lugar de uno técnico. Para un servicio de la era v3, esto suele parecerse más a un cambio completo de plataforma que a un simple cambio de versión.

El papel de TuxCare en este caso es actuar como puente, manteniendo actualizada la versión de Fastify cubierta mientras la migración se lleva a cabo según tu propio calendario, en lugar de según el del proyecto original.

Actualizar a Fastify v5

Es la decisión acertada si te lo puedes permitir, y en el caso de una flota en v4, el salto es menor de lo que suele ser en la mayoría de las actualizaciones de versión principales. La propia guía de migración de Fastify es realmente breve. Para una flota de v3, hay que presupuestar algo más parecido a un cambio de plataforma, ya que hay que gestionar dos versiones principales de API obsoletas, además de un cambio de entorno de ejecución desde cualquier línea de Node en fin de vida útil en la que se encuentre actualmente el servicio a una que cuente con soporte.

Hay cuatro factores que determinan la estimación. El primero es el entorno de ejecución, ya que la versión 5 requiere Node.js 20 o una versión posterior, y ese requisito es innegociable. Dado que Node 20 llegará al final de su vida útil (EOL) en abril de 2026, una migración nueva debería realizarse a una versión LTS que cuente actualmente con soporte, lo que a finales de 2026 significaría Node 24 en lugar de quedarse en la 20.

El segundo es un esquema JSON completo. El opción «jsonShorthand» ha desaparecido y, al utilizar el validador predeterminado, querystring, params, bodyy respuesta deben contener objetos de esquema completos, incluyendo el propiedad «type» .

El tercer punto son las API eliminadas. Fastify v5 ha eliminado las API que quedaron obsoletas a lo largo del ciclo de vida de la v4, por lo que las advertencias de obsolescencia que has ido pasando por alto en tus registros son un buen punto de partida para la lista de tareas. Si vienes de la v3, eso supone dos ciclos de obsolescencia que hay que revisar, en lugar de uno solo.

El cuarto es la compatibilidad con los complementos. Cada @fastify/* y los complementos de la comunidad necesitan una versión compatible con la v5, y aquí es donde suele producirse el retraso en el calendario. El retraso es mayor en el caso de los conjuntos de complementos más antiguos que nadie ha actualizado desde 2022.

Si tu conjunto de plugins es íntegramente propio y se mantiene de forma activa, y vienes de la versión 4, el trabajo suele limitarse a lo esencial. Si vienes de la versión 3, o si tienes plugins de la comunidad que dejaron de actualizarse hace años, evalúa primero el alcance del trabajo de sustitución. Esa es la parte que puede convertir una actualización sencilla en un proyecto de migración considerablemente más amplio.

Sustituir Fastify

Cambiar de framework para resolver un problema de fin de vida útil (EOL) suele ser casi siempre más costoso que actualizar, y esto se acentúa aún más a partir de la versión 3, en la que, de cualquier modo, ya te enfrentas a una reescritura importante. Express 5, Hapi y Hono son todos frameworks razonables, pero pasar a cualquiera de ellos puede suponer un trabajo adicional considerable en el registro de rutas, los hooks y el middleware, la validación, los plugins y el código de la aplicación específico del framework. Eso es una reescritura disfrazada de actualización. Hazlo si Fastify realmente no es la opción adecuada para ti, no porque la versión haya llegado al fin de su vida útil (EOL).

Protege Fastify más allá de su fin de vida útil con TuxCare

Fastify v3 llegó al final de su soporte a largo plazo (LTS) en junio de 2023, y la v4 lo hizo en junio de 2025. Ninguna de estas fechas constituía por sí sola un evento de riesgo. El riesgo es el intervalo que va desde la fecha que corresponda a tu flota hasta el día en que tu último servicio en fin de vida útil (EOL) se implemente en una plataforma compatible; y, para muchos equipos, ese intervalo se mide, en el mejor de los casos, en trimestres y, en el peor, en años.

Hay dos formas de resolverlo. Pasar ahora a la versión 5 y asumir la actualización en tiempo de ejecución que conlleva, o seguir aplicando parches a la versión que ya tienes en funcionamiento —incluidas las 3.29.5 y 4.29.1— mientras realizas la migración según un calendario que tú mismo controles. Ambas son posturas defendibles. Seguir utilizando una versión fuera de ciclo de vida (EOL) y cruzar los dedos no lo es.

Si te encuentras en ese segundo grupo, el servicio «Endless Lifecycle Support» de TuxCare se encarga de mantener los marcos y entornos de ejecución fuera de ciclo de vida (EOL), incluidos Fastify 3.29.5 y 4.29.1, actualizados y listos para auditorías durante todo el tiempo que la empresa los necesite.

Preguntas frecuentes