Kali Linux 2026.3 adds six tools and kernel 7.1.5; Kali's pages list all six only under the 'everything' set

Six new tools, 119 days after 2026.2, and not one in the default list

Kali Linux 2026.3 was announced on Monday 26 October 2026, 119 days after 2026.2 on 29 June (derived from the two post dates). The post lists six new tools. On Kali's own tool pages, read on release day, each of the six names one metapackage, kali-linux-everything. On Kali's metapackage page, kali-linux-default, which Kali describes as depending on the applications in the default official images, lists none of the six, and no other metapackage on that page lists them either.

That does not mean the tools are missing from every image, and it does not mean they are unsafe. The post says only that the six are "available in the network repositories", and it does not say which images install them. What it shows is that "six new tools" counts packages added to a repository, not tools a reader finds on a default install.

This briefing reads Kali's release post in full, then the six tool pages, the metapackage page, Kali's download and verification pages, its package tracker, bug tracker and GitLab milestone, the upstream repository of each tool, and KDE's and kernel.org's own release lists. All were read between 13:30 to 14:20 GMT on Monday 26 October 2026. BleepingComputer's report of the same day (secondary) was read for comparison only; where it differs from Kali's post, this article follows Kali. Kali is a free distribution that OffSec, which sells security training, runs as one of its community projects: the kali.org footer says so, and the kali.org menu links OffSec's courses and a free capture the flag event. That is the publisher's interest, and it is stated once here.

Zoom

What the release post states, and what it leaves out

The post is headed "Kali Linux 2026.3 Release (Build-Scripts Refresh)" and says this is "the third release of the year". It groups the changes under three headings: build scripts, desktop updates and new tools. The table sets each item as printed against what the post does not say. The post lists no removals or deprecations, and it prints no download count, no bug count, no security audit of the images and no named maintainers for the new tools.

One line in the post is easy to read past. It says the build scripts "are the same scripts we use to generate every official Kali image". That is a statement about transparency of method, and it is useful. It is not a statement that two builds of the scripts give identical files, and the post does not claim that.

The six tools: where they come from, and where Kali puts them

The tool table below joins three sources: Kali's tool page for each package, the upstream repository's licence as GitHub shows it, and the version in kali-rolling on Kali's package tracker the same day. The versions differ for four of the six because the tool pages carry earlier "Updated on" dates (30 September for dalfox, katana, qsreplace and rustscan; 3 September for snaffler-ng; 25 August for sdrangel). The pages were therefore written before the release post, and the tracker is the better guide to what a reader installs today.

Zoom

Kali's own page calls kali-linux-everything the metapackage that depends on "all other specific purpose metapackages" and warns "this will install a lot of stuff". Each tool page prints its own install command, for example sudo apt install katana. The Kali bug tracker's 2026.3 change log, read at the same time, lists 13 issues, six of which are the six tool additions (6 of 13, 46 per cent, derived). The tracker's status label for 2026.3 still reads "Not Yet Released", and so does the one for 2026.2, so that label is not a release indicator.

Zoom

What each tool says it does, and what a defender can hunt

A penetration testing distribution is dual use: the same tools serve an authorised engagement and an intruder. This table keeps to what each tool's own page prints. The third column holds only detail the page or its upstream documentation prints; where a defender would want a user agent or a scan signature and none is printed, the cell says so. Anything inferred is marked as inference.

Two points follow. First, the snaffler-ng stealth option is documented by the tool itself: detections keyed on a fixed LDAP query shape may not fire when it is used (inference from the printed description). Behaviour is the sturdier hunt: one account or host touching many hosts and many shares in a short time. Second, rustscan's page says the tool is fast by design, so a burst of connection attempts across many ports from one source is the pattern its own description implies (inference).

One more thing the post does not mention. Dalfox's help lists an mcp command, and the 2026.3 change log on Kali's bug tracker includes an item whose title names mcp-kali-server, reporting that its health check "incorrectly reports tools as missing". This briefing did not read that package's page, so it states only that both appear in Kali's own records. If you drive offensive tools from an AI agent, the questions of scope, approval and logging belong to you, and neither the post nor the tool pages answer them.

Plasma, Frameworks, Qt and the kernel: a screenshot is a snapshot

The post says only that Plasma "has been updated to 6.7" and that the kernel goes "from 6.19 to 7.1.5". The version detail comes from the screenshot in Kali's own post: Plasma 6.7.4, KDE Frameworks 6.28.0, Qt 6.10.2, kernel 7.1.5+kali-amd64, Wayland, in a VirtualBox guest. The screenshot's panel clock reads 5:58 AM, 9/24/26, so it was taken on 24 September, 32 days before the post (derived).

Zoom

Read together, the screenshot's Frameworks and Qt are older than what kali-rolling lists on release day (6.30.0 and 6.11.2), and Plasma 6.7.4 is one patch release behind KDE's 6.7.5 and a minor version behind 6.8. This briefing could not establish which versions the 2026.3 installer image carries, so it treats the screenshot as one machine on one day. A reader should run the About page on their own system.

The kernel is the larger open question. The 2026.2 post explained that Kali held at 6.19 because kernel 7.0 had "incompatibilities with the NVidia DKMS drivers" reported in Debian, and offered 7.0 in kali-experimental for people who did not need NVIDIA. It also listed Copy Fail (CVE-2026-31431) and Dirty Frag (CVE-2026-43284 and CVE-2026-43500) among the disclosures that made a newer kernel attractive; those identifiers are as the 2026.2 post prints them and were not checked here. The 2026.3 post moves to 7.1.5 and does not say whether the NVIDIA problem is resolved. Kali's NVIDIA driver page, last updated 8 May 2026, does not mention kernel 7. The uname -v line the post prints shows the kernel was built on 29 July 2026, 89 days before the post (derived). kernel.org's list on release day has no 7.1 line; this briefing found no statement of when 7.1 stops receiving fixes.

The dates, to scale

Several dates in Kali's own records bear on how fresh "fresh images" are. Kali's GitLab milestone for 2026.3 opened on 30 June and carries a due date of 8 September. The post came 48 days after that date (derived). The page also shows 33 work items, 23 open and 10 closed, and 59 merge requests, all merged. The 2026.2 milestone's due date was 9 June and its post came 20 days later (derived). Nothing in the post explains the gap, and a milestone date is a plan, not a promise; the figures are reported, not explained.

Zoom

The download server's directory for 2026.3, read on release day, lists the installer image at 4.7 GiB with a timestamp of 9 October 2026, and the SHA256SUMS and SHA256SUMS.gpg files with a timestamp of 20 October. So the installer images were built 17 days before the post and the checksum and signature files were uploaded six days before it (derived). The post itself says weekly builds exist for readers who do not want to wait, and that they "do not go through the same QA process" as release images. A fresh install from the 2026.3 installer starts from a package set at least 17 days old, and the full upgrade is the step that closes that gap (inference from the build date).

Verifying the download: what Kali documents, and where a reader can slip

A penetration testing image is high value to an attacker. Kali says so itself: a bogus Kali "could do a tremendous amount of damage", and it documents three ways to check a download. The diagram sets them side by side with what each one trusts, in Kali's own words.

Zoom

Kali's pages have rough edges that matter to someone following them. The download page prints each image's SHA256 beside the file, which is method 1 and shares its trust with that page. The "download securely" page was last updated in June 2025 and its sample output shows a signature made in April 2025, so it shows the shape of a good result, not a 2026.3 result. The longer "Downloading Kali Linux" page uses 2026.2 file names in its examples and still says the current release is "v2025.4, as of this writing". The two pages name different key servers. The fingerprint they print is the same, and it is the thing to compare. The key is the 2025 signing key, created 17 April 2025 and expiring 17 April 2028 as Kali prints it.

This briefing did not download an image, did not import the key and did not run gpg --verify on the 2026.3 files, so it cannot say that the signature on the 2026.3 SHA256SUMS verifies. It deliberately does not reproduce any image checksum: a hash copied from this article would be one more page to trust. The secondary report is a small example of the problem. BleepingComputer's 26 October article links its "directly download ISO images" text to cdimage.kali.org/kali-2025.2/, a 2025.2 directory, and prints an upgrade command that writes /etc/apt/sources.list, the file Kali's 2026.2 post said is retired in favour of kali.sources. Kali's own post prints the kali.sources form. It also tells WSL users to move to WSL 2, which Kali's post does not; this briefing could not find that advice in Kali's post.

The wider lesson is the one this site has met twice this month. A checksum that sits with the file proves little if the place that serves the file is compromised: see the OVHcloud CLI case, where the checksum list was swapped with the binaries, and the AOMEI Backupper case, where the expected checksum changed with the file. Kali's method 3 exists for exactly that reason, and it is the only one of the three that a compromised download page does not defeat.

Two smaller supply chain notes from the post itself. The quick example for building your own image pairs git clone with sudo ./build.sh, which runs the cloned repository's script as root; the post does not mention pinning a commit or checking a signed tag before doing so. And all four new mirror links in the post begin with http://, as does the Kali apt source line (http://http.kali.org/kali/). apt checks repository metadata against the keyring named in Signed-By, so this is a design choice rather than a flaw, but a reader should know it is there.

Five labels doing the work of facts

A label is not a control, and a release post is full of labels. This table separates what each one establishes from what it does not.

Technical details

Every block below is copied from the page named in its caption, read on 26 October 2026. Shell prompts are removed, and where a tool's help wraps a sentence over lines, the lines are joined. Where this site derived something, the caption says so. The Kali post and pages publish no exploit, indicator of compromise or hash for the six tools, so nothing of that kind is shown. There is no working attack code here.

First, the upgrade for an existing install, as Kali's post prints it. The first command overwrites /etc/apt/sources.list.d/kali.sources; keep a copy if you have edited it. The third command copies the files in /etc/skel into your home directory; -b keeps a backup of each file it replaces and -i asks first. The last line reboots only if the system asks for it, and -f is the forced form, so save your work before running it.

sudo tee /etc/apt/sources.list.d/kali.sources << 'EOF'
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
EOF
sudo apt update && sudo apt -y full-upgrade
cp -vrbi /etc/skel/. ~/
[ -f /var/run/reboot-required ] && sudo reboot -f

Then the checks the post prints to confirm the result. The uname -v line carries the kernel build date used in the dates section above. The post notes that the uname -r output differs by architecture.

grep VERSION /etc/os-release
VERSION_ID="2026.3"
VERSION="2026.3"
VERSION_CODENAME=kali-rolling
uname -v
#1 SMP PREEMPT_DYNAMIC Kali 7.1.5-1kali1 (2026-07-29)
uname -r
7.1.5+kali-amd64

For a fresh image, Kali documents verification against a signed checksum file. The fingerprint is the value to compare character by character; the last command assumes the ISO's name, which in Kali's example is a 2026.2 file, so substitute your own file name. The key's email address, obfuscated on the page, is omitted.

wget -q -O - https://archive.kali.org/archive-key.asc | gpg --import
gpg --keyserver hkps://keyserver.ubuntu.com --recv-key 827C8569F2518CC677FECA1AED65462EC8D5E4C5
gpg --fingerprint 827C8569F2518CC677FECA1AED65462EC8D5E4C5
pub   rsa4096 2025-04-17 [SC] [expires: 2028-04-17]
      827C 8569 F251 8CC6 77FE  CA1A ED65 462E C8D5 E4C5
uid           [ unknown] Kali Linux Archive Automatic Signing Key (2025)
gpg --verify SHA256SUMS.gpg SHA256SUMS
grep kali-linux-2026.2-live-amd64.iso SHA256SUMS | shasum -a 256 -c

The download directory lists the two files the signature method needs. This is the listing as read, reduced to the lines that matter. The sizes and timestamps are the server's; the 17 and six day gaps in this article are derived from them.

SHA256SUMS 2.8 KiB 2026-Oct-20 03:57
SHA256SUMS.gpg 833 B 2026-Oct-20 03:57
kali-linux-2026.3-installer-amd64.iso 4.7 GiB 2026-Oct-09 16:13
kali-linux-2026.3-installer-netinst-amd64.iso 712.0 MiB 2026-Oct-09 16:29

Next, building your own installer image, as the post prints it. Note the build mirror in the post's sample output, http://http.kali.org/kali/, and that build.sh runs under sudo. The post's own custom example adds rustscan to an image.

sudo apt install git ca-certificates
git clone https://gitlab.com/kalilinux/build-scripts/kali-installer.git
cd ./kali-installer/
sudo apt install simple-cdd debian-cd cpio mtools dosfstools xorriso
sudo ./build.sh
sudo apt install podman
sudo ./build-in-container.sh
sudo ./build.sh --hostname haxbox --packages rustscan
sudo ./build.sh --branch kali-dev --variant netinst --arch arm64

Now the lines from the tool pages that bear on scope and detection. These are the defaults and options the tools' own help prints. A defender can use the rates and probe behaviour as hunting hints; an operator should read them before a first run to keep traffic inside the authorised scope.

-rl, -rate-limit int                maximum requests to send per second (default 150)
-c, -concurrency int                number of concurrent fetchers to use (default 10)
-d, -depth int                       maximum depth to crawl (default 3)
-tlsi, -tls-impersonate              enable experimental client hello (ja3) tls randomization
-kb-validate-secrets                 validate detected secrets against their provider (sends live API calls)
-al, -auto-login string                automatic login with username:password (headless only)
-csp, -captcha-solver-provider string  captcha solver provider (e.g. capsolver)

Scans all 65k ports in 3 seconds.
Automatically pipes ports into Nmap.
WARNING Do not use this program against sensitive infrastructure since the specified server may not be able to handle this many socket connections at once.
[default: 4500]
[default: 1500]

--hash TEXT NT hash for Pass-the-Hash authentication
--max-threads -x INTEGER Maximum total worker threads (default: 60)
--dns-threads INTEGER Concurrent threads for DNS + port 445 reachability probes (default: 100)
--timeout INTEGER SMB connection timeout in seconds (default: 5)
--stealth OPSEC mode: pad LDAP queries with random attributes to break IDS signatures
--state PATH Path to state database (default: ./snaffler.db). Auto-resumes if DB exists.

scan        Scan targets for XSS
server      Run API/server mode
payload     Manage or enumerate payloads
mcp         Run MCP stdio server (Model Context Protocol) exposing Dalfox tools

Finally, the package tracker's kali-rolling versions for the six tools and the kernel as read on 26 October, shown as a table because they are this site's reading of a page that changes daily, not text Kali published as a block.

What to do, in the order worth doing

What could not be verified

No image was downloaded and no signature was verified, so the integrity of the 2026.3 files is unchecked. The licences are as GitHub's repository pages show them, not Kali's package copyright files. The tools were read about, not run. Which versions of Frameworks and Qt the 2026.3 installer carries is not established; the screenshot and the tracker disagree, and the screenshot is dated 24 September. Whether the six tools are among the 126 package updates is not stated. The package tracker's change log pages for the six tools were not read, so their first appearance in kali-rolling is not dated here beyond the tool pages' own dates. The CVE identifiers cited from the 2026.2 post were not checked against CVE.org. This briefing found nothing on end of life for the 7.1 kernel line and says only that kernel.org's list does not show it. Everything that depends on a page that updates daily, including the tracker versions, the GitLab milestone counts and the download directory, is as of the read time stated in the opening section.

The question that exposes the gap

A release post can say six tools are new. It cannot say which of them are on the machine in front of you, which kernel and desktop that machine really runs, or that the image that put them there is the one Kali signed. Before the next engagement, can you show, for your own Kali box, the image you installed, the fingerprint you checked and the packages you added, or are you relying on a headline?

Key facts