(~10 years NixOS user, and committer.)

It depends.

Mostly on how much rebuilding it needs (e.g. if it's a "leaf" package, or one many packages depend on).

The merging of security fixes is usually very good, also because it is so easy for anyone to just make a PR.

The security team also seems pretty competent and fast.

As a sibling commenter says, it is also extremely easy to just apply patches to your own system in general, usually with a few line of easy code max. So you can fix systems without dependence on distro maintainers.

In contrast to e.g. patching a `.deb`, you can declare the code such that the patch will still be used even if the distro releases a new package; you can carry the patch forward, and don't need to choose between {not having the patch because the distro lacks it} and {not having future security fixes because you pinned your custom .deb version}. NixOS will rebuild any future update, applying your patch to it. That's a big benefit, because it makes "out-of-tree" custom patches very maintainable.

Due to declarativeness, you can easily roll out your fix on lots of machines.

Also, the "SBOM" (software bill of materials) part is quite good in NixOS. It's very easy to determine which package uses what dependencies.

The only real drawback is CI build time when a high-dependency package needs fixing.

Due to the way Nix works with its immutable hash DAG of package dependencies, a package change will trigger a full rebuild of all packages that recursively depend on it.

For example, if you change 1 line in glibc, or libpng, or curl, or (recently) brotli, the entire distro needs to be recompiled from source ("rebuild the world"). Some of the packages, such as Chromium, can take many hours to rebuild individually. Rebuilding all-of-NixOS can take days.

In distros that can mutate packages without triggering dependency rebuilds, updating 1 line in e.g. glibc, will only rebuild that package, allowing to theoretically distribute such security updates within minutes (if done, see Ubuntu counter-example).

The mass-rebuilding is done by NixOS's binary-cache build farm. A new NixOS update is generally only released once the build farm has fully built all dependents. (One can also opt into a "small" channel that releases as soon as only a few core packages are built, which gives you security updates faster for those. But if you do that, your computer will next start compile all huge packages such as Chromium, in parallel to the NixOS build farm already doing that. So usually people don't.)

For the recent brotli CVE-2026-111497, the timline was:

    2026-10-21       node.js releases its fix for node2shell (caused by brotli)
    2026-10-21 19:27 https://github.com/google/brotli/releases#release-v1.2.1
    2026-10-22       brotli CVE-2026-111497 gets published
    2026-10-22 06:51 PR "brotli 1.2.1" https://github.com/NixOS/nixpkgs/pull/577208
    2026-10-22 08:25 PR merged to "staging" that will become rolling "nixos-unstable" in the future
    2026-10-23       created https://tracker.security.nixos.org/suggestions/by-id/60353
    2026-10-23       created https://github.com/nixos/nixpkgs/issues/577796
    2026-10-28       CI has built a nixos-26.05 update that includes it:
                     https://hydra.nixos.org/build/351243680
                     This is the point where users can install it.
    2026-11-02       CI for rolling-release nixos-unstable is still not built, 2 weeks later:
                     https://github.com/NixOS/nixpkgs/pull/577208#issuecomment-6573335016

So in summary:

    The PR got made within 7 h
    Review and merge happened within 2 h
    CI took additional 6 days for stable NixOS 26.05
    CI for rolling nixos-unstable is still not finished after 10 days post-merge

For our startup, I rebuilt the slice of the world we use on a 16-core CPU within a day or so, without waiting on the NixOS build farm to build all of NixOS, so we got the update significantly faster.

Also note that just patching a library in your distro is often not enough. For brotli, lots of upstream package vendor brotli's code. NixOS contributors seem to be quite good at looking at underlying issues, e.g. there's this issue "Tracking vendored Brotli decoders" (https://github.com/NixOS/nixpkgs/issues/578375) to track that. I am not aware of other distros making such efforts.

Thus:

In NixOS, security updates are great and fast for leaf packages such as the kernel, but can be slow for many-dependents packages. Much of that can be mitigated by building things yourself, which is easy.

Hope this helps.