How to update Kali Linux: apt full-upgrade, sources and the new signing key

Short answer: to update Kali Linux, run sudo apt update && sudo apt full-upgrade -y, then reboot if a new kernel came in. Use full-upgrade, not upgrade: Kali is a rolling release, and its updates regularly need to remove or replace packages, which plain apt upgrade refuses to do. Check the result with cat /etc/os-release.

sudo apt update
sudo apt full-upgrade -y
sudo apt autoremove          # optional: remove packages nothing needs any more
sudo reboot                  # if the kernel was updated

This page is written from Kali’s own documentation (“Updating Kali”, updated 14 May 2026, and “Kali Network Repositories”, 8 May 2026), the archive key announcement of 28 April 2025, the Kali 2026.2 release notes and the apt(8) man page, all read on 21 October 2026. No Kali system was updated for it; the quoted error and version output are Kali’s published examples.

How do I update Kali Linux step by step?

1. 1Check the repository

   cat /etc/apt/sources.list.d/kali.sources 2>/dev/null || cat /etc/apt/sources.list

   It must name http.kali.org and kali-rolling and nothing else. The correct contents are below.

2. 2Refresh the package lists

   sudo apt update
   apt list --upgradable         # what would change

   apt update ends by saying how many packages can be upgraded, and the second command lists them. An error here, most often a missing key, has to be fixed before anything else; see the signing key section.

3. 3Upgrade everything

   sudo apt full-upgrade

   Without -y apt shows the plan first. Read the list under The following packages will be REMOVED before you confirm: removing an old library is normal, removing your desktop or a tool you rely on is not.

4. 4Clean up

   sudo apt autoremove      # dependencies and old kernels no longer needed
   sudo apt clean           # empty the downloaded package cache in /var/cache/apt/archives

5. 5Reboot if needed and check

   grep VERSION /etc/os-release
   uname -r

Kali’s documentation suggests updating every few days or weeks, and advises against doing it in the middle of a security engagement: a rolling release occasionally breaks a tool. Update before the work starts, then check that the tools you need still run.

Why full-upgrade and not upgrade?

The apt(8) man page draws the line. upgrade installs new versions and may add new packages, but “existing packages will never be removed”; when an upgrade needs a removal, that package is simply not upgraded. full-upgrade “performs the function of upgrade but will remove currently installed packages if this is needed to upgrade the system as a whole.”

On a stable distribution that difference rarely matters. On Kali, which follows Debian testing, libraries get renamed and replaced all the time, so apt upgrade leaves a growing list of packages under The following packages have been kept back, and the system drifts into a half updated state where new tools do not install. full-upgrade is the command Kali’s documentation gives. apt-get dist-upgrade is the older name for the same thing.

What is the correct Kali sources.list?

Since Kali 2026.2 (29 June 2026), new installs keep the repository in /etc/apt/sources.list.d/kali.sources, in the deb822 format. Older installs still have the classic one-line entry in /etc/apt/sources.list, and Kali says both are equivalent and work the same:

Types: deb
URIs: http://http.kali.org/kali/
Suites: kali-rolling
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

Keep one of the two, not both, or apt update warns that the same target is configured multiple times. To convert an existing sources.list to the new format, current apt versions offer sudo apt modernize-sources. Plain http is fine here: http.kali.org redirects you to a nearby mirror, and apt checks the signature of the package index against the Kali keyring whatever the transport.

kali-rolling is the branch almost everyone should use. kali-last-snapshot moves only with the quarterly point releases, which Kali calls the safest option; kali-experimental and kali-bleeding-edge are for testing and can break.

How do I fix the Kali “Missing key” error?

On 28 April 2025 Kali announced that it had lost access to the signing key of its package archive and had created a new one. Since then the repository is signed with the new key, and a Kali installed from an image older than 2025.1c (or a weekly image before 2025-W17) that has not received the new keyring cannot verify it. Kali’s published example of the error:

Err:1 https://http.kali.org/kali kali-rolling InRelease
  Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5, which is needed to verify signature.
Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used.

Where apt still verifies with GnuPG, the same problem reads NO_PUBKEY ED65462EC8D5E4C5, the last 16 hex digits of that fingerprint. Either way, apt keeps using the old package lists, so nothing updates. The fix is to fetch the current keyring from Kali:

sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg
# or with curl:
sudo curl https://archive.kali.org/archive-keyring.gpg -o /usr/share/keyrings/kali-archive-keyring.gpg

# check what you got
gpg --no-default-keyring --keyring /usr/share/keyrings/kali-archive-keyring.gpg -k
sudo apt update && sudo apt full-upgrade -y

The key listing must show the fingerprint 827C8569F2518CC677FECA1AED65462EC8D5E4C5, “Kali Linux Archive Automatic Signing Key (2025)”, valid until 17 April 2028. The old key is still in the keyring, valid until 4 February 2027; Kali says it was not compromised. The announcement also gives a SHA-1 checksum of the file at that time, 603374c107a90a69d983dbcb4d31e0d6eedfc325; if the keyring has been updated since, the checksum changes but the fingerprint does not. After the next full-upgrade, the kali-archive-keyring package keeps the file current. For other repositories with the same kind of error, see GPG error: NO_PUBKEY.

Kali metapackages: which tools get updated

Kali groups its tools into metapackages. A full-upgrade updates the ones you have and installs any tool Kali has added to them since. To change the size of your toolset, install a different one:

apt list --installed 'kali-linux-*'       # which ones you have
sudo apt install -y kali-linux-default    # add the default tool set
df -h /                                   # check free space before the bigger ones

How do I check which Kali version I have?

$ grep VERSION /etc/os-release
VERSION="2026.2"
VERSION_ID="2026.2"
VERSION_CODENAME="kali-rolling"

On a rolling release the number is the point release your packages last caught up with, not a separate edition: any Kali that has just run full-upgrade is current, whichever image it was installed from. On 21 October 2026 the newest point release listed on kali.org is 2026.2 of 29 June 2026, with Linux 6.19. uname -r shows the kernel you are running, and checking your Linux version covers /etc/os-release, hostnamectl and the rest.

Do I need to reboot after updating Kali?

Only when the kernel changed, but that happens often on a rolling release. A new kernel package is installed next to the running one and takes effect at the next boot:

uname -r                 # the kernel you are running
ls /lib/modules          # the kernels installed; a newer one here means: reboot

Long-running programs keep using the old libraries in memory until they restart, so after a large update a reboot is the simple way to be sure everything runs the new code. Old kernels pile up over time; apt autoremove clears out the ones apt no longer protects and always keeps the kernel you are running.

Common errors when updating Kali

How do I install Kali Linux in the first place?

Kali’s download page offers installer images for bare metal, ready-made virtual machines for VMware, VirtualBox, Hyper-V and QEMU, ARM builds, NetHunter for Android, live USB images, container images for Docker and LXC, and WSL. For most users it recommends the latest point-release image over the weekly builds. On Windows, WSL is the quickest route: wsl --install --distribution kali-linux in PowerShell.

Whatever you install from is a snapshot, and the rolling archive has moved on since it was built. So the first thing to run on a fresh Kali is the update at the top of this page, followed by the metapackage you want, since a container or WSL install starts with almost no tools.

Updating Kali on a VPS

On a server, Kali’s tools are best kept in a container on a stable host. VMHeaven has no Kali template: you install Debian from a template and run Kali’s official kalilinux/kali-rolling image, as the Kali VPS guide shows. Updating then has two parts:

• Inside the container you are root, so the same commands run without sudo: apt update && apt -y full-upgrade. Or pull a fresh image with docker pull kalilinux/kali-rolling and recreate the container, which also gives each engagement a clean start.
• The Debian host gets its normal updates. A container has no kernel of its own, so a kernel update and its reboot always happen on the host.

Take a snapshot in the panel before a large update, so a broken tool chain is one restore away. And the tools are only for systems you own or have written permission to test: our Pentesting KVM line explicitly allows scanning such as zmap and masscan, from an isolated network segment, within that rule.

Frequently asked