PatchSiren cyber security CVE debrief
CVE-2012-0814 OpenBSD CVE debrief
CVE-2012-0814 describes an information disclosure issue in OpenSSH sshd where debug messages can reveal authorized_keys command options to authenticated remote users. In environments that rely on shared accounts, forced commands, or restricted shells, that leaked data can cross a privilege boundary because the affected user may not otherwise have legitimate access to the authorized_keys file. The issue is low severity overall, but it is worth addressing wherever SSH logs are broadly accessible or where account separation is intentionally tight.
- Vendor
- OpenBSD
- Product
- OpenSSH
- CVSS
- LOW 3.5
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2012-01-27
- Original CVE updated
- 2026-04-29
- Advisory published
- 2012-01-27
- Advisory updated
- 2026-04-29
Who should care
Administrators and security teams running OpenSSH on systems that use shared SSH accounts, Gitolite-style workflows, forced-command entries, restricted shells, or any setup where access to authorized_keys content is intentionally limited. Log consumers and platform teams should also care if sshd debug output is retained or exposed to non-admin users.
Technical summary
The vulnerable function, auth_parse_options in auth-options.c, can emit debug messages containing command options from authorized_keys entries. Because the messages may be readable by the authenticated user who triggers the login path, the disclosure can reveal configuration details that were meant to stay private. NVD maps the issue to information disclosure (CVSS vector AV:N/AC:M/Au:S/C:P/I:N/A:N; CWE-255). The supplied record indicates affected OpenSSH versions broadly before the fixed release line, while the NVD CPE list enumerates vulnerable versions through 5.5; treat that boundary as record data that should be verified against vendor guidance for your package line.
Defensive priority
Low overall, but higher priority in shared-account or forced-command deployments because the disclosure can leak sensitive SSH access-control details across intended user boundaries.
Recommended defensive actions
- Upgrade OpenSSH to a version that includes the vendor fix, using your distribution or OpenBSD/OpenSSH advisory guidance to confirm the correct release boundary for your package line.
- Reduce or avoid sshd debug logging in production, especially where authenticated users can see logs or diagnostic output.
- Review authorized_keys usage for forced-command entries and other sensitive command options that should not be exposed to the account holder.
- Audit shared-account and Gitolite-style deployments for privilege-boundary assumptions; split accounts where feasible so users do not share SSH identities.
- Restrict access to sshd logs and related diagnostics to administrators only.
- Verify whether your deployed OpenSSH build is within the vulnerable range identified by the CVE record and NVD criteria before scheduling remediation.
Evidence notes
The CVE record is dated 2012-01-27, and the NVD record was later modified on 2026-04-29; that later modification is record maintenance, not the vulnerability date. The NVD metadata ties the issue to sshd in OpenSSH and includes oss-security references dated 2012-01-26 and 2012-01-27, plus Debian and Juniper references. The supplied record also contains a version-scope inconsistency to watch: the textual description says OpenSSH before 5.7, while the NVD CPE list enumerates vulnerable versions through 5.5.
Official resources
Publicly disclosed in January 2012, with the CVE published on 2012-01-27. The record was modified later on 2026-04-29, which should not be treated as the issue date.