CVE pending: pre-auth format-string bug in tac_plus (Shrubbery Networks)

TychoTithonus · September 23, 2026, 1:45pm

Last Updated: 2026-09-25T02:39:37Z

CVE: TBA

CVSSv3: tentative 9.8 (per vuln publisher, not ratified)

What’s Happening

Research firm elttam has disclosed a vulnerability in the Shrubbery fork of the tac_plus TACACS+ authentication library used in multiple networking devices. The vulnerability, if fully exploited, can lead to remote code execution on target devices. Crashing systems is also a possibility. Secret disclosure is a natural result of this vulnerability.

That post is long, but the plain-text advisory is more clear:

github.com/elttam/publications

writeups/elttam-tac_plus_rce_fmtstring_advisory.txt

master

=============================================================================
                                                            Security Advisory
                                                                       elttam

Topic:          Remote pre-authentication format string vulnerability in
                tac_plus send_authen_error() (CWE-134)

Module:         packet.c - send_authen_error() / get_authen_continue()

CVE:            <CVE-PENDING>
Severity:       Critical - CVSS v3.1 9.8
                (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, elttam assessment)
                9.8 applies where no shared secret is in effect, or where
                the configured secret is weak. Where the secret is long,
                random and unique, AC:H is the better fit, giving 8.1 High.
                See section III.

Disclosed:      23-Sep-2026
Credits:        Matt Jones, elttam

This file has been truncated. show original

Affected Versions

Let’s say this up front: Cisco gear in production is not impacted by this vulnerability (per Cisco PSIRT, per the advisory above).

Shrubbery tac_plus up to and including F4.0.4.31
Facebook/Meta tac_plus fork F4.0.4.28-7fb – likely no fix (repo archived read-only 2025-08-22)
Any other fork / product based on Cisco’s dev-kit-derived fork? (not in production)
Notably affected: many FOSS OS distros; OpenWrt
Distros and downstream products - see tables below

Actions

Segment: only network/authed gear should be able to reach the TACACS server on port 49
Patch: upgrade to F4.0.4.32 Index of /pub/tac_plus
Note: provided SHA256 on server may be stale at this writing; should be:
ee3e403a079c75cad13ce9e451c1af0115b0647142765bbd85e60d7a9f3f3fd2
Harden:
- Require shared secret (if the server allows non-encrypted connections, it can be exploited more directly)
- Make sure shared secret is long/random (resistance to cracking offline, hashcat -m 16100)
- Turn off reverse DNS lookups: disable use of the -L flag (another source of tainted input). But this is only partial mitigation - other fields of the protocol are client-controlled
- Drop privileges (run with -U/-Q)
- Enable ASLR (discoverer tested with it disabled; speculative)
- Restrict outbound traffic from the server.
Monitor for crashes.

The daemon often runs as root by default (distros not yet verified), but per the post running as non-root isn’t sufficient mitigation - daemon drops privs later but no impact on vulnerability, and most packages appear to not use the -U / -Q flags to drop to a different user by default.

Mitigations also cannot protect the server from valid clients. If the weakest network device holding the shared TACACS secret is compromised, the server is vulnerable until patched.

Exploitation Detection

From post:

Exploitation attempts may appear in the daemon’s logs as entries whose port or peer field contains expanded conversion specifiers, or as truncated or malformed report() output. Note that the expansion appears in the log only, not in the reply sent to the client. A successful %n write may occur without producing a distinctive log entry, so absence of these indicators is not evidence that a host was not targeted.

FOSS/source status (tentative)

Distro / Source	Package	Fork	Version	Status	Notes
ALT Linux p10 / p11	`tac_plus`	Shrubbery	4.0.4.28-alt2	Vulnerable - await update	+ third-party (Hungarian) patches
ALT Linux sisyphus	`tac_plus-ng`	Huber	2026.06.17.9-alt1	Not affected	Replaced the removed Shrubbery pkg
Arch (AUR)	`tacacs-plus`	Shrubbery	4.0.4.28-1	Vulnerable - orphaned	Not in official repos
Debian	`tacacs+`	Shrubbery	4.0.4.27a-3	Vulnerable (EOL only)	buster and earlier; gone from bullseye+
deepin 20	`tacacs+`	Unconfirmed	?	Unconfirmed - verify	Debian-derived; likely Shrubbery, EOL branch
EPEL 8 / 9	`tacacs`	Meta	F4.0.4.28.7fb~20231005g4fdf178	Vulnerable - no upstream fix	Has the 2023 fix, not the 2026 one
Fedora 35-42	`tacacs`	Meta	F4.0.4.28.7fb (g25fd8f0)	Vulnerable - no upstream fix
FreeBSD 14 / 15	`net/tac_plus4`	Shrubbery	F4.0.4.28_2	Vulnerable - await F4.0.4.32 port	drops privs
Mageia 10 / cauldron	`tac_plus`	Shrubbery	4.0.4.28-2	Vulnerable - await update	Mageia 9: 4.0.4.26
NetBSD pkgsrc	`net/tacacs`	Shrubbery	4.0.4.28nb9	Vulnerable - await update
nixpkgs	`tac_plus`	Unconfirmed	4.0.4.31	Vulnerable - await update	check default.nix `src`
OpenBSD Ports	`tac_plus`	Shrubbery	4.0.4.28 rev 4	Vulnerable - await update	drops privs
OpenPKG	`tac_plus`	Unconfirmed	?	Unconfirmed - verify
openSUSE (Tumbleweed)	`tac_plus`	Shrubbery	4.0.4.28	Vulnerable - await update	`Source0` = shrubbery FTP
OpenWrt 23.05 / 24.10 / 25.12	`tac_plus` (+`-pam`)	Meta	4.0.4.28-r2/r3/r4 (snapshot 2019.02.11)	Vulnerable - no upstream fix	On routers; 2019 snapshot predates even the 2023 fix, so likely also CVE-2023-45239
PureOS amber	`tacacs+`	Unconfirmed	?	Unconfirmed - verify	Debian-derived; tracks Debian
Rosa 2021.1 / 13	`tac_plus`	Unconfirmed	?	Unconfirmed - verify	RPM distro; Shrubbery or Meta
Ubuntu	`tacacs+`	Shrubbery	4.0.4.27a-3	Vulnerable (EOL/ESM only)	bionic 18.04; gone from focal+

Commercial /vendor product status

NOTE: Per private communication with the author 2026-09-24, they are not aware of any commercial integrations – but since such integrations might exist without notification, we’ll continue to update if any new information comes in.

Vendor / Author	Product	Fork	Version	Status	Notes
Cisco	ISE (Device Admin license)	?	All	Not affected per Cisco PSIRT	TACACS+ added in ISE 1.4; Linux-based appliance (HW / VMware / KVM); own engine presumed
Cisco	Secure ACS (EOL)	?	All	Not affected per Cisco PSIRT	Own AAA engine presumed (TACACS+ originated at Cisco); HW / VMware appliance; EOL
DialWays	DialWays AAA	?	?	?	Windows, proprietary; origin unknown
Fortinet	FortiAuthenticator	?	?	?	TACACS+ server, per-command authz, listens TCP/49; own engine presumed
Fortinet	FortiGate / FortiOS	n/a	n/a	client-only?	Verify: acts as TACACS+ client (up to 10 servers); client role should not hit this bug
HPE Aruba	ClearPass Policy Manager	?	?	?	Linux appliance; TACACS+ server service; own engine presumed
Juniper	Junos	n/a	n/a	client-only?	Verify: TACACS+ client (`junos-exec`); client role should not hit this bug
Meta	Tacquito	none	?	Not affected?	Verify: independent Go RFC 8907 rewrite (MIT); no shared C code
NTTacPlus	NTTacPlus	?	?	?	Windows, proprietary; origin unknown

Other product families

Vendor / Author	Product	Comment / status
Marc Huber	tac_plus / tac_plus-ng	rewrite - tentatively unaffected

Validation / vulnerability detection

draft YARA (validated against patched and unpatched packages, but not commercial):
Yara for detecting tac_plus versions vulnerable to 2026-09 vulnerability · GitHub
scan for TCP port 49. If you can nmap, scan with NSE (benign, beyond stock Nmap, detects valid TACACS service and shared-secret status)
Nmap NSE to detect valid TACACS and its shared-secret status (benign fingerprint) · GitHub
grep for strings starting with tac in package-listing output, including tacplus and tac_plus
search filesystem for tac_plus.conf
binwalk binaries for Shrubbery