This article is based on original reporting by BleepingComputer (2019) and research by security engineer Avinash Jain.
Overview
Misconfigured Jira instances operated by well-known technology companies, government bodies, and educational institutions were found to be exposing sensitive internal data to unauthenticated users on the public internet. The exposure included employee names, email addresses, job roles, and details about ongoing projects — information that could be exploited for reconnaissance, targeted phishing, or competitive intelligence gathering.
The issue was discovered and disclosed by Avinash Jain, a security engineer, who reported findings to affected organisations including NASA and the United Nations. BleepingComputer independently verified that the misconfigured instances could be located using advanced search operators (commonly known as Google Dorks).
What Is Jira and Why Does It Hold Sensitive Data?
Jira, developed by Atlassian, is one of the most widely adopted project management and issue-tracking platforms in the world. Agile engineering teams use it to track tasks, bugs, sprints, and releases. Because Jira sits at the heart of development workflows, it inevitably contains details about internal projects, team structures, personnel, and organisational priorities — making it a high-value target if access controls are misconfigured.
The Root Cause: A Visibility Misconfiguration
According to Jain, the core problem lies in how Jira Cloud handles the default visibility setting for filters and dashboards. When a user creates a new filter or dashboard, the default sharing option is set to “All”. Many administrators and users reasonably interpret this to mean “all members of the organisation,” but in practice it means all users on the internet — including unauthenticated visitors.
Two configuration paths contribute to this exposure:
- Public filter and dashboard sharing: Jira Cloud allows filters and dashboards to be shared with a “Public” option. Atlassian’s own documentation warns that “if a filter or dashboard is shared with Public, the name of the filter or dashboard will be visible to anonymous users.” Many organisations enabled this without realising the full scope of what becomes accessible.
- Global Permissions — “Anyone” access: In the Global Permissions menu, administrators can grant access to users who are not logged in by selecting “Anyone” from a drop-down list. Atlassian’s documentation explicitly notes this is not recommended for systems accessible from the public internet, such as Jira Cloud. Despite this warning, many organisations left this setting enabled.
Once anonymous access is enabled at either level, Jira’s built-in user picker functionality can be used to retrieve a complete list of usernames and email addresses registered on that instance — without any authentication required.
How Misconfigured Instances Were Discovered
Jain used Google Dorks — carefully crafted search queries that leverage advanced Google search operators — to identify publicly accessible Jira instances exposing user and project data. This technique requires no special tools or credentials; it relies entirely on data that search engines have already indexed from misconfigured public-facing servers.
BleepingComputer confirmed that applying these search operators surfaced government domains, private companies, and educational institutions among the affected instances. The breadth of exposure was significant: Jain reported finding misconfigured Jira accounts across hundreds of companies, including organisations listed in the Alexa and Fortune top rankings.
“Thousands of companies’ filters, dashboards and staff data were publicly exposed. I have discovered several such misconfigured JIRA accounts in hundreds of companies. Some of the companies were from Alexa and Fortune top list including big giants like NASA, Google, Yahoo, etc and government sites.”
— Avinash Jain, Security Engineer
Organisations Affected
Named organisations reported to have been affected at the time of discovery included Google, Yahoo, NASA, Lenovo, 1Password, Zendesk, and a number of government bodies worldwide. Jain responsibly disclosed his findings to affected parties. Notable acknowledgements he received include:
- NASA: A previously discovered misconfigured Jira server exposed the names and email addresses of approximately 1,000 users. Jain reported this responsibly and was recognised by NASA.
- United Nations: The UN acknowledged Jain’s disclosure and recognised his role in improving their security posture.
- CODIX: A financial software solution used by European Union institutions and agencies, which also recognised Jain’s responsible disclosure.
Why This Matters: Reconnaissance and Attack Surface
Leaking employee names, email addresses, and project details may not seem as immediately dangerous as exposing passwords or financial records, but this data is highly valuable for attackers in the early stages of an attack:
- Spear phishing: Knowing which employee works on which project — and their email address — enables highly targeted phishing emails that are far more convincing than generic attempts.
- Social engineering: Role and project information helps attackers impersonate colleagues or vendors credibly.
- Competitive intelligence: Exposed project names, sprint goals, and task descriptions can reveal product roadmaps and strategic initiatives to competitors.
- Credential stuffing preparation: A validated list of real email addresses from an organisation can be fed directly into automated credential stuffing attacks against other services.
How to Audit and Fix Jira Visibility Settings
Jira administrators should review the following settings to close these exposure paths:
1. Review Global Permissions
Navigate to Settings → System → Global Permissions. Check whether “Browse Users” or “Use Jira” permissions are granted to “Anyone (including anonymous users).” Remove anonymous access unless there is a documented and deliberate reason to allow it.
2. Audit Filter and Dashboard Sharing
Review all shared filters and dashboards. Any item shared with “Public” or “All” should be reassessed. Change sharing to specific groups or projects rather than organisation-wide or public defaults.
3. Disable Anonymous Access to Projects
For each project, check Project Settings → Permissions. Ensure that “Browse Projects” is not granted to “Anyone” unless the project is intentionally public-facing.
4. Restrict User Picker Access
The user picker API endpoint can enumerate all users on an instance when anonymous access is enabled. Restricting anonymous access at the Global Permissions level prevents unauthenticated enumeration.
5. Use Atlassian’s Built-in Security Advisor
Jira Cloud includes a Security Advisor tool under site administration that flags common misconfigurations, including overly permissive anonymous access settings. Run this regularly as part of routine security reviews.
Key Takeaways for DevOps and Platform Teams
- Default settings in SaaS tools are not always secure by default — always validate permission configurations after initial setup and after major upgrades.
- “Visible to all” in a cloud tool frequently means the entire internet, not just your organisation. Read documentation carefully.
- Regularly audit third-party project management and collaboration tools as part of your organisation’s attack surface management programme.
- Google Dorks are a free, low-skill method attackers use to find misconfigured systems. If an attacker can find your Jira instance this way, you will want to know before they do.
- Responsible disclosure by external researchers is valuable — organisations should have a clear vulnerability disclosure policy and acknowledge reports promptly.