Hello Kali Security Team,

I would like to responsibly report a local privilege-boundary issue in the Kali nmap package.

Summary

On my Kali system, the nmap package installs /usr/lib/nmap/nmap with broad Linux file capabilities:

/usr/lib/nmap/nmap cap_net_bind_service,cap_net_admin,cap_net_raw=eip

The /usr/bin/nmap wrapper executes /usr/lib/nmap/nmap and automatically adds --privileged for non-root users:

#!/usr/bin/env sh

set -e

if [ "$(id -u)" -eq 0 ] || [ "$1" = "--resume" ]; then
exec /usr/lib/nmap/nmap "$@"
else
exec /usr/lib/nmap/nmap --privileged "$@"
fi

Nmap NSE exposes Lua package.loadlib(), allowing an unprivileged local user to load an arbitrary native shared object from a user-controlled path. Because the shared object is loaded inside the file-capability-enabled nmap process, attacker-controlled native code runs with:

CAP_NET_ADMIN
CAP_NET_RAW
CAP_NET_BIND_SERVICE

I was also able to raise those capabilities into the ambient set and execute child processes that inherit them.

Affected environment
Distribution: Kali GNU/Linux
Kernel: 6.19.14+kali-amd64
Package: nmap
Version: 7.99+dfsg-1kali1
Architecture: amd64
nmap binary: /usr/lib/nmap/nmap
wrapper: /usr/bin/nmap

Observed package/capability state:

Package: nmap
Maintainer: Kali Developers [email protected]
Architecture: amd64
Version: 7.99+dfsg-1kali1
Original-Maintainer: Debian Security Tools [email protected]

-rwxr-xr-x 1 root root 165 /usr/bin/nmap
-rwxr-xr-x 1 root root 3115216 /usr/lib/nmap/nmap

/usr/lib/nmap/nmap cap_net_bind_service,cap_net_admin,cap_net_raw=eip
/usr/bin/nmap
Technical impact

A non-root local user can execute arbitrary native code with effective network-administration capabilities intended for nmap scanning.

Confirmed capabilities inside attacker-controlled native code loaded via NSE:

Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
CapInh: 0000000800000000
CapPrm: 0000000000003400
CapEff: 0000000000003400
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0

0x3400 decodes to:

cap_net_bind_service,cap_net_admin,cap_net_raw

After raising ambient capabilities from the loaded native code, a child /bin/sh process inherited them:

Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
CapInh: 0000000800003400
CapPrm: 0000000000003400
CapEff: 0000000000003400
CapBnd: 000001ffffffffff
CapAmb: 0000000000003400
NoNewPrivs: 0

This allows non-root users to perform privileged network operations such as:

creating and bringing up TUN/TAP interfaces;
modifying nftables rulesets;
creating tc/qdisc/filter/action objects;
creating XFRM/IPsec state and policy objects;
modifying network sysctls;
opening raw/packet sockets through CAP_NET_RAW;
propagating the elevated network capabilities to child commands via ambient capabilities.
Confirmed examples
Plain user cannot create a TUN interface:
open_tun=3 errno=0 Success
TUNSETIFF=-1 errno=1 Operation not permitted ifname=plain7455
The same operation succeeds from attacker-controlled native code loaded through nmap NSE:
open_tun=5 errno=22 Invalid argument
TUNSETIFF=0 errno=0 Success ifname=graaltun8194
ioctl_socket=6 errno=0 Success
flags_before=0x1090
SIOCSIFFLAGS_UP=0 errno=0 Success flags_after=0x10d1

ip link confirmed the interface was created and brought up:

graaltun8194: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN
Plain user cannot modify nftables:
Error: Could not process rule: Operation not permitted
add table inet nmap_plain_test
A child process spawned from the NSE-loaded native code with ambient capabilities can create nftables objects:
table inet nmap_child_tbl {
}
A child process with ambient capabilities can create TUN/TAP via normal system utilities:
---ip-tuntap---
4: childcaptun: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 500
A child process can modify network sysctl values:
ORIG=64
AFTER_WRITE=65
RESTORED=64
Uid: 1000 1000 1000 1000
CapEff: 0000000000003400
CapAmb: 0000000000003400
Security boundary

This is not a full root privilege escalation because the attacker does not receive capabilities such as CAP_SYS_ADMIN, CAP_SETUID, CAP_DAC_READ_SEARCH, or CAP_SYS_PTRACE.

However, it does allow arbitrary attacker-controlled native code to obtain CAP_NET_ADMIN, CAP_NET_RAW, and CAP_NET_BIND_SERVICE, which is a significant local privilege-boundary break. The issue is especially relevant on multi-user systems, shared Kali workstations, training labs, CI/security automation hosts, and jump boxes where unprivileged users may exist.

Root cause

The package grants broad file capabilities to an extensible interpreter-like program. Nmap NSE allows loading native shared libraries via Lua package.loadlib(). Therefore, capabilities intended for nmap’s internal network-scanning operations become available to arbitrary user-controlled native code.

Suggested mitigations

Possible options:

Do not grant CAP_NET_ADMIN to /usr/lib/nmap/nmap by default.
Avoid giving broad eip file capabilities to an application that can load user-controlled native code.
Disable or restrict package.loadlib() and native Lua module loading in NSE when nmap is running with elevated file capabilities.
Drop elevated capabilities before executing user-provided NSE scripts.
Split privileged operations into a small, constrained helper rather than granting capabilities to the full NSE runtime.
Consider only granting the minimum capabilities required for common non-root scans, if any.
Disclosure notes

This report is based on local testing on my own Kali system. No third-party systems were accessed. I have not publicly disclosed the full PoC.

Please let me know whether you would like a minimal reproducer archive or additional logs.

Best regards,

Federico Brasil