Bug 1623184 (CVE-2018-15919) - CVE-2018-15919 openssh: User enumeration via malformed packets in authentication requests
Summary: CVE-2018-15919 openssh: User enumeration via malformed packets in authenticat...
Alias: CVE-2018-15919
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1623185 1623186 1661050
Blocks: 1623187
TreeView+ depends on / blocked
Reported: 2018-08-28 16:38 UTC by Laura Pardo
Modified: 2023-03-24 14:12 UTC (History)
34 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
OpenSSH server was found to respond differently to failed GSSAPI authentication attempts when the target user existed versus when that user did not exist. A remote attacker could use this bug to test for the existence of particular usernames on a target system.
Clone Of:
Last Closed: 2021-10-27 10:54:48 UTC

Attachments (Terms of Use)

Description Laura Pardo 2018-08-28 16:38:05 UTC
A flaw was found in OpenSSH versions from 5.9 (September 6, 2011) to the recently released 7.8 (August 24, 2018), inclusive. A remotely observable behaviour in auth-gss2.c could be used by remote attackers to detect existence of users on a target system when GSS2 is in use. Similar to CVE-2018-15473 (it is not a timing attack)


Comment 1 Laura Pardo 2018-08-28 16:38:48 UTC
Created openssh tracking bugs for this issue:

Affects: fedora-all [bug 1623185]

Comment 9 Shuai Song 2018-12-04 10:28:43 UTC
Hi everyone, Will this cve be fixed in redhat7 ? 

looking for your reply.Thanks.

Comment 13 fabio.goia 2019-06-27 19:35:44 UTC
Hi everybody

I didn't find an update for this issue to the RHEL 7. 
Is there a fix?


Comment 14 wangye 2019-09-25 03:44:22 UTC
Is this vulnerability still not fixed? Is there a fix? Still think that "system libraries will not treat this type of information leakage as a threat, because the username is considered to be a non-secret part of the user's identity, and an attacker without a password is useless"?

Comment 21 Doran Moppert 2020-02-11 23:03:08 UTC

If GSSAPI Authentication is not required, this flaw can be mitigated by changing the global configuration in `/etc/ssh/sshd_config` from `GSSAPIAuthentication yes` to `GSSAPIAuthentication no`.

Comment 22 Jakub Jelen 2020-02-12 07:02:02 UTC
I updated the doc text. There is nothing like OpenSSHD (even though it is mentioned in few of the advisories. I remember there was something like this for windows, but I can not find it now. We ship OpenSSH in RHEL and its server is called sshd. I would keep it as "OpenSSH server" or sshd, not the combination of both.

Note You need to log in before you can comment on or make changes to this bug.