What Is CAP_NET_RAW? Definition & Examples

A Linux capability that allows a process to create and send raw network packets. In Kubernetes, it can enable ARP spoofing, DNS spoofing, and other packet-level attacks from inside a container. It should be granted only when a workload genuinely needs low-level networking functions.

What CAP_NET_RAW Means in Linux and Kubernetes

CAP_NET_RAW is a Linux capability that grants a process the right to create raw network sockets and send packets directly. That is a powerful low-level permission because it bypasses higher-level protocol handling and can expose traffic injection and spoofing paths inside a container.

In practice, this capability matters most in container and cluster environments where a workload should only receive it for a clearly justified networking function. Granting it broadly expands what a compromised process can attempt on the local network, especially when the container shares trust with other services on the node or within the namespace.

Why CAP_NET_RAW Is Security-Sensitive

Raw packet access changes the security model from ordinary application traffic to packet construction and transmission. That can enable ARP spoofing, DNS spoofing, custom packet generation, and some forms of network reconnaissance, which is why the capability is treated as high-risk in hardened deployments. For background on the broader control plane around Linux and container hardening, see NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework.

The key issue is not that every use of CAP_NET_RAW is malicious, but that the capability removes a meaningful boundary. Once a process can emit crafted packets, it can participate in traffic manipulation or trust abuse at the network layer if other controls are weak.

How CAP_NET_RAW Is Commonly Overused

Many Linux containers inherit capabilities they do not actually need, either through permissive runtime defaults or overly broad pod specifications. CAP_NET_RAW is often one of the first capabilities to remove during hardening because most application workloads do not need direct packet construction to function.

When the capability is left in place for convenience, the workload gains an unnecessary attack path. That risk is amplified in shared environments where an attacker who gains code execution inside a container may attempt lateral abuse of local networking assumptions.

When CAP_NET_RAW Has Legitimate Use

This capability is appropriate for specialized tooling that must work below the socket abstraction, such as packet capture, custom diagnostics, or certain network utilities. The correct question is whether the workload truly needs raw packet access or whether its function can be delivered with ordinary TCP, UDP, or application-layer calls.

If the answer is not clear, the safer default is to withhold the capability and introduce it only for a narrowly scoped workload with a documented reason. In Kubernetes, that usually means treating CAP_NET_RAW as an exception rather than a baseline permission.

Risk and Threat Considerations

CAP_NET_RAW is risky because it can let a compromised container generate traffic that looks like it came from somewhere else, or interfere with local name resolution and adjacent network trust assumptions. That makes it attractive for internal reconnaissance, spoofing, and manipulation of peer-to-peer communications.

Failure mechanism: A workload with raw packet privileges can bypass normal application request paths and craft packets directly, allowing spoofing or injection at the network layer if other safeguards do not block it.

Impact: Attackers may use the capability to impersonate local services, poison trust relationships, or extend a container compromise into broader network abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-05 — Least Privilege	CAP_NET_RAW is a privilege decision that should be granted only when needed.
Recommendation — Apply least-privilege access so only justified workloads retain CAP_NET_RAW.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Raw packet capability is an excess-privilege exposure that AC-6 directly governs.
	SC-7 — Boundary Protection	Packet-level abuse can cross trust boundaries and undermine network segmentation.
Recommendation — Restrict CAP_NET_RAW to the smallest set of processes that truly require it. Use boundary protections to contain traffic that a CAP_NET_RAW process can generate.
ISO/IEC 27001:2022	A.8.22 — Segregation of networks	Raw packet privileges can defeat network separation assumptions in containerized environments.
Recommendation — Preserve network segregation when evaluating workloads that request CAP_NET_RAW.
CIS Controls v8	CIS-6 — Access Control Management	Capability assignment is an access-control decision requiring governance and review.
Recommendation — Review and remove CAP_NET_RAW wherever the workload does not need raw network access.

Practitioner Guidance

Governance implication: Treat CAP_NET_RAW as a narrowly justified exception and require an explicit owner for any workload that requests it. The practical decision is whether the function truly depends on raw packet generation, not whether the container can technically tolerate having it.

What to watch for: Review pod and runtime configurations for workloads that request CAP_NET_RAW without a clear networking use case, especially in internet-facing or shared clusters. If the capability is present, assume the workload deserves closer scrutiny than a standard application container.

CAP_NET_RAW