ROOTLESS CONTAINER SECURITY IN 2026

• 11/2/2026
• Updated 11/4/2026
• 4-minute read
• 835 words

The container landscape shifted dramatically in 2025, and most teams missed it. When Podman 5.0 shipped with pasta as the new default rootless networking backend, it wasn’t just a version bump—it represented a fundamental architectural change in how rootless containers communicate with the outside world.

But here’s what nobody’s talking about: pasta isn’t always faster than slirp4netns. The default isn’t always the best choice for your workload. And the CVE that everyone thought affected slirp4netns? It wasn’t even in the same codebase.

The pasta Revolution

What Changed in Podman 5.x

Before May 2024, every rootless Podman container used slirp4netns for network address translation. It’s been the default since Podman 2.0, and it works. But it has dependencies—and those dependencies have had security issues.

pasta (stylized as “passt”) is different. It’s a complete rewrite designed from scratch for rootless operation:

• Written in C: ~9,500 lines of code, zero external dependencies except libc and the kernel
• No NAT: Creates a tap device directly inside the network namespace
• IPv6-first: Full IPv6 support with NDP and DHCPv6
• splice() acceleration: For local-to-local TCP connections, uses kernel splice() for near-native throughput
• Minimal attack surface: seccomp filter allows only 26 syscalls on x86_64

The design philosophy is explicit: avoid every mistake from libslirp (slirp4netns’s underlying library).

Performance Benchmarks: The Numbers

I ran GitHub’s standard Apache Bench methodology to get real numbers [source ]:

Reference: Rootful networking achieves ~37,610 req/s at c=32

The data tells a clear story: pasta wins for typical development workloads (1-8 concurrent connections, which is 90% of use cases). But slirp4netns scales significantly better once you hit high concurrency.

This is the irony nobody discusses—Podman’s new default is slower under load.

Why the Performance Gap?

The maintainer noted it openly: pasta is currently single-threaded. The slirp4netns codebase has had years of multi-threaded optimization. When pasta has more concurrent connections, it hits a architectural bottleneck that slirp4netns already solved.

Future versions will close this gap—vhost-user and VDUSE support are in progress. But for now, it’s a documented limitation.

The CVE Reality Check

What Everyone Got Wrong About CVE-2025-61728

In late 2025, security scanners started flagging “CVE-2025-61728 in slirp4netns.” Articles propagated this claim. The problem? It’s not slirp4netns at all.

CVE-2025-61728 is a vulnerability in golang:archive/zip —the Go standard library for building archive indexes. It affects any Go toolchain building ZIP archives. The CVSS is 6.5 (Medium), and it can cause denial of service via malformed archives.

This was never a slirp4netns vulnerability. It was Go’s library. The confusion came from security scanners that flag any mention of “slirp” without context.

The Real Vulnerability: CVE-2024-32462 (bubblewrap)

The actual rootless container vulnerability you should care about is CVE-2024-32462 , affecting bubblewrap (bwrap):

• CVSS: 8.4 (High)
• Type: Sandbox escape via argument injection
• Vector: Flatpak argument injection allows malicious apps to manipulate bwrap
• Fix: Use -- argument separator (since bwrap 0.3.0)
• Patched in: bwrap 1.15.8, 1.10.9, 1.12.9, 1.14.6

If you’re running Flatpak, ensure your xdg-desktop-portal is 1.18.4+ and your bwrap version is current.

Historical CVE Comparison

pasta has had fewer reported vulnerabilities—which makes sense given its smaller codebase and newer architecture.

Rootless Container Hardening Checklist (2026)

Every production rootless container should implement these eight practices:

1. Use Default Podman Seccomp

Podman applies a restrictive seccomp policy by default. Don’t disable it unless necessary:

podman run --security-opt seccomp=unconfined myapp  # AVOID THIS

2. Enable SELinux (or Apparmor)

On RHEL/Fedora, SELinux is enabled by default. Verify:

podman info | grep selinuxEnabled
# Should return: selinuxEnabled: true

On Ubuntu/Debian, use Apparmor profiles instead.

3. Drop Capabilities

Podman drops dangerous capabilities by default. Verify:

podman run --cap-drop=ALL myapp

4. Use Read-Only Filesystems

Prevent writes to container layers:

podman run --read-only myapp

5. Block Privilege Escalation

podman run --security-opt no-new-privileges=true myapp

6. Map User Namespaces Preserve ID

podman run --userns=keep-id:uid=1000,gid=1000 myapp

7. Set Resource Limits

podman run --memory=512m --cpus=1.0 myapp

8. Use Udica for Custom SELinux Policies

Generate workload-specific policies:

podman inspect myapp > myapp.json
udica -t myapp myapp.json

This generates a custom SELinux type for your specific workload—stricter than default.

Decision Framework

Use pasta when:

• Running Podman 5.x or later
• Workload is typical web application (1-8 concurrent connections)
• Security is primary concern
• IPv6 support is needed

Use slirp4netns when:

• Running older Podman versions
• High-concurrency workloads (16+ parallel connections)
• Need precise latency guarantees under load

Use rootful networking when:

• Maximum performance required
• Single-tenant environments
• Latency-sensitive workloads where 20%+ overhead matters

The right choice depends on your threat model and workload characteristics.

TL;DR

• pasta is the new default in Podman 5.x—use it unless your workload exceeds 16 concurrent connections
• slirp4netns isn’t broken—it actually performs better under load
• CVE-2025-61728 isn’t slirp4netns—it’s golang:archive/zip
• CVE-2024-32462 is real—patch your bubblewrap if using Flatpak
• Implement the 8-point hardening checklist for production rootless workloads