Kali Linux 2020.1 to 2026.2: Every Quarterly Release and What Changed

Kali Linux shipped 26 quarterly releases from Kali 2020.1 (28 January 2020, kernel 5.4, Xfce 4.14.2) to Kali 2026.2 (29 June 2026, kernel 6.19, Xfce 4.20.7). The biggest security changes were the non-root default user in 2020.1 and a new archive signing key in April 2025. There is no 2026.3 yet.

Kali is a Debian testing based rolling distribution built for authorised penetration testing, forensics and security research. Use it only on systems you own or have written permission to test. Below: every release's date, kernel and desktop, what changed from the release before, and the defaults a security team should know about. Every fact comes from kali.org/releases, the Kali release posts or the Kali documentation, fetched on 23 October 2026. Where those pages say nothing, we say so.

Key takeaways

• Root by default ended in 2020.1. From Kali 2020.1 the default account is a standard unprivileged user. Live images run as user kali; installs prompt you to create a user in the sudo group. Kali's own words: "root/toor is dead."
• A versioned release every quarter. Kali's update guide says it releases "four times a year" on "a loose quarterly schedule." The period covered here has four releases per year from 2020 to 2025 and two so far in 2026.
• The kernel moved from 5.4 to 6.19. Kali's releases page lists kernel 5.4 for 2020.1 and 6.19 for 2026.2. Kali held 2026.2 on 6.19 rather than 7.0 to avoid breaking NVIDIA driver users, with 7.0 available in kali-rolling.
• Xfce has been the default desktop throughout. Xfce has been the default since 2019.4. It went from 4.14.2 in 2020.1 to 4.20.7 in 2026.2, with GNOME and KDE Plasma offered as alternatives.
• Some defaults are deliberately weak, for testing. OpenSSL (from 2021.3) and the Samba client (from 2021.4) accept legacy protocols by default; SSH stays secure by default.
• The archive key changed in April 2025. Kali lost access to its repository signing key and rolled a new one. Every existing install needed the new keyring before apt update would work again. Kali reissued its images as 2025.1c.
• New editions arrived. NetHunter Rootless (2020.1), the Everything image (2022.1), NetHunter Pro (2022.4) and the Kali Purple technical preview for defensive work (2023.1).
• Authorised use only. Kali says it is not a general purpose desktop, and misusing its tools without authorisation has legal consequences.

Every Kali release from 2020.1 to 2026.2

The table below lists every release on Kali's releases page from 2020.1 to 2026.2, including the minor "a", "b" and "c" fix releases. Dates, kernels and Xfce versions are as the releases page states them. The headline column is the subtitle Kali gave each release post.

"Not stated" means the releases page gives no kernel or Xfce version for that minor release, and its post (where one exists) does not either. The minor releases are rebuilt images, not new package sets: Kali describes them as bug fix or "no fanfare" releases.

One small inconsistency: the releases page lists "Kali 2025.1 - 19th March, 2025", but the release post at the 2025.1 address is titled "Kali Linux 2025.1a Release" and explains that "a last minute bug" in a package forced a rebuild after the images were produced. We use the releases page entry and note that the shipped images were named 2025.1a. The releases page has no separate 2025.1a row.

Desktop versions beyond Xfce

GNOME and KDE Plasma are offered at install time as alternatives to Xfce. Kali's 2026.2 post says they get a major update "roughly every six months, every other Kali release." The release posts name GNOME 41 and KDE Plasma 5.23 in 2021.4, GNOME 42 and Plasma 5.24 in 2022.2, GNOME 43 and Plasma 5.26 in 2022.4, Plasma 5.27 in 2023.1, GNOME 44 to 47 across 2023.2, 2023.4, 2024.2 and 2024.4, Plasma 6.2 in 2025.1, GNOME 48 and Plasma 6.3 in 2025.2, GNOME 49 and Plasma 6.5 in 2025.4, and GNOME 50 and Plasma 6.6 in 2026.2. The 2025.4 post adds that GNOME is now Wayland only and that Kali's KDE has used Wayland by default since 2023.1.

What changed from release to release

This is the "what changed versus the previous release" view. Each row lists the change in that release that most affects how Kali behaves, from the release post.

The rest of this post goes through the changes that matter most for security, in order.

2020.1: the default non-root user

Kali announced the change in a post on 31 December 2019, and shipped it in Kali 2020.1 on 28 January 2020. The 2020.1 post puts it plainly: "the default credentials have been root/toor. This is no more." The default account is now "a standard, unprivileged, user."

Why Kali ran as root before

The December 2019 post explains the history. BackTrack versions 1 to 4 were live distributions run from a CD, with "no real update mechanism," and many tools of that era needed root or ran better as root. An "everything as root" model "made complete sense for the time." Kali inherited that policy when it launched in March 2013 as an official Debian derivative.

Kali's older root user policy page, now marked as dated, adds that many tools "can only run with root privileges" and multi-user use was "highly unlikely."

Why it changed

The post gives two reasons: the number of tools that need root "has dropped over the years," and more applications refuse to run as root, which was "a maintenance burden" for Kali.

What the change looks like in practice

From the December 2019 post and the current Kali user policy page:

• Live images run as user kali with password kali. The post itself predicted that bots would soon scan for that pair. If a live or prebuilt VM image will ever touch a network you do not control, change that password first.
• Installs prompt you to create a non-root user that gets administrative rights through membership of the sudo group, "the same process as other Linux distros."
• Privilege escalation uses sudo on the command line and pkexec for graphical and command line prompts. Tools that need root ask for it when started from the Kali menu.
• Tools behave differently without root. The user policy page gives the example of a network scanner that falls back to a slower scan type when it cannot open raw sockets without root.
• The old model is opt in. Kali provides a kali-grant-root package for people who want password-less root. The 2019 post's framing: "If you really don't care about security." For a machine you take onto a client network, leave it alone.

Why it matters

A default root session means any bug in any program you run, including a browser opening a client's web application, runs with full privileges. A non-root default puts sudo between a mistake and the system, and brings Kali in line with your other Linux machines.

Security relevant defaults that changed in this era

Several Kali releases changed defaults in ways that help testing and would be wrong on a general purpose system. Know which way each one is set before you take a Kali machine onto a network.

Privileged ports (2021.2) and dmesg (2023.1)

Kali 2021.2 patched its kernel so that a normal user can bind to TCP and UDP ports below 1024. The reasoning: people were running programs with sudo just to get a low port, which "defeats the point of switching to non-root user." The change only applies where Kali's own kernel runs, not in cloud instances, Docker or WSL that use another kernel.

Kali 2023.1 listed this as a kernel default ("No more privileged ports") alongside a second one: dmesg is now readable without root. Both can be changed in kali-tweaks.

OpenSSL wide compatibility (2021.3)

From Kali 2021.3, OpenSSL is configured "for wider compatibility," with TLS 1.0, TLS 1.1 and older ciphers enabled by default so testers can talk to old systems. Kali's own post says this "is not a configuration that would be good for a general purpose operating systems." To revert it, open kali-tweaks, go to the Hardening section and choose Strong Security for OpenSSL.

Samba client wide compatibility (2021.4)

Kali 2021.4 set the Samba client to Wide Compatibility, so it can connect to servers that use old protocol versions. In kali-tweaks, Hardening, choosing Default reverts to Samba's normal setting of modern protocol versions only.

SSH client: secure by default (2022.1 and 2024.4)

SSH went the other way. Kali 2022.1 added a kali-tweaks option to enable old SSH algorithms and ciphers, but the post states this weaker behaviour is "NOT enabled by default, as SSH is a sensitive enough component that we prefer to keep it Secure by default." Kali 2024.4 shipped OpenSSH 9.8p1, which removes DSA key support; the post describes the default client as configured "with security in mind," with legacy ciphers off unless you change the kali-tweaks setting.

Python packages and pip (2023.1 and 2024.4)

Kali 2023.1 warned that Python's PEP 668 change was coming: installing packages system wide with pip would be refused with an "externally-managed-environment" error. Kali's advice was to prefer the Debian packaged Python module through APT, or use a virtual environment. With Kali 2024.4 Python 3.12 became the default interpreter and pip installs into the system Python were "disallowed by default." Tools installed with pip into a virtual environment are outside what Kali and Debian maintain, and need their own tracking.

Network services do not persist by default

Older than 2020 but still in force: Kali's network service policy says Kali "does not enable any externally-listening services by default" and will "disallow network services from persisting across reboots." If you install a package that starts a network service, it will not come back after a reboot unless you enable it with systemctl.

Kali Purple and the other editions introduced in this era

Kali Purple (2023.1)

Kali 2023.1, published on Kali's tenth anniversary, introduced Kali Purple as "an initial technical preview pre-launch." It is Kali's first move into defensive security. The post describes it as starting "as a Proof of Concept, evolving into a framework, then a platform." It contains:

• a reference architecture for a "SOC In-A-Box" for learning, SOC analysis practice and team exercises;
• over 100 defensive tools in categories such as full packet capture and analysis, security information and event management, vulnerability scanning, incident response case management, network traffic analysis and intrusion detection;
• a defensive menu organised by the NIST Cybersecurity Framework functions Identify, Protect, Detect, Respond and Recover;
• Kali Autopilot, a framework for scripting attack scenarios so blue teams can practise detection;

The 2023.1 post says Kali Purple "is still in its infancy." The pages we fetched state no general availability date.

NetHunter editions (2020.1) and NetHunter Pro (2022.4)

Kali 2020.1 split Kali NetHunter, its mobile platform, into three editions:

• NetHunter: needs a rooted device with a custom recovery and patched kernel; no restrictions.
• NetHunter Light: rooted device and custom recovery but no custom kernel; no wireless injection or HID support.
• NetHunter Rootless: installs on stock, unmodified devices through Termux, with no root permissions and other limits.

Kali 2022.4 launched Kali NetHunter Pro, "a bare metal installation of Kali Linux" with the Phosh mobile desktop, starting with the PinePhone and PinePhone Pro.

The Everything image (2022.1)

Kali 2022.1 added a "kali-linux-everything" ISO with every tool preinstalled, about 9.4 GB at launch and distributed over BitTorrent only. By 2025.4 Kali gave its size as 13 GB (installer) and 15 GB (live).

Single installer, live and netinstaller images (2020.1)

Before 2020.1 Kali published separate images for each desktop. Kali 2020.1 replaced them with an installer image (offline install, pick your desktop and tool set at install time), a live image and a network installer. From 2025.4 the live image is also BitTorrent only, because it grew past the roughly 5 GB limit of the CDN that serves direct downloads.

The archive signing key change: 2025.1c

On 28 April 2025 Kali published "A New Kali Linux Archive Signing Key." The short version, in Kali's words: "we had to roll a new signing key for the Kali repository." The reason: "We lost access to the signing key of the repository, so we had to create a new one."

What happened

• Kali froze its repository from Friday 18 April 2025, so no one received packages signed with a key they did not yet trust.
• The new key, "Kali Linux Archive Automatic Signing Key (2025)," has fingerprint 827C8569F2518CC677FECA1AED65462EC8D5E4C5. Kali's post shows it was created on 17 April 2025 and expires on 17 April 2028.
• When the repository unfroze, any Kali system without the new key would fail apt update with a "Missing key" error and keep using old package indexes.
• The new keyring file contains both the old key (ED444FF07D8D0BF6) and the new one (ED65462EC8D5E4C5).

Was the old key compromised?

Kali says no. Its Q and A section answers that if the key had been compromised "we would have removed it and provided a revocation certificate." The new key is signed by Kali developers, with signatures published on the Ubuntu OpenPGP keyserver. The post also recalls that in 2018 Kali had accidentally let its key expire.

What users had to do

Install the new keyring by hand, once, on every existing system: download Kali's archive keyring to /usr/share/keyrings/kali-archive-keyring.gpg and check its checksum against the value in the post. The exact commands are in the walkthrough below. Alternatively, reinstall from the new 2025.1c images, which are "the exact same images" as 2025.1 with the new keyring. Weekly images from 2025-W17 also contain it, and Kali updated its NetHunter, VM, cloud, Docker and WSL images.

Why it matters beyond Kali

An archive key is a trust root for every package on the machine. Kali froze first, published the fingerprint, kept the uncompromised old key and reissued images. The lesson for your own fleet is to know which machines and images pin which keys: a Kali VM image built before 28 April 2025 will fail to update until its keyring is replaced.

Architectures and transitions Kali followed from Debian

Kali is based on Debian testing. Its 2024.2 post explains that "all the work done in Debian is incorporated in Kali pretty quickly after it lands in Debian testing," and that packages which break are held in kali-dev until the Kali team fixes them. Several releases in this period reflect Debian changes rather than Kali decisions:

• t64 (2024.2). Debian moved 32 bit architectures to a 64 bit time_t to avoid the year 2038 overflow.
• GCC 14, glibc 2.40 and Python 3.12 (2024.3). These slowed updates into kali-rolling for about two months.
• i386 (2024.4). Debian stopped building an i386 kernel and images in October 2024, so Kali did too. i386 packages remain in the repository and can still run on a 64 bit system.
• ARMel (2025.3). Debian 13 "trixie" is the last Debian release with ARMel, and Debian testing no longer builds it. Kali dropped ARMel, which affected the original Raspberry Pi 1, Raspberry Pi Zero W and ODROID-W.

Platforms: where Kali runs

Kali's download documentation groups official images into ISO files for Intel based PCs, virtual machine images and ARM images, and lists further platforms in its docs. This table shows each platform type and the releases in this period that changed it.

Containers

Kali's container documentation says its official Docker images are "updated once a week." The main image, kalilinux/kali-rolling, tracks kali-rolling "just like the default images." kalilinux/kali-last-release tracks kali-last-snapshot and "will not get any update until the next release." There are also bleeding-edge, experimental and kali-dev images for special cases. None of the images include the default tool metapackage; Kali's docs say to install kali-linux-headless yourself.

A container built on kalilinux/kali-rolling is a snapshot of the week you built it, so rebuild it to pick up fixes. It also runs on the host's kernel, not Kali's.

Kali 2026.3: not released as of 23 October 2026

Kali's releases page, checked on 23 October 2026, lists Kali 2026.2 (29 June 2026) as the latest release. The address that a 2026.3 release post would use returned 404 when we checked. The last release in this series is therefore Kali 2026.2. We make no prediction about when 2026.3 will ship; Kali's update guide describes the schedule only as "a loose quarterly schedule."

On kali-rolling, a versioned release matters less than it sounds: your system already has whatever was in rolling when you last updated.

Kernel choices and the 2026.2 decision

Some kernels span several releases on Kali's releases page: 5.10 for 2021.1 to 2021.3, and 6.12 for 2025.1 to 2025.3.

The 2026.2 post is the only one in the period that explains a kernel decision in detail. Kali wanted to ship the newest kernel because of recent kernel vulnerability disclosures, which the post names as "Copy Fail" (CVE-2026-31431) and "Dirty Frag" (CVE-2026-43284 and CVE-2026-43500). But when kernel 7.0 reached Debian there were reports of incompatibility with NVIDIA's DKMS drivers. Kali shipped 6.19 in the images and made 7.0 available in kali-experimental and kali-rolling.

We have not checked those CVE identifiers against NVD for this post; we cite them only as Kali's post states them. The practical point: a release image's kernel is a starting point. On Kali, apt full-upgrade moves you to whatever kernel kali-rolling carries, and the running kernel only changes after a reboot.

Authorised use only, and tools by category

Kali is a distribution for authorised security testing, forensics and research. Kali's "Should I use Kali Linux?" page says it is "specifically geared towards professional penetration testers and security specialists," and is "NOT a recommended distribution" for people new to Linux or looking for a general purpose desktop. The 2020.1 post, even after the non-root change, still did not encourage Kali as a daily driver: "we just don't encourage it. We still don't."

The same page warns that "misuse of security and penetration testing tools within a network, particularly without specific authorization, may cause irreparable damage and result in significant consequences, personal and/or legal." Use Kali only on systems you own or have written permission to test. Before any engagement, agree scope and rules in writing. Our guides on what penetration testing is and how to scope a penetration test and define rules of engagement cover what that agreement should contain.

Kali's tools fall into categories such as information gathering, vulnerability analysis, web application testing, password attacks, wireless testing, reverse engineering, exploitation frameworks, forensics and reporting. Kali 2025.2 reorganised its menu to follow the MITRE ATT&CK structure, replacing a layout that Kali says came from BackTrack and WHAX before it. Kali Purple adds defensive categories organised by the NIST Cybersecurity Framework. We do not describe how to use any of them here.

How to check which Kali release you are on and bring it up to date

All commands below come from Kali's release posts and documentation, cited in each step. Do this before an engagement, not during one: Kali's update guide says to make sure your tools work before you start, and not to update mid engagement because "once in a while issues will sneak into rolling."

Step 1: Check the Kali version

Kali's release posts use this check after upgrading:

grep VERSION /etc/os-release

On a current system, VERSION and VERSION_ID show the release (for example 2026.2) and VERSION_CODENAME shows kali-rolling.

Step 2: Check the running kernel

The release posts use uname -v, and the 2021.2 post uses uname -r:

uname -r
uname -v

Compare the result with the kernel for your release in the table above. A newer kernel than the table shows is normal on an updated rolling system. An older one after an upgrade means you have not rebooted.

Step 3: Confirm you are on kali-rolling

Kali's update guide says to check the APT sources file first:

cat /etc/apt/sources.list.d/kali.sources

Expect Suites: kali-rolling and Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg. Systems installed before 2026.2 keep the old one line format; the 2026.2 post says existing systems "won't be changed" and both formats work:

cat /etc/apt/sources.list

That file should contain a single deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware line. If you see kali-last-snapshot instead, you are on the frozen branch and will get nothing until the next versioned release.

Step 4: Confirm you have the 2025 archive key

From Kali's archive signing key post:

gpg --no-default-keyring --keyring /usr/share/keyrings/kali-archive-keyring.gpg -k

The output should list the key 827C8569F2518CC677FECA1AED65462EC8D5E4C5, "Kali Linux Archive Automatic Signing Key (2025)." If apt update fails with "Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5," install the new keyring as Kali's post shows:

sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg
sha1sum /usr/share/keyrings/kali-archive-keyring.gpg

Kali's post gives the expected SHA1 as 603374c107a90a69d983dbcb4d31e0d6eedfc325. Kali has published only that one value in the post we fetched, so a later keyring package may differ; if in doubt, reinstall from a current image.

Step 5: Update to the latest Kali

From Kali's update guide:

sudo apt update
sudo apt full-upgrade -y

Kali says these commands "will upgrade us to the latest Kali version." Reboot, then repeat steps 1 and 2.

If the upgrade includes the polkit update from 2026.2, Kali's post says a reboot is required, and that if graphical applications still will not start as root afterwards, enable the helper socket:

sudo systemctl enable --now polkit-agent-helper.socket

Step 6: Check the hardening settings before you connect to anything

Run kali-tweaks and open the Hardening section. The release posts for 2021.3, 2021.4 and 2022.1 say this is where OpenSSL, the Samba client and the SSH client switch between wide compatibility and strong security. Leave wide compatibility on only for the test that needs it.

Step 7: Verify a new image before you use it

Kali's download documentation says to verify every image. For a torrent download it gives this check, using the checksum file that comes with the torrent:

grep kali-linux-2026.2-live-amd64.iso kali-linux-2026.2-live-amd64.txt.sha256sum | shasum -a 256 -c

For the strongest check, the same page explains how to verify the signed SHA256SUMS file with GPG against Kali's key.

Common mistakes

• Treating a Kali release number as a support window. Kali publishes no fixed support period for a versioned release in the pages we fetched. A 2024.4 install that has never been updated is not "on a supported release"; the supported state is a current kali-rolling system.
• Leaving live or VM default credentials in place. Live images run as kali with password kali, a pair Kali itself expected bots to scan for. Change it on any persistent install or VM that touches a network.
• Restoring root by default out of habit. kali-grant-root exists, but it undoes the main security improvement of the period.
• Forgetting the wide compatibility defaults. OpenSSL and the Samba client accept legacy protocols by default on Kali. That is fine for a test box and wrong anywhere else. Do not copy Kali's configuration to other machines.
• Missing the 2025 key rotation on old images. VM images, containers and cloud snapshots built before 28 April 2025 need the new keyring before they can update. A failed apt update that keeps old indexes is easy to miss in scripted builds.
• Using Kali as a daily desktop or a server. Kali says it is not built for that. Use a general purpose distribution and keep Kali in a VM or on a dedicated machine. Our Ubuntu vs Kali vs Debian comparison covers what to use instead.
• Testing without written authorisation. No release changes this. Get scope and permission in writing first.

FAQ

What is the latest version of Kali Linux?

Kali 2026.2, released on 29 June 2026 with kernel 6.19 and Xfce 4.20.7, per Kali's releases page as of 23 October 2026. There is no Kali 2026.3 on the releases page or the Kali blog yet.

Is Kali Linux 2026.3 out?

Not as of 23 October 2026. The releases page lists 2026.2 as the latest, and the address a 2026.3 release post would use returns 404. Kali's update guide only describes "a loose quarterly schedule," so we do not predict a date.

What kernel does Kali 2026.2 use?

Kernel 6.19. Kali's 2026.2 post says it chose 6.19 over 7.0 because of reports that 7.0 broke NVIDIA DKMS drivers, and that 7.0 is available in kali-experimental and kali-rolling.

When did Kali stop using root by default?

With Kali 2020.1 on 28 January 2020. The default user became a standard unprivileged account that uses sudo. Kali's user policy page says the policy applies "since Kali Linux 2020.1."

How often does Kali release a new version?

Four times a year, on what Kali calls "a loose quarterly schedule." From 2020 to 2025 that meant four main releases a year, plus occasional fix releases.

Is Kali Linux based on Debian or Ubuntu?

Debian. Kali is based on Debian testing and describes itself as an official Debian derivative since March 2013. Its predecessor BackTrack 5 was based on Ubuntu, which Kali's 2019 non-root post mentions. Our Ubuntu vs Kali vs Debian comparison explains the relationship.

Why does apt update fail on Kali with a missing key error?

Most likely your system does not have the archive signing key Kali introduced in April 2025, fingerprint 827C8569F2518CC677FECA1AED65462EC8D5E4C5. Install the new keyring as shown in step 4 above, or reinstall from a 2025.1c or later image.

What is Kali Purple?

A defensive security edition of Kali, introduced as a technical preview in Kali 2023.1. It packages a reference SOC architecture and over 100 defensive tools, with a menu organised by the NIST Cybersecurity Framework. Kali described it in 2023 as "still in its infancy."

Fix it without waiting for upstream

A Kali machine gets its fixes by staying on kali-rolling, and that is Kali's and Debian's job. The part that is yours is everything you build and ship around it: the Python and Go tools a team installs outside APT, the container images built on kalilinux/kali-rolling for a lab or CI job, and the applications you are testing, whose dependencies often lag far behind any distribution.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos replaces updating Kali or chooses a kernel for you; that stays with the Kali team and Debian. They cover the step around it: knowing what is inside the projects and images your team builds, and moving vulnerable dependencies to fixed versions with a person approving each action.

In this Safeguard CLI session you install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the in house tooling a testing team maintains, or to an application under test whose report lists outdated dependencies: the fix becomes a reviewed change instead of a line in a findings document.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. If your team builds lab or CI images on top of kalilinux/kali-rolling, scanning the built image (for example with safeguard scan --image) produces an SBOM listing the packages and versions inside it, so you can see how stale a weekly snapshot has become since it was built.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects contain a given component and version, the same question you face when a release post says a library or tool changed underneath you. Our post on using SBOMs to find affected products fast works through that question.

Click through it at your own pace, or open it full screen.

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli.

Quick check

Sources

• Kali Linux: Release History
• Kali Linux blog: Kali Default Non-Root User (31 December 2019)
• Kali Linux blog: Kali Linux 2020.1 Release
• Kali Linux blog: Kali Linux 2020.2 Release
• Kali Linux blog: Kali Linux 2020.3 Release
• Kali Linux blog: Kali Linux 2020.4 Release
• Kali Linux blog: Kali Linux 2021.1 Release
• Kali Linux blog: Kali Linux 2021.2 Release
• Kali Linux blog: Kali Linux 2021.3 Release
• Kali Linux blog: Kali Linux 2021.4 Release
• Kali Linux blog: Kali Linux 2022.1 Release
• Kali Linux blog: Kali Linux 2022.2 Release
• Kali Linux blog: Kali Linux 2022.3 Release
• Kali Linux blog: Kali Linux 2022.4 Release
• Kali Linux blog: Kali Linux 2023.1 Release
• Kali Linux blog: Kali Linux 2023.2 Release
• Kali Linux blog: Kali Linux 2023.3 Release
• Kali Linux blog: Kali Linux 2023.4 Release
• Kali Linux blog: Kali Linux 2024.1 Release
• Kali Linux blog: Kali Linux 2024.2 Release
• Kali Linux blog: Kali Linux 2024.3 Release
• Kali Linux blog: Kali Linux 2024.4 Release
• Kali Linux blog: Kali Linux 2025.1a Release
• Kali Linux blog: A New Kali Linux Archive Signing Key (28 April 2025)
• Kali Linux blog: Kali Linux 2025.2 Release
• Kali Linux blog: Kali Linux 2025.3 Release
• Kali Linux blog: Kali Linux 2025.4 Release
• Kali Linux blog: Kali Linux 2026.1 Release
• Kali Linux blog: Kali Linux 2026.2 Release
• Kali Linux docs: Kali Linux User Policy
• Kali Linux docs: Kali Linux Root User Policy (dated)
• Kali Linux docs: Network Service Policy
• Kali Linux docs: Should I Use Kali Linux?
• Kali Linux docs: What is Kali Linux?
• Kali Linux docs: Updating Kali
• Kali Linux docs: Kali Branches
• Kali Linux docs: Metapackages
• Kali Linux docs: Downloading Kali Linux
• Kali Linux docs: Official Kali Linux Docker Images
• Kali Linux docs: WSL
• Kali Linux docs: Cloud
• Kali Linux docs: ARM
• Kali Linux docs: Kali NetHunter

Last reviewed: 23 October 2026.