Unix Named Pipe

What a Unix named pipe is

A Unix named pipe, or FIFO, is a filesystem object that gives unrelated processes a way to exchange data as a byte stream. Unlike a regular file, it does not store content persistently; the kernel passes data between a writer and a reader as it flows, which makes it useful for simple inter-process communication.

Its defining feature is the combination of a pathname with pipe semantics. That means programs can open it through the filesystem namespace, coordinate through ordinary file operations, and still avoid writing data to disk. This makes named pipes convenient for glue code, shell pipelines that need a reusable endpoint, and local process coordination.

How named pipes work

A named pipe behaves like a special endpoint rather than a document. One process writes bytes into it, another reads those bytes out, and the kernel mediates the transfer. Because the data is streamed, consumers see whatever the producer sends in order, without the buffering and random access model associated with files.

Named pipes are usually blocking by default. If a reader opens the FIFO before a writer is available, or vice versa, the process may wait until the other side connects. That behaviour is useful when two processes must synchronize, but it also means a workflow can stall if one side never starts or exits unexpectedly.

Permissions matter because a named pipe is an object in the filesystem namespace. Whoever can open it can potentially participate in the communication channel, subject to the operating system’s access checks. The security significance therefore comes from who can create, discover, open, or replace the pipe path, not from the pipe storing sensitive data itself.

Where named pipes are useful

Named pipes are common in Unix tooling because they are lightweight and composable. They let unrelated programs hand off structured output, decouple producers from consumers, and avoid temporary files when a stream is enough. They are also useful in scripts, service orchestration, and local IPC patterns where a single host needs low-overhead communication.

They are not a general-purpose messaging system. A FIFO is best when the interaction is simple, linear, and local. If the design needs persistence, multiple consumers, rich message routing, or robust delivery guarantees, a different mechanism is usually a better fit. The pipe model is intentionally minimal, which is why it remains widely used and easy to reason about.

That simplicity also makes named pipes visible in defensive tooling. A pipe can expose process relationships, data flow, and unusual communication patterns, especially when it is created in unexpected locations or used by software that normally does not rely on local IPC. Security teams often treat unusual named pipe activity as an artefact worth investigating rather than as a problem by itself.

Security and operational considerations

Named pipes can become security-relevant when the pipe name, permissions, or surrounding process behaviour are weakly controlled. If an attacker can write to or read from a FIFO that a privileged process trusts, the pipe can become a local abuse path for data theft, command relay, or process influence. In other cases, the risk is less about the pipe itself and more about the trust boundary it creates between processes.

Process interaction over named pipes is also a common visibility point for malware and post-exploitation tooling. A named pipe can be used to pass commands, stage data, or coordinate components without touching obvious network channels, so defenders often correlate pipe creation with parent-child process chains, unexpected service activity, and unusual file-system namespace usage. Cobalt Strike Abuse Detection Guide is a useful reference when pipe activity appears alongside beaconing or other suspicious operator tradecraft. MITRE D3FEND Guide is also helpful for mapping named-pipe artefacts to defensive countermeasures and detection ideas.

For Unix systems, the main operational concern is ensuring that the FIFO path, ownership, and access mode match the communication pattern you intended. A named pipe that is world-readable, writable by the wrong account, or left behind after use can create avoidable exposure, especially when it sits in a predictable location that other local processes can discover.

Practitioner Guidance

Why practitioners should care: Named pipes are easy to overlook because they look like ordinary filesystem objects, yet they can carry sensitive inter-process traffic and become an abuse path if permissions or lifecycle handling are weak. Treat them as part of the process trust boundary, not just as a convenience feature.

What to watch for: Investigate FIFOs that appear in unexpected paths, persist longer than the application workflow, or are associated with privileged processes that should not be sharing data through a local pipe. Unusual named-pipe use is often most meaningful when it lines up with a new service, a rare parent-child chain, or suspicious local IPC patterns.

Governance implication: Teams should define who may create and consume named pipes in sensitive runtimes, then review those permissions alongside other local communication paths. The practical question is whether the pipe is acting as an intentional integration point or as an undocumented shortcut that bypasses normal controls.

Related resources from NHI Mgmt Group

• What are the signs that named pipe access controls are being misused in a Windows application?
• When is Named Pipe Metadata logged?
• Which attacks are indicated by named pipe metadata?
• How does a named pipe work?