CVE-2026-55168 is a symlink traversal vulnerability in Runtipi's backup restore flow. The bug is straightforward: the restore mechanism deserializes archive contents without checking whether extracted entries are symlinks, allowing an attacker to write files outside the intended directory boundary. The fix—adding an isSymlink() check before writeTextFile calls—is textbook defensive coding. What makes this worth your attention isn't the technique; it's the gap between what the code was intended to do and what it actually does.
The restore endpoint accepts archives and writes their contents to disk under the Runtipi process's permissions. For a homeserver product, those permissions are significant: Runtipi orchestrates application state, manages config directories, and controls how services start. A symlink to ~/.ssh/authorized_keys gets you persistent shell access. A symlink to a docker-compose override gets you runtime container execution. The CVSS 6.5 scores 'write to arbitrary path' as medium severity, but CVSS can't model what paths are actually reachable from that write primitive in a homeserver orchestrator's blast radius.
More concerning: the 'authenticated attacker required' prerequisite in the CVSS is misleading in practice. If the attack vector is a malicious backup file handed to the restore flow, no authentication is needed at all—you're not exploiting a running instance, you're feeding it poison. For deployments where users share backup archives from forums, GitHub gists, or cloud storage, the authentication barrier collapses entirely. The restore flow treats archives as trusted data, not attacker-controlled artifacts.
Check your Runtipi deployment for: whether the backup restore endpoint requires authentication and whether that authentication is actually enforced; whether the backup creation path has the same symlink-following behavior (if archives are created by walking directories without symlink checks, you've got a two-way vulnerability); and whether Runtipi's process permissions have been sandboxed from ~/.ssh, docker configs, and other sensitive paths. The symlink check fix addresses the symptom, but the real remediation is auditing what the Runtipi process is allowed to touch—and treating the backup restore flow as a first-class security surface, not just a data migration feature.