Hi — I'm publishing my first Medium piece, so hello, internet! This isn't a tale of dramatic exploitation or flashy shell access. It's a small recon story: how routine tooling, a little curiosity, and careful reporting uncovered an information-disclosure bug in a publicly reachable Jira instance. I can't reveal the target (I removed the subdomain), but I will walk you through what happened, how I found it, and what I did next.

Opening scene — the hunt begins

I started my usual morning recon ritual: collect as many surface points as I can, then focus on the ones that look juicy.

My aim wasn't to break anything — just to see what an unauthenticated visitor could learn about an externally facing app. I often find that the most useful weaknesses are the boring ones: outdated software, forgotten endpoints, and configuration choices that leak information.

The target in this story turned up while I was processing a long list of URLs I'd gathered with automated tooling. The commands I ran looked familiar:

gau domain.com > urls.txt
gau domain.com | awk -F/ '{print $3}' | sort -u > subdomains.txt
cat subdomains.txt | httprobe -s -p https:443 -t 50 > live.txt

I won't paste the domain here (I redacted it), but one of the responding hosts had an accessible Jira web interface. I filtered and prioritized the usual suspects — jira, admin, dev, staging, api — and started poking around the ones that responded.

The moment of curiosity

One of the live hosts looked promising. Nothing dramatic: an externally reachable Jira installation with a few public endpoints. I didn't have credentials, and I wasn't trying brute force or anything noisy. I was simply checking known Jira paths and behaviors for information that's sometimes left exposed.

I tried the /secure/QueryComponent!Default.jspa path and — surprise — it returned readable metadata without requiring authentication. That behavior matched a known issue: CVE-2020-14179, an information-disclosure vulnerability in certain Jira Server / Data Center versions where the query component endpoint can expose custom field names and custom SLA names to unauthenticated users.

Because I can't disclose the exact host, the path I checked looked like this in my notes:

https://[redacted]/secure/QueryComponent!Default.jspa

I verified the output only to the extent that it confirmed the presence of exposed custom field and SLA names. I did not attempt to enumerate or exfiltrate sensitive issue data.

A quick check on the public record

To be thorough, I did a little internet digging. I found an older report by nagli on HackerOne that described something very similar. That gave me confidence I wasn't seeing a one-off fluke — this was a known class of issue and something that deserved a tidy, professional report.

Armed with that context, I collected everything I could reasonably include without exposing private content: the minimal reproduction, a screenshot showing the metadata (no sensitive ticket data), the CVE reference, and a concise remediation recommendation.

The report — VDP, not a bounty program

The organization didn't have a public bug-bounty program, but they did have a Vulnerability Disclosure Policy (VDP). I opened a report through the VDP with:

• A concise summary (CVE-2020–14179 — unauthenticated information disclosure via /secure/QueryComponent!Default.jspa)
• Impact statement (custom field and SLA names exposed; reconnaissance value)
• Minimal reproduction steps and the CVE link
• Suggested remediation (upgrade to patched Jira; harden public endpoints)

Then I sent it off and waited. (Yes — "waited.")

The slow part — triage, patience, and a decent outcome

Triage took a while. Longer than I hoped. The silence was the worst part — that weird limbo where you don't know if your report landed in the right inbox. Eventually the security team replied. They confirmed the issue and forwarded my submission to their global bounty team for further handling.

Did I get a bounty? No — they didn't award anything for this one. But despite the slow back-and-forth and the lack of monetary reward, it felt good: the issue was acknowledged, it moved into the organization's triage pipeline, and the domain stays redacted here because I can't disclose it publicly. That outcome — responsible handling and remediation — is what matters most.