CVE-2022-26135

What it actually does

CVE-2022-26135 is an authenticated server-side request forgery vulnerability in the Jira Mobile Plugin batch endpoint. A low-privileged Jira user can cause the Jira Server or Data Center application to issue HTTP requests to attacker-chosen URLs and receive the response content. Because the request originates from the Jira server, the attacker may be able to read data from internal-only services, loopback interfaces, cloud metadata endpoints, or network resources that are not directly reachable from the internet. The flaw primarily affects confidentiality; integrity and availability impact are not the main expected outcomes.

Why it matters to the business

An attacker with any valid Jira account, including one created through public self-signup where enabled, could use the Jira application as a proxy to read sensitive internal data. This may expose cloud credentials, service metadata, internal APIs, application configuration, or other network-restricted information. Jira is often widely deployed and trusted inside enterprise networks, so even though authentication is required, the operational risk is meaningful when public registration, weak account governance, or broad internal network access from Jira is present. The EPSS score is high, indicating elevated likelihood of exploitation in the wild despite the absence of CISA KEV listing.

How an attack unfolds

An attacker first obtains a valid Jira account, either through normal credential compromise, an invited account, or public sign-up if the site permits it. The attacker then sends crafted requests to the Jira Mobile Plugin batch endpoint that instruct Jira to fetch one or more attacker-specified URLs. Instead of the attacker connecting directly to the target resource, Jira performs the outbound request from the server side and returns readable response data to the attacker. The attacker typically probes safe targets first, such as localhost, internal RFC1918 addresses, and cloud metadata IP addresses, then uses successful responses to enumerate internal services or retrieve sensitive data such as instance metadata, tokens, configuration files exposed over HTTP, or internal API responses. If credentials or secrets are obtained, the SSRF may become an initial step toward broader compromise outside Jira.

How to fix it

Upgrade affected Jira installations to fixed versions. For Jira Server and Jira Data Center, upgrade to 8.13.22, 8.20.10, 8.22.4, or later supported versions. For Jira Service Management / Jira Service Desk Server and Data Center, upgrade to 4.13.22, 4.20.10, 4.22.4, or later supported versions. If immediate upgrade is not possible, reduce exposure by disabling public user sign-up, restricting access to Jira to trusted networks or identity providers, reviewing whether the Jira Mobile Plugin is required, and applying network egress controls so the Jira application cannot reach cloud metadata services, loopback-only administrative services, or broad internal address ranges unnecessarily. Where supported by the platform, block access to metadata endpoints such as 169.254.169.254 from application hosts unless explicitly required.

How to confirm the fix worked

Confirm the running Jira and Jira Service Management versions are at or above the fixed version for the deployed release train. Verify that the Mobile Plugin component has been updated as part of the product upgrade. Review access controls to ensure anonymous access or open self-registration is not unintentionally enabled. From a controlled test account, confirm that crafted requests to the mobile batch endpoint cannot retrieve arbitrary external, loopback, internal, or metadata URLs. Validate outbound firewall or proxy controls by confirming the Jira host cannot reach restricted destinations such as localhost-only administrative ports, RFC1918 services not required for Jira operation, and cloud metadata IP addresses.

Typical attack path

1. Obtain a valid low-privileged Jira account or create one through public sign-up if enabled.
2. Identify that the target Jira version includes the vulnerable Mobile Plugin batch endpoint.
3. Send crafted authenticated POST requests to the mobile batch endpoint with embedded attacker-controlled URLs.
4. Use Jira as the network origin to request localhost, internal IP ranges, service discovery endpoints, or cloud metadata services.
5. Read the returned response bodies and refine target URLs based on discovered services or metadata.
6. Extract sensitive data such as internal API output, service banners, configuration details, cloud instance metadata, or temporary credentials.
7. Use any exposed credentials or internal knowledge for follow-on access, lateral movement, or data theft.

How to detect it

Review Jira HTTP access logs, reverse proxy logs, web application firewall logs, and load balancer logs for authenticated requests to the Jira Mobile Plugin batch endpoint. Focus on POST requests to paths such as /rest/nativemobile/1.0/batch or other mobile batch REST paths, especially where request bodies contain absolute URLs, internal IP addresses, localhost references, or cloud metadata addresses. Correlate suspicious requests with Jira audit logs and identity provider logs for new account creation, public sign-up events, unusual logins, or low-privileged users making repeated batch requests. If request bodies are logged by a proxy, WAF, or application logging layer, search for URL schemes such as http:// and https:// inside batch payloads, and for targets including 127.0.0.1, localhost, ::1, 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. On cloud-hosted deployments, examine cloud metadata service access logs or network telemetry where available for requests originating from Jira hosts. Follow up by checking whether sensitive internal endpoints returned data around the same timestamps and rotate exposed secrets if metadata or credential endpoints may have been reached.

• /rest/nativemobile/1.0/batch
• /rest/mobile/1.0/batch
• POST /rest/nativemobile/1.0/batch
• POST /rest/mobile/1.0/batch
• "/rest/nativemobile/1.0/batch" "http://
• "/rest/nativemobile/1.0/batch" "https://
• "/rest/mobile/1.0/batch" "http://
• "/rest/mobile/1.0/batch" "https://
• 169.254.169.254
• metadata.google.internal
• 169.254.169.254/latest/meta-data
• 169.254.169.254/latest/user-data
• 169.254.169.254/metadata/instance
• localhost
• 127.0.0.1
• [::1]
• 0.0.0.0
• 10.
• 172.16.
• 172.17.
• 172.18.
• 172.19.
• 172.20.
• 172.21.
• 172.22.
• 172.23.
• 172.24.
• 172.25.
• 172.26.
• 172.27.
• 172.28.
• 172.29.
• 172.30.
• 172.31.
• 192.168.

What your security team should do

• Prioritize upgrade of internet-accessible Jira Server, Jira Data Center, Jira Service Desk, and Jira Service Management instances to the fixed release trains or newer supported versions.
• Immediately disable public self-signup unless there is a documented business requirement and compensating identity controls are in place.
• Search historical Jira access logs for authenticated requests to mobile batch endpoints, especially requests associated with unusual users, newly created accounts, high request volume, or suspicious target URL patterns.
• Restrict outbound network access from Jira application nodes to only required services; explicitly block cloud metadata endpoints and unnecessary internal address ranges.
• Review newly created Jira accounts, inactive accounts that became active, and accounts with unusual access immediately before suspicious mobile batch requests.
• If evidence of SSRF is found, investigate whether internal services or metadata endpoints were accessed and rotate any credentials or tokens that may have been exposed.
• Add SIEM detections for POST requests to the vulnerable mobile batch endpoint containing URL schemes, loopback addresses, RFC1918 ranges, or cloud metadata addresses.