Security Fixes We’ve Delivered to Unsupported Fastify Versions
Covered Fastify Versions
|
|
|
|
|---|---|---|
|
|
Unsupported since June 30, 2023 |
|
|
|
Unsupported since June 30, 2025 |
|
*EOL dates are based on the published Fastify LTS schedule.
What You Get with ELS
Security Fixes After Upstream Support Ends
When a new CVE lands against a covered release, TuxCare backports and tests the fix, so the finding can be closed without a jump to a new major version.
Any fixes already delivered for your covered release are available as soon as your project connects to the ELS registry.
Patch Fastify Without Rebuilding Your App
ELS replaces unsupported Fastify with a TuxCare maintained equivalent that preserves the API, plugin behavior, and hook order your service already expects.
Patched packages arrive through the TuxCare npm registry and fit the workflow you already have, from dependency resolution to Docker images and CI/CD builds.
Support That Holds Up to Review
Patch Delivery Backed by SLA
When auditors ask how an unsupported framework gets patched, you point to a contractual SLA aligned with SOC 2, PCI DSS, HIPAA, NIS2, DORA, and the CRA.
Enterprise Support Guarantees
ELS is built for enterprise use, with commercial terms and contractual protections beyond community best effort maintenance.
Add patched Fastify through npm without changing your application code
Point npm at the TuxCare registry, update how the package resolves, then reinstall your dependencies. The TuxCare Patcher can make those edits for you.
A head start on Fastify security
Start with the fixes already published for your covered release and keep receiving patches as new applicable CVEs appear.
| CVEs | Product | Component | Severity | Status | Published |
|---|---|---|---|---|---|
| CVE-2026-6270 Direct | Fastify | fastify-middie 8.3.3 | Critical | Patch available | |
| CVE-2026-25223 Direct | Fastify | fastify 4.29.1 | High | Patch available | |
| CVE-2026-25224 Direct | Fastify | fastify 4.29.1 | Low | Patch available | |
| CVE-2026-33804 Direct | Fastify | fastify-middie 8.3.3 | High | Patch available | |
| CVE-2026-3635 Direct | Fastify | fastify 4.29.1 | Medium | Patch available | |
| CVE-2026-2880 Direct | Fastify | @fastify/middie 8.3.3 | High | Patch available | |
| CVE-2024-47764 Transitive | Fastify | fastify 3.29.5 | Medium | Patch available |
Browse all Fastify vulnerabilities with our CVE Tracker →
Ask a Fastify Security Specialist
Talk through where legacy Fastify sits in your stack, what it pulls in, and the cleanest route to maintained packages.
How Teams Use ELS
Quiet the scanner
⚠️ The bind:
One service sits on Fastify 3, another on Fastify 4, and neither can jump to a new major in the same quarter.
🔄 The turn:
ELS patches each covered release independently, so every service keeps the exact version it was built against while the findings get closed.
Close an open audit finding
⚠️ The bind:
Internal audit, SOC 2, or a customer security review flags Fastify as unsupported, and upstream no longer guarantees a patch path.
🔄 The turn:
ELS supplies maintained packages under a contractual SLA, which gives reviewers a documented remediation path instead of an open item.
Modernize when the roadmap is ready
⚠️ The bind:
Moving to Fastify 5 means retesting plugins, schemas, hooks, Node.js compatibility, and application behavior all at once.
🔄 The turn:
ELS keeps covered releases patched while the team validates the newer major release at its own pace.
Why TuxCare?
From the Team That Extends Open-Source Lifecycles
TuxCare keeps essential components protected long after upstream support ends, from the Linux kernel to language runtimes and frameworks like Fastify. One partner, broad open source coverage.
Founding platinum sponsor of the AlmaLinux OS Foundation and member of the Open Source Security Foundation (OpenSSF).
TuxCare invests in the open-source projects it secures, from JavaScript build tooling to Linux, and beyond.
Learn more →
Related Insights
The CRA Expects Due Diligence on Open Source Code You Didn’t Write
Key Takeaways Article 13(5) of the Cyber Resilience Act (CRA) requires due diligence on…
November 11 Node.js Security Updates for Supported and End of Life Versions
ELS Builds for the November Node.js Fixes Are Planned for Release Day Fixed builds…
Top 5 Patch Management Tools in 2026: Full Review
Key Takeaways Patch management tools often look alike on a feature list, but they…
Keep running out-of-support Fastify with ongoing CVE fixes.
Get continuous CVE fixes for Fastify 3.29.5 and 4.29.1 through the npm workflow you already use.
Ask Us a Question
Frequently Asked Questions
No. Fastify 3 reached the end of upstream LTS on June 30, 2023, and Fastify 4 followed on June 30, 2025, which leaves Fastify 5 as the current major line. Community contributed fixes are still reviewed upstream, but nothing guarantees one for any given CVE. TuxCare ELS provides ongoing security patches for Fastify 3.29.5 and 4.29.1.
Use a maintained replacement for the version your service already expects. Add three registry lines to your project .npmrc, point the Fastify dependency at the TuxCare package, and reinstall. CVEs get remediated without taking on a framework migration at the same time, and routes, hooks, decorators, and plugin registration stay as they are.
ELS covers Fastify 3.29.5 and 4.29.1, the final release of each line. Fastify 3 left upstream LTS in June 2023 and Fastify 4 in June 2025, so new security issues affecting either no longer have a guaranteed upstream patch path. If your service pins a different release, contact TuxCare to discuss coverage.
When a disclosed CVE affects a covered release, TuxCare evaluates it and backports the required fix where feasible. Fastify history already includes denial of service through crafted Content-Type headers and a CORS preflight bypass, the sort of finding that surfaces in a scan long after a service stops changing.
Yes. ELS includes security fixes for covered direct and transitive dependencies, so remediation is not limited to the top level Fastify package. TuxCare documents a package.json overrides entry for nested copies, the Patcher writes it for you, and support can confirm the right method if your project builds on an older npm.
No. Adopting the TuxCare maintained package is a dependency resolution change made through the TuxCare npm registry. Your route definitions, lifecycle hooks, schemas, and plugin tree behave exactly as before.
Yes. ELS packages resolve through npm from the TuxCare registry, so they fit Docker builds, CI/CD pipelines, and existing deployment workflows. The change happens in dependency resolution rather than in your application logic.
ELS is designed to support vulnerability remediation requirements under frameworks including SOC 2, PCI DSS, HIPAA, NIS2, DORA, and the CRA. A contractual patching SLA gives auditors a documented remediation path for an otherwise unsupported framework.
Upgrade when the engineering case makes sense. ELS keeps covered releases patched while you test plugins, runtime requirements, schemas, and application behavior on the newer major, so the migration follows your roadmap instead of the next CVE.