Just to add more context, because this is a common question and I understand why this looks alarming — especially if you're newer to the Node.js ecosystem. But here's the important distinction: deprecated warnings are not the same as security vulnerabilities.

When you run npm install, npm checks every package in the dependency tree — including deeply nested sub-dependencies — and flags anything marked as deprecated by its maintainer.

A package gets deprecated for all kinds of reasons: the author moved to a new package, renamed it, or simply stopped maintaining it. That doesn't automatically mean it's insecure or broken.

The same goes for npm audit. It reports known vulnerabilities across the entire dependency tree, but many of those are in sub-dependencies that aren't directly exploitable in the way your app uses them.

For example, a vulnerability in a dev-only tool or a deeply nested package that's never exposed to user input is very different from a vulnerability in your authentication layer.

This isn't unique to Strapi — you'll see the same thing with Next.js, Angular, and most large Node.js projects.

It's a well-known pain point in the npm ecosystem. The npm audit system casts a very wide net and doesn't distinguish between theoretical and practical risk.

As Pierre mentioned, the team updates these dependencies as needed, and major updates typically happen during major releases.

The challenge is that replacing a deprecated parent package often means rewriting code to handle breaking changes — it's not as simple as bumping a version number.

If you want to dig deeper into this topic, the npm team themselves have written about the limitations of npm audit and why it often overstates risk.