What did systemd say for the malicious vectors on this change?

Dec 28, 2025, 12:20 by dahlmanatgmail.comyen-mummify-yeah () duck com: This information is to be publicly released on January 6 per requirements of the distro list. This most likely impacts all recent VMs on most modern hypervisors. Thanks, Greg Dahlman Overview DuckDuckGo> did not detect any trackers. > > More <https://duckduckgo.com/-yPPlCVssOmY70ZnFvF-Wddd1QVblRSWUzjDgQW0TwaWlOck8n8Ygc4uUWFOC0MIJjOCjbYQbaDnBbkZETdwzuTGuVfdqEg6gB0ZExR5xaWYrVcTRoiFA6TclKbZwAFTyPnXg5X0PS0OyyEtjYQBJHEzpeSU-hRarcRIWDBFrNec0XCuV8O59Dplp9litlpyij8AzA8uvCO2VQI07SH4enlMeH4OCVIQSCgUfYvHtKDDZ9v0NuPkhurpI4yN5xx-Ac> Unable to verify sender identity Deactivate <https://duckduckgo.com/> This information is to be publicly released on January 6 per requirements of the distro list.

This most likely impacts all recent VMs on most modern hypervisors.

Thanks,

Greg Dahlman

Overview

Systemd v256 change - When the openssh-server package is   installed on a VM with vsock support, systemd now automatically   starts an sshd instance that listens on the afvsock socket in   the global network namespace without any manual configuration.

vsock exists in the global namespace - Unlike "afinet" sockets,   vsock connections are not bound to a particular network namespace.   By default they are visible to every namespace on the host.

Violation of namespace isolation - Users normally expect that   services bound in one namespace cannot be accessed from another   namespace. The global‑namespace vsock listener breaks this   expectation, allowing processes in any namespace to reach the sshd   instance.

Enables malware and lateral movement - Malicious code that runs   inside a container or sandbox can exploit the exposed vsock listener   to connect to the host’s SSH daemon, thereby bypassing   network‑segmentation rules and moving laterally across the   host. This creates a powerful attack vector for malware that can   spread from isolated workloads to the host or other guests without   needing traditional network exposure.

Hard‑to‑audit data path - vsock provides a low‑level,   kernel‑backed IPC channel that is opaque to many security tools. It   can be used by sandboxed programs or containers to send commands or   data to sandboxed programs or containers in a way that is difficult   to monitor or audit.

vsock ss/netstat invisibility - The visibility feature is   isolated in a network namespace, letting processes evade detection   in an already hard‑to‑audit subsystem.

Trivial extension of active threats - If not already being   leveraged, it would be trivial to extend [BRICKSTORM] and [shai-   hulud] to take advantage of vsock as described above. As   [BRICKSTORM] is already leveraging vsock on VmWare, it is unlikely it   is not already being used by advanced threats.

[BRICKSTORM] > https://www.cisa.gov/news-events/analysis-reports/ar25-338a#AppC

[shai-hulud] > https://www.wiz.io/blog/shai-hulud-2-0-aftermath-ongoing-supply-chain-attack

This information is to be publicly released on January 6 per requirements of the distro list.

This most likely impacts all recent VMs on most modern hypervisors.

Thanks,

Greg Dahlman

Overview

Systemd v256 change - When the openssh-server package is installed on a VM with vsock support, systemd now automatically starts an sshd instance that listens on the afvsock socket in the global network namespace without any manual configuration.

vsock exists in the global namespace - Unlike "afinet" sockets, vsock connections are not bound to a particular network namespace. By default they are visible to every namespace on the host.

Violation of namespace isolation - Users normally expect that services bound in one namespace cannot be accessed from another namespace. The global‑namespace vsock listener breaks this expectation, allowing processes in any namespace to reach the sshd instance.

Enables malware and lateral movement - Malicious code that runs inside a container or sandbox can exploit the exposed vsock listener to connect to the host’s SSH daemon, thereby bypassing network‑segmentation rules and moving laterally across the host. This creates a powerful attack vector for malware that can spread from isolated workloads to the host or other guests without needing traditional network exposure.

Hard‑to‑audit data path - vsock provides a low‑level, kernel‑backed IPC channel that is opaque to many security tools. It can be used by sandboxed programs or containers to send commands or data to sandboxed programs or containers in a way that is difficult to monitor or audit.

vsock ss/netstat invisibility - The visibility feature is isolated in a network namespace, letting processes evade detection in an already hard‑to‑audit subsystem.

Trivial extension of active threats - If not already being leveraged, it would be trivial to extend [BRICKSTORM] and [shai- hulud] to take advantage of vsock as described above. As [BRICKSTORM] is already leveraging vsock on VmWare, it is unlikely it is not already being used by advanced threats.

[BRICKSTORM] https://www.cisa.gov/news-events/analysis-reports/ar25-338a#AppC

[shai-hulud] https://www.wiz.io/blog/shai-hulud-2-0-aftermath-ongoing-supply-chain-attack