This article is based on reporting originally published by Bleeping Computer and Techworm in 2019, citing research conducted by security engineer Avinash Jain.
Overview
An India-based security engineer named Avinash Jain discovered that hundreds of organizations — including NASA, Google, Yahoo, Western Union, Lenovo, and numerous government agencies — had misconfigured their Jira project management servers in ways that exposed internal project data, employee names, and email addresses to the open internet. The exposed data was indexed by search engines, making it discoverable by anyone with knowledge of advanced search operators (commonly called Google Dorks).
The vulnerability was not a software bug in Jira itself, but rather the result of default permission settings that many administrators misunderstood. The research was reported by Bleeping Computer and drew widespread attention from the security community.
What Is Jira?
Jira is a proprietary issue tracking and project management platform developed by Atlassian. It is widely used for bug tracking, agile sprint planning, and task management across software development teams. Its popularity among Fortune 500 companies and government agencies makes misconfigurations at scale particularly consequential.
Root Cause: Default Permission Settings
The core problem stemmed from how Jira handles the default visibility of filters and dashboards. When a user creates a new filter or dashboard in Jira, the default visibility is set to “All users” (for filters) and “Everyone” (for dashboards). Many administrators and end users interpreted these labels as meaning “everyone within the organization.” In practice, these settings expose the content to any user on the public internet, including unauthenticated visitors.
Jira’s own documentation includes a disclaimer for the “Public” sharing option: “If a filter or dashboard is shared with the Public, the name of the filter or dashboard will be visible to anonymous users.” However, many administrators either missed this warning or did not appreciate its implications for internet-facing Jira Cloud instances.
An additional setting in the Global Permissions menu allows administrators to grant access to the “Anyone” user group, which includes users who are not logged in. Atlassian’s own documentation explicitly notes this is not recommended for systems accessible from the public internet, including Jira Cloud.
What Data Was Exposed?
Because Jira includes a user picker functionality that enumerates account users, misconfigured servers exposed the following types of sensitive information to anonymous visitors:
- Full names and email addresses of employees across affected organizations
- Employee roles, as inferred from Jira group memberships
- Active and upcoming projects, milestones, and task assignments via dashboards and filters
- Internal project structure and workflow details
Jain noted in his report: “Thousands of companies’ filters, dashboards and staff data were publicly exposed. It occurs because of the wrong permissions scheme set to filters and dashboards, hence providing their access even to non-logged-in users and leading to leaking of sensitive data.”
Affected Organizations
According to Jain’s research, affected organizations spanned private industry and the public sector globally. He cited examples including:
- Technology companies: Google, Yahoo, HipChat, Zendesk, Dubsmash
- Enterprise and financial firms: Western Union, Lenovo, Informatica, Sapient, 1Password
- Ride-sharing and consumer apps: Go-Jek
- Government and public sector: NASA, the United Nations, the Brazilian government transport portal, the Canadian government finance portal, and an unspecified European government portal
Bleeping Computer independently verified the vulnerability and confirmed they were able to locate government domains, private firms, and educational institutions through standard search engine queries.
How the Servers Were Discovered
Jain identified the vulnerable servers using Google Dorks — specialized search operators that target publicly indexed pages with specific URL patterns or content characteristics typical of Jira dashboards and user picker endpoints. Because the exposed pages were indexed by major search engines, no authentication or exploitation tool was required to locate them.
This highlights a significant operational security risk: data exposed through misconfiguration is often passively discoverable long before any targeted attacker finds it. In this case, the same technique could be used by competitors conducting corporate espionage or by threat actors mapping out personnel and project structures for phishing or social engineering campaigns.
Disclosure and Prior Research
Jain responsibly disclosed his findings to the affected organizations. This was not his first discovery of this type: in a prior engagement, he had identified a misconfigured Jira server exposing names and email addresses of approximately 1,000 NASA users. That issue was reported to NASA and subsequently fixed.
How to Audit and Fix Jira Permissions
Organizations running Jira Cloud or Jira Server instances should audit their permission configurations immediately. Key areas to review:
- Global Permissions: Navigate to Jira Administration → System → Global Permissions and confirm that the “Anyone” group is not granted “Browse Users,” “Create Shared Objects,” or similar permissions on internet-facing instances.
- Filter and Dashboard sharing: Audit existing filters and dashboards for those shared with “Public” or “Everyone.” Change these to specific groups or project roles where broad sharing is not required.
- Anonymous access: Disable anonymous access for any Jira project that does not have a deliberate and documented business reason to be publicly readable.
- User picker exposure: Ensure that the user picker REST endpoint (
/rest/api/2/user/picker) is not accessible to unauthenticated users by reviewing Global Permissions for the “Browse Users” permission.
Atlassian provides documentation on managing global permissions and project permissions in both Jira Cloud and Jira Server/Data Center editions. Organizations should treat a periodic permissions audit as a standard part of their DevOps security posture, not a one-time configuration task.
Broader Lessons for DevOps Teams
This incident is a textbook example of a misconfiguration vulnerability — a category that consistently ranks among the most common causes of data exposure in cloud and SaaS environments. Several takeaways apply broadly:
- Default settings are not safe defaults. Convenience-oriented defaults in SaaS tools often prioritize ease of collaboration over least-privilege access. Always review defaults before deploying to a production or internet-accessible environment.
- Labels can mislead. Terms like “Everyone” or “All users” are ambiguous in a SaaS context. Read the accompanying documentation to understand whether the scope is organizational or public internet.
- Search engine indexing amplifies exposure. Data that is publicly accessible will eventually be indexed. Assume that any misconfigured public endpoint will be discoverable without any active scanning by an attacker.
- Routine audits matter. Permission drift occurs as teams grow and configurations change. Automated audits of permission settings should be integrated into security review cycles.
The Jira misconfiguration case serves as a reminder that securing DevOps tooling is as important as securing the applications those tools help build.