CVE-2021-26086

What it actually does

This is an unauthenticated, network-accessible path traversal flaw in Atlassian Jira Server and Jira Data Center. A remote attacker can craft HTTP requests to the /WEB-INF/web.xml endpoint that bypass intended path restrictions and cause Jira to return files that should only be readable by the application server. The direct impact is unauthorized file disclosure, not code execution or service disruption, but exposed configuration files can reveal application structure, security controls, deployment details, and potentially sensitive paths that support further attacks. The affected Jira version ranges are before 8.5.14, 8.6.0 through before 8.13.6, and 8.14.0 through before 8.16.1. The supplied TensorFlow fixed-version metadata does not align with the described Jira vulnerability and should not be used as the remediation source for this issue.

Why it matters to the business

Exploitation can expose internal Jira application files to anyone who can reach the Jira web interface, including unauthenticated internet users where Jira is publicly exposed. While the flaw is scored as moderate because it primarily affects confidentiality, it is listed in CISA KEV, has active in-the-wild exploitation, and has an extremely high EPSS score, so organizations should treat reachable vulnerable Jira instances as high-priority remediation targets. Business consequences may include leakage of deployment details, increased risk of follow-on compromise, incident response costs, and potential exposure of information that helps attackers target issue-tracking workflows and connected systems. CISA KEV remediation was due by 2024-12-03 for covered organizations, making overdue remediation a governance and compliance concern.

How an attack unfolds

An attacker first identifies an exposed Jira Server or Data Center instance and fingerprints the version through normal HTTP responses, static resources, headers, error pages, or public version indicators. If the instance is in an affected version range, the attacker sends unauthenticated HTTP requests targeting the /WEB-INF/web.xml endpoint and may include path traversal sequences or encoded traversal variants to reach files normally protected under the Java web application directory. The vulnerable Jira endpoint mishandles path normalization or access control and returns file contents that should not be directly served. The attacker reviews the disclosed data for application configuration, servlet mappings, security filters, internal paths, plugin details, or other deployment clues. They may then use that information to plan additional Jira-specific attacks, credential attacks, exploitation of other vulnerabilities, or targeted reconnaissance against integrations. This vulnerability is known to be exploited in the wild and should be investigated as a possible precursor to broader Jira compromise even though the vulnerability itself is file-read only.

How to fix it

Upgrade Atlassian Jira Server and Jira Data Center to a fixed version: 8.5.14 or later for the 8.5 LTS line, 8.13.6 or later for the 8.13 line, and 8.16.1 or later for the 8.14/8.15/8.16 line. Prefer upgrading to a currently supported Jira release rather than only the minimum fixed version. If immediate upgrade is not possible, restrict access to Jira at the network layer, require VPN or trusted source ranges for administrative and user access, place Jira behind a WAF or reverse proxy rule that blocks requests for /WEB-INF/, /META-INF/, and path traversal sequences, and increase logging on web/proxy access. Mitigations should be considered temporary because malformed encodings and proxy normalization differences can bypass simple filters. Do not use the unrelated TensorFlow commit listed in the supplied package metadata as a fix for this Jira vulnerability.

How to confirm the fix worked

Confirm the running Jira version from the application administration UI, build information, package manager, container image, or Atlassian installation files and verify it is at or above the applicable fixed version. From a controlled test source, verify that unauthenticated requests for /WEB-INF/web.xml and encoded traversal variants are denied with 403 or 404 and do not return XML file contents. Review reverse proxy, WAF, and application server behavior to ensure URL normalization is consistent before requests reach Jira. Validate that WAF or proxy rules, if used as compensating controls, block both plain and encoded traversal attempts. Re-run authenticated and unauthenticated exposure checks after upgrade and after any reverse proxy changes.

Typical attack path

1. Discover an internet-facing or otherwise reachable Jira Server or Jira Data Center instance.
2. Fingerprint the Jira version or infer vulnerability from exposed behavior and release range.
3. Send unauthenticated HTTP GET or HEAD requests to /WEB-INF/web.xml using direct, relative-path, or URL-encoded traversal patterns.
4. Observe whether the server returns HTTP 200 responses or file-like content from protected application paths.
5. Extract application configuration details, servlet mappings, filter definitions, paths, or plugin information from disclosed files.
6. Use the disclosed information to support follow-on reconnaissance, targeted authentication attacks, or exploitation of additional Jira weaknesses.

How to detect it

Review HTTP access logs from Jira, reverse proxies, WAFs, load balancers, CDN logs, and application server logs such as Tomcat/Catalina logs. Focus on unauthenticated GET or HEAD requests containing /WEB-INF/web.xml, /WEB-INF/, /META-INF/, ../, or URL-encoded traversal patterns such as %2e%2e, %252e%252e, %2f, and %5c. Give highest priority to requests that returned HTTP 200, 206, or unusually large response sizes, especially from unfamiliar external IP addresses or scanners. Check for repeated requests with different encodings, mixed slash and backslash separators, double encoding, semicolon path parameters, or normalization bypass attempts. In Jira application logs, look for errors, warnings, or stack traces around requests to protected WEB-INF resources. If exploitation appears successful, investigate follow-on activity from the same source IPs or nearby time window: login attempts, administrative logins, plugin installation, changes to application links, user creation, project permission changes, and requests for other Jira vulnerability paths. Preserve raw logs because normalized proxy logs may hide the original traversal encoding.

• /WEB-INF/web.xml
• /WEB-INF/
• WEB-INF/web.xml
• /META-INF/
• ../WEB-INF/web.xml
• ..%2fWEB-INF%2fweb.xml
• %2e%2e%2fWEB-INF%2fweb.xml
• %252e%252e%252fWEB-INF%252fweb.xml
• ..%5cWEB-INF%5cweb.xml
• %2e%2e%5cWEB-INF%5cweb.xml
• GET /WEB-INF/web.xml
• HEAD /WEB-INF/web.xml
• GET /%2e%2e%2fWEB-INF%2fweb.xml
• GET /..%2fWEB-INF%2fweb.xml
• WEB-INF%2fweb.xml
• WEB-INF%5cweb.xml
• catalina.out
• localhost_access_log
• access_log

What your security team should do

• Immediately inventory all Jira Server and Jira Data Center deployments, including internet-facing, partner-accessible, VPN-accessible, and disaster-recovery instances.
• Prioritize emergency upgrade or isolation for any vulnerable Jira instance reachable from the internet because the issue is in CISA KEV, is exploited in the wild, and has extremely high EPSS likelihood.
• Upgrade to 8.5.14, 8.13.6, 8.16.1, or a newer supported Jira release according to the deployed branch.
• Search historical web, proxy, WAF, load balancer, and application server logs for access to /WEB-INF/web.xml, /WEB-INF/, traversal strings, and encoded traversal variants.
• Treat confirmed successful file reads as a security incident: preserve logs, identify source IPs, enumerate files requested, and investigate follow-on authentication or exploitation activity.
• Add WAF or reverse proxy detections and blocks for protected Java web application paths such as /WEB-INF/ and /META-INF/ and for repeated encoded path traversal attempts.
• Review Jira exposure posture and restrict direct access where business requirements allow.
• Correlate suspicious file-read activity with subsequent failed logins, successful admin logins, plugin uploads, configuration changes, or requests to other known Jira exploit paths.