EUVD-2025-28479
CVSS VectorNVD
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L/S:N/AU:Y/R:U/V:C/RE:M/U:Amber
Lifecycle Timeline
4DescriptionNVD
Improper Link Resolution Before File Access ('Link Following') vulnerability in yrutschle sslh.This issue affects sslh: before 2.2.2.
AnalysisAI
CVE-2025-52936 is a symlink following vulnerability (CWE-59) in sslh before version 2.2.2 that allows local attackers with low privileges to bypass file access controls and potentially achieve high-impact confidentiality and integrity violations. The vulnerability enables attackers to read, modify, or delete sensitive files through improper resolution of symbolic links during file operations. With a CVSS v4.0 score of 9.3 and an attack vector limited to local access requiring low privileges, this is a critical local privilege escalation risk for multi-user systems running vulnerable sslh versions.
Technical ContextAI
sslh is a network protocol demultiplexer that routes incoming connections to different services (SSH, HTTPS, OpenVPN, etc.) based on protocol detection. The vulnerability resides in sslh's file handling operations where symbolic links are not properly validated before access, allowing CWE-59 (Link Following) attacks. When sslh processes files—likely configuration files, PID files, or log files—it follows symbolic links without checking if they point to unintended locations. An attacker with local system access can create malicious symlinks in predictable locations that sslh accesses, causing the application to read from or write to arbitrary files on the system. This is a classic TOCTOU (Time-of-Check-Time-of-Use) or direct symlink-following flaw common in privilege-escalated daemon processes.
RemediationAI
- IMMEDIATE: Upgrade sslh to version 2.2.2 or later from the official yrutschle/sslh GitHub repository (https://github.com/yrutschle/sslh). 2) VERIFY: After patching, restart sslh service and validate symbolic link resolution behavior with test cases. 3) MITIGATION (if immediate patching impossible): Apply strict file system permissions to all directories where sslh operates (config, PID, log directories) using ACLs or umask to restrict local user write access; use SELinux/AppArmor profiles to restrict sslh's file access to explicit whitelist paths only, preventing symlink traversal. 4) MONITORING: Audit /proc/[sslh-pid]/fd to detect unexpected file descriptor opens; monitor file system events in sslh's working directories for symlink creation. 5) CONTAINMENT: If running sslh in containers, ensure unprivileged sslh container process cannot access host symlinks via volume mounts; use read-only mounts where possible.
Vendor StatusVendor
Ubuntu
Priority: Medium| Release | Status | Version |
|---|---|---|
| xenial | needs-triage | - |
| bionic | needs-triage | - |
| focal | needs-triage | - |
| jammy | needs-triage | - |
| noble | needs-triage | - |
| upstream | needs-triage | - |
| plucky | ignored | end of life, was needs-triage |
| oracular | ignored | end of life, was needs-triage |
| questing | needs-triage | - |
Debian
Bug #1108284| Release | Status | Fixed Version | Urgency |
|---|---|---|---|
| bullseye (security) | fixed | 1.20-1+deb11u1 | - |
| bookworm, bullseye | vulnerable | 1.20-1 | - |
| forky, sid, trixie | vulnerable | 2.1.4-1 | - |
| bullseye | fixed | 1.20-1+deb11u1 | - |
| (unstable) | fixed | (unfixed) | - |
Share
External POC / Exploit Code
Leaving vuln.today