Skip to content

VNX-267: Privilege Defined With Unsafe Actions

A root-equivalent Linux capability (CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_SYS_RAWIO, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_SETFCAP, CAP_BPF or all) is granted through libcap, libcap-ng, ambient capabilities, setcap, capsh or a systemd AmbientCapabilities= line.

Updated 02 Nov 2026Checked against cli@de9b52a
Field Value
Rule ID VNX-267
Severity Medium
SARIF level warning
Kind sast
Languages C, C++, Shell, Dockerfile, Any file
CWE CWE-267
CAPEC CAPEC-66
ATT&CK T1190
CWSS vector CWSS:1.0/TI:M/AP:RU/AL:S/IC:N/FC:LT/RP:RU/RL:S/AV:L/AS:N/IN:A/SC:A/BI:M/DI:H/EX:M/EC:N/P:C
Tags privilege-unsafe capabilities cwe-267
Source internal/sast/rules/vnx-267.rego

Overview

VNX-267 maps to CWE-267: Privilege Defined With Unsafe Actions. Linux capabilities split root into pieces, but several of the pieces are root again under another name. This rule reports code and install scripts that grant one of those.

Why This Matters

CAP_SYS_ADMIN covers mounting filesystems, namespaces, BPF, device administration and dozens of other operations; CAP_SYS_MODULE loads kernel code; CAP_SYS_PTRACE reads and writes any process’s memory; CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH ignore file permissions; CAP_SETFCAP hands out further capabilities. A process holding any of these for one narrow task can be turned into full root by the first bug an attacker finds in it.

What Gets Flagged

cap_value_t wanted[] = { CAP_NET_ADMIN, CAP_SYS_ADMIN };
cap_set_flag(caps, CAP_EFFECTIVE, 2, wanted, CAP_SET);

cap_t caps = cap_from_text("cap_sys_admin,cap_net_raw+ep");
capng_update(CAPNG_ADD, CAPNG_EFFECTIVE | CAPNG_PERMITTED, CAP_DAC_OVERRIDE);
prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN, 0, 0);
setcap cap_sys_admin,cap_net_admin+ep /usr/local/bin/agent
RUN setcap cap_sys_ptrace+ep /usr/local/bin/agent
exec capsh --addamb=cap_sys_ptrace -- -c /opt/agent/bin/agent
# agent.service
AmbientCapabilities=CAP_SYS_PTRACE CAP_NET_RAW

Not flagged: capsh --drop=..., CapabilityBoundingSet= (a limit, not a grant), checks (capable(CAP_SYS_ADMIN), ns_capable, cap_get_flag), drops (CAP_CLEAR, CAPNG_DROP, PR_CAP_AMBIENT_LOWER, PR_CAPBSET_DROP, setcap -r), narrow capabilities such as CAP_NET_BIND_SERVICE or cap_net_raw+ep, and the calls in comments or string literals. Capabilities added to containers (--cap-add, Kubernetes securityContext) are left to the IaC rules.

Remediation

  1. Find the specific operation the program needs and grant only the capability that covers it (CAP_NET_BIND_SERVICE for a low port, CAP_NET_RAW for ICMP).
  2. If the operation really needs CAP_SYS_ADMIN or similar, move it into a small helper that takes a fixed, validated request, and keep the main program unprivileged.
  3. Raise the capability only around the call and clear it from the effective and permitted sets afterwards.

References

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-267
// nosec vnx-267

Or record an ignore rule: vulnetix ignore add --rule vnx-267 --reason "...". See Suppressing findings.

Edit this pageSources: cli/internal/sast/rules/vnx-267.rego, cli/internal/sast/docs/vnx-267.md
esc
↑ ↓ move↵ openSearches in your browser. A key like autonomy.max or a code like threshold_required jumps straight to it.