TL;DR – With systemd v256+, installing openssh-server on a VM automatically creates a socket activated SSH listener on af_vsock:22 in the global network namespace. This breaks the usual namespace isolation and opens a hidden, low‑visibility channel that malicious code can use to hop from containers or sandboxes straight to the host. It also brings attention to the unprotected, global namespace, vsock loopback that is trivial to use from most languages.

What Changed in Systemd 256?

When the openssh-server package is installed on a virtual machine that has vSock support, systemd now:

• Auto‑starts an socket activated sshd instance
• Binds it to af_vsock in the global network namespace

No manual configuration is required – the change is baked into the package.

Impact Assessment

How to detect:

It should be visable via ss -af vsock in the default namespace

$ ss -af vsock
Netid              State               Recv-Q              Send-Q                           Local Address:Port                             Peer Address:Port              
v_str              LISTEN              0                   0                                            *:22                                        *:*   

Check via systemctl status sshd-vsock.socket

Why Is vSock Different From af_INET?

Because vSock is a kernel‑backed IPC channel, it can bypass traditional network‑segmentation rules that rely on namespace isolation.

The Security Fallout

3.1 Violation of Namespace Isolation

• Expectation: Services started in one namespace should not be reachable from another.
• Reality: The global‑namespace vSock listener lets any process, regardless of its namespace, talk to the host’s sshd.

3.2 Enabling Malware & Lateral Movement

• A container or sandboxed process can now open a vSock connection to the host’s SSH daemon or to another container or sandboxed process.
• No need for port forwarding or network exposure; the attack stays entirely within the host kernel.
• This is a powerful vector for moving laterally across a host or between guests.

3.3 Hard‑to‑Audit Data Path

• vSock is opaque to many security tools; traditional packet sniffers or intrusion detection systems typically ignore it.
• Processes can send commands or data through this channel without leaving a visible footprint.

3.4 Invisibility in ss / netstat

• If a listener or client isolated in a network namespace, tools like ss or netstat will not show vsock connections unless one side is in the default net namespace.
• This makes detection and monitoring even more difficult.

3.5 Extension of Existing Threats

• APTs and malware families that already use or could be trivially modified to use vsock (e.g., BRICKSTORM, shai‑hulud) can simply enable this feature and expand their attack surface.
• Since BRICKSTORM already leverages vSock on VMware, it is likely that APTs are already exploiting this in the wild.

What Should You Do?

Kernel boot string:

Disables systemd sshd vsock listener, will not protect the vsock loopback.

The official way to disable vsock sshd is through a kernel command line parameters or system credentials logic. [systemd-ssh-generator]

 systemd.ssh_auto=no

Mask systemd socket:

This will disable the systemd sshd vsock listener, but will not protect the vsock loopback.

 sudo systemctl mask sshd-vsock.socket

Note: If another unit explicitly wants “sshd-vsock.socket” it may
 be started.

Seccomp:

Add the following to your seccomp profile.

		{
			"names": [
				"socket"
			],
			"action": "SCMP_ACT_ALLOW",
			"args": [
				{
					"index": 0,
					"value": 40,
					"op": "SCMP_CMP_NE"
				}
			]
		},

AppArmor:

This will remove access to the vsock loopback, which will also remove access to the systemd sshd vsock listener for targeted binaries.

Add the following to “/etc/apparmor.d/local/<filename>” for each
high risk command.

 audit deny network vsock,

This should be added to:

Why block the vsock loopback?

Vsock was developed specifically to provide a familiar BSD socket like interface to ease development of Hypervisor/VM communication, it has been known for well over a decade that, just as BSD sockets required namespace support for isolation, that vsock connections are difficult to constrain.

ChromeOS disabled the vsock loopback in 2019, because it was impossible to constrain, fully disabling it requires patching the kernel.