Vulnerability record · CVE-2020-36239 · published 29 July 2021
CVE-2020-36239: Atlassian Jira Data Center Ehcache RMI service missing authentication RCE
Atlassian · Jira Data Center
Jira Data Center, Jira Core Data Center, Jira Software Data Center and Jira Service Management Data Center exposed an Ehcache RMI network service on port 40001 (and potentially 40011) without authentication. An attacker able to reach that port can deserialize untrusted data and execute arbitrary code in the Jira process. Fixed versions require a shared secret to access the Ehcache service.
Description
Jira Data Center, Jira Core Data Center, Jira Software Data Center from version 6.3.0 before 8.5.16, from 8.6.0 before 8.13.8, from 8.14.0 before 8.17.0 and Jira Service Management Data Center from version 2.0.2 before 4.5.16, from version 4.6.0 before 4.13.8, and from version 4.14.0 before 4.17.0 exposed a Ehcache RMI network service which attackers, who can connect to the service, on port 40001 and potentially 40011[0][1], could execute arbitrary code of their choice in Jira through deserialization due to a missing authentication vulnerability. While Atlassian strongly suggests restricting access to the Ehcache ports to only Data Center instances, fixed versions of Jira will now require a shared secret in order to allow access to the Ehcache service. [0] In Jira Data Center, Jira Core Data Center, and Jira Software Data Center versions prior to 7.13.1, the Ehcache object port can be randomly allocated. [1] In Jira Service Management Data Center versions prior to 3.16.1, the Ehcache object port can be randomly allocated.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Automated analysis
critical priorityCVSS 9.8 with no authentication or user interaction required and a high EPSS score make this a top-priority remote code execution exposure for internet- or network-reachable Jira Data Center instances.
What it is
Jira Data Center, Jira Core Data Center, Jira Software Data Center and Jira Service Management Data Center exposed an Ehcache RMI network service on port 40001 (and potentially 40011) without authentication. An attacker able to reach that port can deserialize untrusted data and execute arbitrary code in the Jira process. Fixed versions require a shared secret to access the Ehcache service.
Impact
An unauthenticated network attacker gains arbitrary code execution in the Jira server process, which typically runs with the application's privileges and can lead to full compromise of the instance and its data.
Attack surface
Reached over the network via the exposed Ehcache RMI ports 40001 and potentially 40011; the CVSS vector shows no privileges or user interaction required. In some older versions the Ehcache object port is randomly allocated, so the exact port may vary.
Exploitation
Not listed in CISA KEV and no ransomware association is documented, but EPSS is high at roughly 0.50 (98.8th percentile), indicating substantial predicted exploitation activity; references are vendor advisories and patch links only.
What to do
- Upgrade to a fixed Jira/Jira Service Management Data Center release (8.5.16, 8.13.8, 8.17.0 or later for Jira; 4.5.16, 4.13.8, 4.17.0 or later for Jira Service Management) so the Ehcache service requires a shared secret.
- Restrict network access to the Ehcache ports (40001 and 40011, or the randomly allocated object port) to only trusted Data Center cluster nodes.
- Block the Ehcache ports at the perimeter and between network segments so they are not reachable from untrusted networks.
- If immediate patching is not possible, isolate affected instances and monitor for unexpected connections to the Ehcache ports.
Detection
- Monitor network traffic and firewall logs for inbound connections to TCP 40001 and 40011 from hosts outside the Jira cluster.
- Alert on unexpected processes or child processes spawned by the Jira Java process.
- Review Jira and host logs for deserialization errors or unusual RMI/Ehcache activity around the service ports.
This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.
Affected products
3 vulnerable configurations from NVD's CPE data, grouped by vendor and product.
References
| Link | Tags |
|---|---|
| https://confluence.atlassian.com/adminjiraserver/jira-data-center-and-jira-service-management-data-center-security-advis | PatchVendor Advisory |
| https://jira.atlassian.com/browse/JRASERVER-72566 | Issue TrackingVendor Advisory |
| https://jira.atlassian.com/browse/JSDSERVER-8454 | Issue TrackingVendor Advisory |
| https://confluence.atlassian.com/adminjiraserver/jira-data-center-and-jira-service-management-data-center-security-advis | PatchVendor Advisory |
| https://jira.atlassian.com/browse/JRASERVER-72566 | Issue TrackingVendor Advisory |
| https://jira.atlassian.com/browse/JSDSERVER-8454 | Issue TrackingVendor Advisory |
Track CVE-2020-36239 inside VULONE
Watch it alongside the ransomware crews, C2 infrastructure and forum chatter that reference it, query it through the API and pull it into your SIEM over TAXII.
Related vulnerabilities
Same products first, then exploited flaws of the same weakness class.
Source: NIST National Vulnerability Database (record CVE-2020-36239), CISA KEV, FIRST EPSS (scores of 2026-09-27). This page is refreshed as NVD updates the record.