Lifecycle Timeline
1DescriptionNVD
Alpine Linux: openssh fixed in 10.1_p1-r0
AnalysisAI
OpenSSH on Alpine Linux was patched in version 10.1_p1-r0, addressing an unspecified security vulnerability tracked as CVE-2025-61985. The nature of the flaw, affected versions prior to the fix, and the attacker-accessible impact have not been disclosed in the available intelligence. No public exploit has been identified at time of analysis, and the EPSS score of 0.06% (19th percentile) suggests low observed exploitation probability.
Technical ContextAI
OpenSSH is the widely deployed SSH daemon and client suite used for encrypted remote access. Alpine Linux packages OpenSSH and maintains its own patch cadence; the fix version 10.1_p1-r0 corresponds to Alpine's packaging of OpenSSH 10.1 patch level 1 with Alpine-specific revision 0. No CWE classification was provided in the available data, making it impossible to confirm the root cause class - possible categories for OpenSSH vulnerabilities historically include memory corruption, authentication bypass, information disclosure, or privilege escalation, but none can be attributed here without vendor disclosure. No CPE strings were provided to further narrow the affected component.
Affected ProductsAI
Alpine Linux systems running OpenSSH versions prior to 10.1_p1-r0 are affected. The specific Alpine Linux release branches (e.g., Alpine 3.x edge, stable) that contain the vulnerable package have not been enumerated in the available data. No CPE strings were provided to confirm the exact package scope. Administrators should consult the Alpine Linux security tracker and package changelogs for the full list of affected branches.
RemediationAI
Upgrade the openssh package on Alpine Linux to version 10.1_p1-r0 or later using the Alpine package manager: 'apk update && apk upgrade openssh'. This is the vendor-confirmed fix per the Alpine Linux security advisory. If an immediate upgrade is not possible, consider restricting SSH access via firewall rules to trusted IP ranges, disabling password authentication in favor of key-based auth (already a best practice), and monitoring SSH daemon logs for anomalous activity. No specific workaround was detailed in the available data because the vulnerability type is unknown - these compensating controls are general SSH hardening measures and may not directly address the specific flaw. No upstream OpenSSH advisory URL was provided in the intelligence data.
Share
External POC / Exploit Code
Leaving vuln.today