CVE-2022-0540

What it actually does

CVE-2022-0540 is a critical authentication bypass in Jira Seraph, the authentication framework used by Atlassian Jira Server, Jira Data Center, and Jira Service Management Server/Data Center. A remote unauthenticated attacker can send a specially crafted HTTP request that causes protected Jira functionality to be reached without valid credentials. Because the vulnerability is network-exploitable, requires no user interaction, and can compromise confidentiality, integrity, and availability, successful exploitation may allow unauthorized access to Jira data and actions that should require authentication.

Why it matters to the business

Exploitation can expose sensitive project data, tickets, attachments, comments, customer support records, development workflows, internal discussions, and operational information stored in Jira. Attackers may alter issues, disrupt service management processes, create or modify accounts or tickets depending on reachable functionality, and use Jira as a foothold for broader intrusion. The EPSS score is very high and exploit maturity is reported as weaponized, so internet-facing or partner-accessible Jira instances should be treated as high-priority remediation targets even though this CVE is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies an exposed Jira Server, Jira Data Center, or Jira Service Management instance and determines whether it is running a vulnerable version. They then send a crafted HTTP request targeting Jira paths handled by Seraph authentication logic. If the instance is vulnerable, the request is processed as though authentication requirements were satisfied or improperly skipped, allowing the attacker to reach restricted Jira resources without valid credentials. From there, the attacker may enumerate projects and issues, access sensitive ticket contents or attachments, make unauthorized changes where functionality permits, and potentially chain the access with other Jira misconfigurations, plugin vulnerabilities, weak permissions, or credential harvesting to expand control.

How to fix it

Upgrade affected Atlassian products to fixed versions. For Jira Server and Jira Data Center, upgrade to 8.13.18 or later for the 8.13 LTS line, 8.20.6 or later for the 8.20 line, or 8.22.0 or later for 8.21 and newer lines. For Jira Service Management Server and Data Center, upgrade to 4.13.18 or later for the 4.13 LTS line, 4.20.6 or later for the 4.20 line, or 4.22.0 or later for 4.21 and newer lines. If immediate upgrade is not possible, restrict external access to Jira through VPN, trusted IP allowlists, reverse proxy authentication, or network segmentation; disable unnecessary public exposure; and review Atlassian guidance for any supported temporary mitigations. Because authentication bypass flaws can expose data before normal application controls are enforced, compensating controls should be treated as temporary and not a substitute for patching.

How to confirm the fix worked

Confirm the installed Jira or Jira Service Management version is outside the vulnerable ranges: Jira Server/Data Center before 8.13.18, 8.14.0 through before 8.20.6, and 8.21.0 through before 8.22.0; Jira Service Management Server/Data Center before 4.13.18, 4.14.0 through before 4.20.6, and 4.21.0 through before 4.22.0. Validate using the application administration interface, build information, package inventory, deployment manifests, or Atlassian support zip output. For externally reachable deployments, perform authenticated and unauthenticated testing against known protected resources to ensure unauthenticated requests are redirected to login or denied. Also verify reverse proxy, SSO, and network access controls are still enforcing the intended access policy after upgrade.

Typical attack path

1. Discover an exposed Jira Server, Jira Data Center, or Jira Service Management instance over HTTP or HTTPS.
2. Fingerprint the application version, product type, or behavioral indicators to determine whether it falls in a vulnerable release range.
3. Send a specially crafted unauthenticated HTTP request that abuses Jira Seraph authentication handling.
4. Access protected Jira resources or workflows without a valid login session.
5. Enumerate projects, issues, users, comments, attachments, dashboards, service desk queues, or other available data.
6. Perform unauthorized actions available through the bypassed context, such as viewing, modifying, or creating content where permitted.
7. Use obtained information, credentials, tokens, or internal operational details to support lateral movement or additional attacks.

How to detect it

Review HTTP access logs from Jira, reverse proxies, load balancers, WAFs, and identity-aware proxies for unauthenticated requests that successfully reached protected Jira endpoints instead of receiving redirects to login or 401/403 responses. Focus on requests from unfamiliar internet sources, high-volume enumeration, unusual user agents, missing or empty session cookies, and access to issue, project, attachment, dashboard, administrative, or service desk paths. Compare web access logs with Jira application audit logs: suspicious cases include protected-resource access with no corresponding successful login, anonymous activity against resources that should not allow anonymous access, unexpected changes to issues or configuration, and downloads of attachments without a normal authenticated session trail. Review Atlassian application logs such as atlassian-jira.log, access_log files, catalina logs, reverse proxy logs, WAF logs, and SSO/IdP logs. Since this vulnerability is an authentication bypass rather than a malware dropper, reliable host-level IOCs are unlikely; detection should emphasize behavioral evidence of unauthorized unauthenticated access and post-exploitation changes.

• GET /browse/
• POST /browse/
• GET /secure/
• POST /secure/
• GET /projects/
• GET /issues/
• GET /rest/api/2/
• POST /rest/api/2/
• GET /rest/servicedeskapi/
• POST /rest/servicedeskapi/
• GET /plugins/servlet/
• POST /plugins/servlet/
• GET /secure/attachment/
• GET /secure/Dashboard.jspa
• GET /secure/admin/
• POST /secure/admin/
• GET /login.jsp
• GET /secure/MyJiraHome.jspa
• GET /secure/ViewProfile.jspa
• atlassian-jira.log
• access_log
• catalina.out
• JSESSIONID=

What your security team should do

• Prioritize patching all internet-facing or third-party-accessible Jira and Jira Service Management instances due to critical severity, high EPSS probability, and weaponized exploit availability.
• Inventory all Jira Server, Jira Data Center, and Jira Service Management deployments, including staging, disaster recovery, and legacy instances.
• Upgrade to the appropriate fixed version: Jira 8.13.18, 8.20.6, 8.22.0 or later; Jira Service Management 4.13.18, 4.20.6, 4.22.0 or later.
• Temporarily restrict access to trusted networks or VPN-only access until patching is complete.
• Review web access logs for suspicious unauthenticated requests to protected Jira endpoints and unusual HTTP patterns around the time of potential exposure.
• Audit Jira users, groups, permissions, project roles, application links, API tokens, webhooks, automation rules, and recent administrative changes for unauthorized activity.
• Review issue, attachment, and service desk access patterns for large or unusual data reads by anonymous or unexpected users.
• If compromise is suspected, rotate credentials and tokens that may have been stored in Jira tickets, comments, attachments, configuration fields, or service desk records.