CVE-2020-14179: Atlassian Jira information disclosure, unauthenticated field enumeration
The short version: CVE-2020-14179 lets an unauthenticated attacker view custom field names and custom SLA names on Jira Server and Data Center via the /secure/QueryComponent!Default.jspa endpoint. It leaks configuration metadata, not your data — a reconnaissance aid, not a break-in.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Moderate — an information 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 | 76.04% · 99.48th percentile (2026-07-17) |
| In CISA KEV? | No |
| Known exploited? | Not confirmed as in-the-wild; commonly bundled in Jira recon tooling |
| Vulnerability type | Information disclosure → unauthenticated enumeration of custom field & SLA names |
| Requires authenticated session? | No — pre-authentication |
| Affected | Jira Server & Data Center: before 8.5.8; 8.6.0–8.11.0 |
| Fixed in | 8.5.8 · 8.11.1 (and later) |
What you need to know
The affected endpoint returns custom field and SLA names to anyone who asks, with no authentication. That's configuration metadata — it can reveal how your Jira is set up and hint at internal naming, but it doesn't expose issues, credentials, or user data.
- How they find it — internet-wide scanning flags exposed Jira, and this endpoint responds without a login.
- How they use it — as reconnaissance: naming conventions and workflow structure that help tune later, more targeted attempts.
- What it leads to — on its own, not much. Its value is as one small piece of a larger picture.
Note the high EPSS: prediction models rate exploitation likelihood highly because it's trivial and widely scanned — but likelihood isn't impact, and the impact here is genuinely limited.
How serious we see it
Low. This is an information-disclosure issue that leaks metadata, not sensitive content — there's no code execution and no direct path to access. We don't inflate it just because it's easy to trigger. It's still worth closing: it's a free, no-patch-cycle fix that removes a reconnaissance foothold, and it's a reliable sign the instance is behind on updates that may include more serious ones.
What to do
- Patch. Upgrade to Jira Server / Data Center 8.5.8 or 8.11.1 or later.
- Restrict exposure. Keep Jira behind SSO/VPN where practical rather than open to the whole internet.
- Treat it as a version signal. An instance vulnerable here is likely due for other fixes — review its full patch level.
- 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 responds — a benign, bounded check rather than a data grab — so a low-grade finding is reported as verified rather than a maybe, and prioritized honestly against everything else on your attack surface.