How an avatar endpoint led to a complete Jira takeover with the highest administrative privileges.

When assessing a seemingly hardened web application with strong access controls, it's often the forgotten, legacy, or seemingly benign features that provide the keys to the kingdom. In a recent penetration test, what was intended to be a simple endpoint for fetching profile avatars turned out to be an unconstrained proxy into the company’s entire Atlassian Jira infrastructure.

The result? A low-privileged, authenticated attacker could bypass all frontend access controls, achieve Atlassian instance administration, and extract highly sensitive company data - including full user lists, projects, synced Jira services, VPN configuration files, and plaintext passwords.

Here is a technical breakdown of the Jira API proxy takeover. The Vulnerability: An Unconstrained API Proxy The vulnerability resides in the fnJira.loadAttachment function, exposed via the service.php endpoint.

Under normal circumstances, the application uses this endpoint for benign tasks, such as retrieving user avatars. To do this, it accepts a user-supplied path parameter and appends it directly to the backend Jira base URL (redacted-projects.atlassian.net).

The fatal flaw is twofold:

• Lack of Validation: The application performs no allow-listing or validation on the path parameter.

• Hardcoded High-Privilege Credentials: The backend server executes these proxied requests using a hardcoded service account ([email protected]) that possesses instance-wide administrative privileges, completely ignoring the permissions of the actual user making the request.

By manipulating the path parameter, an attacker can redirect the backend to query arbitrary endpoints within the Jira REST API. The Benign Request By default, the web application makes the following request to fetch avatar data (an SVG image): The server happily responds with the SVG data. But what happens if we change the API path? The Attack: Escalating to Jira Administrator Since the application functions as a blind proxy, we can replace the avatar path with any valid Jira REST API endpoint. The following proofs of concept demonstrate the critical impact of this design flaw.

1. Checking Permissions (Who am I?) First, we need to understand the context of the service account executing our requests. By calling /rest/api/3/mypermissions, we can see exactly what we are dealing with. The Request (whoami?): The response: Result: The service account has global administrative rights over the Jira instance. 2. Reconnaissance (What can I see?) With administrative privileges confirmed, the next step is instance enumeration. By requesting /rest/api/2/project and /rest/api/2/users/search, an attacker can map out the entire organization. The Request (Listing Projects): This returned a response with massive JSON blob (150+ KB) detailing every internal project, including descriptions, leads, and internal URLs. A similar request to the /users/search endpoint returned complete user enumeration for the Atlassian instance. The Request (Listing All Users): This returned a response with all users and services: 3. Data Exfiltration (Taking the loot) development and IT operations, it is a goldmine for sensitive information.

By querying specific attachment IDs, it was possible to download internal files directly through the proxy. The Request (Downloading an attachment): The Impact: Through this method, it was possible to enumerate projects containing VPN configuration files, plaintext passwords, and other highly sensitive data. This goes far beyond compromising issue tracking - it provides an attacker with the initial access material required to pivot directly into the internal corporate network.

While not explicitly tested to avoid disruption, the CREATE_ISSUES and EDIT_ISSUES permissions indicate that an attacker could also inject malicious comments, alter software development tickets, or modify project scopes. Remediation To secure this endpoint and prevent future proxy abuse, the following recommendations were provided:

• Rotate Credentials Immediately: The [email protected] Atlassian credentials must be considered compromised and rotated.
• Enforce Least Privilege: Service accounts should never have global administrative rights if their only job is to fetch attachments. Use scoped API tokens with minimal, read-only permissions limited specifically to the required project or asset type.
• Remove Path Manipulation: Do not pass raw API paths from the client to the server. The application should only accept a specific identifier (e.g., an attachmentID) and construct the Jira API URL server-side.
• Implement Strict Allow-listing: If proxying is absolutely necessary, strictly whitelist the permitted API endpoints on the server side so that only /rest/api/2/universal_avatar/... requests are processed.