CVE-2020-14181: Atlassian Jira user enumeration, unauthenticated
The short version: CVE-2020-14181 lets an unauthenticated attacker enumerate valid users on Jira Server and Data Center via the /secure/ViewUserHover.jspa endpoint. It confirms which usernames exist — useful raw material for password spraying, but not access by itself.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — a reconnaissance leak, not a compromise |
| CVSS v3.1 (NVD) | 5.3 — Medium · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| EPSS | 99.60% · 99.94th percentile (2026-07-17) |
| In CISA KEV? | No |
| Known exploited? | Not confirmed as in-the-wild; commonly bundled in Jira recon tooling |
| Vulnerability type | CWE-200 information exposure → unauthenticated username enumeration |
| Requires authenticated session? | No — pre-authentication |
| Affected | Jira Server & Data Center: before 7.13.6; 8.0.0–8.5.6; 8.6.0–8.11.x |
| Fixed in | 7.13.6 · 8.5.7 · 8.12.0 (and later) |
What you need to know
The ViewUserHover.jspa endpoint responds differently for valid versus invalid usernames, letting an unauthenticated attacker confirm which accounts exist. That's a list of real usernames — the first half of a credential-guessing attack, which normally has to guess both the username and the password.
- How they find it — internet-wide scanning flags exposed Jira; the endpoint answers without a login.
- How they use it — build a validated username list, then attempt password spraying (a few common passwords across many known-good accounts, low and slow).
- What it leads to — no direct access on its own, but a meaningfully easier path if accounts use weak or reused passwords and MFA isn't enforced.
As with its sibling CVE-2020-14179, the EPSS number is high because the flaw is trivial and widely scanned — that's likelihood of attempt, not severity of impact.
How serious we see it
Low. Enumerating usernames is reconnaissance, not a breach — there's no code execution and no data access. The reason to close it is that it removes the free half of a spraying attack. The real defense against what this enables is strong, unique passwords and enforced MFA; fix those and the enumeration loses most of its value. It's also a useful signal that the instance is behind on updates.
What to do
- Patch. Upgrade to Jira Server / Data Center 7.13.6 / 8.5.7 / 8.12.0 or later.
- Enforce MFA and kill weak/reused passwords. This defeats the spraying that enumeration feeds, even when usernames are known.
- Restrict exposure and monitor auth failures. Keep Jira behind SSO/VPN where practical; alert on spray patterns (many accounts, few passwords).
- Confirm your exposure first. Verify whether any Jira instance is internet-facing and on an affected build.
How BreachRisk sees it
BreachRisk discovers internet-facing Jira from little more than your domain, fingerprints the product and version, and flags version-based exposures like this one. Where active testing is enabled, it can safely confirm the endpoint behaves as vulnerable — a benign, bounded check — so the finding is reported as verified and ranked honestly next to the higher-impact items on your attack surface.