mareks.birkenfelds, 72ecabbe32dc this improvement was introduced in Jira 8.8.0 and is present in all newer versions as well.

Hi, please confirm that the vulnerability is solved in the latest Jira version 8.13.x, without an upgrade to 8.8 upfront. 

Could you please confirm, that this issue is resolved in latest Long Term Support release : 8.13.4 ?

Thanks

First, hey Kimberly.  

Re Duane's comment, we share the frustration with this not being backported to Jira 8.5.9, a version that is ostensibly LTS. But has the severity rating changed since November? It has for some CVEs.

Has somebody applied this patch already? If so, how is it going? We're going to apply the patch to a 7.13 server version these days and will have to include this patch during an upgrade (to 8.5) as well quote soon. According to Atlassian

"some 3rd party and your own internal apps may stop working or cause problems with other Jira functionality. You can use this workaround at your own discretion."

In fact we have done so upon the test server tonight. Let's see how it works. At least Jira is up & running again. Nonetheless, it's quite interesting annoying to be left on our own with this while actually running a LTS version. Now we would have to find out if any 3rd party plugin works properly? Great.

If I understand this correctly there's no risk when upgrading to 8.8 (or later). How can this fix be guaranteed to work properly then? And where's the difference to 8.5 in terms of velocity?

+1 for the above.  You might be fortunate enough to consider it a "security improvement" but I can assure you, my organization does not, with that NIST/NVD score.

Thanks for the update Pawel.  Given your comment of:

We treat this issue as a security improvement, not a security vulnerability that can be exploited.

Should a CVE should have been issued at ALL for this?  Let alone one that wound up with an accepted vulnerability score by NIST/NVD of 9.8 out of 10.0 (aka "critical").   All of the common vulnerability scanners - Qualys, Tenable, etc - picked up this CVE and added it to their tests.  Directly because of this, I have already had to patch to a non-LTS release in order to keep the compliance monster in my heavily regulated environment content and happy.

More care/caution by Atlassian when (a) deciding to flag something as a vulnerability / CVE and (b) accurately describing the actual risk in a way that leads to the correct CVSS score would be GREATLY appreciated.  We don't need things under-reported, nor do they need to be over-reported.

I nagged the NIST/NVD folks for their take on the discrepancy on the score – basically they're looking for "more words" from Atlassian in order to be able to more carefully score the vuln.  I'm no longer impacted as we went ahead and upgraded to 8.12, but adding this just for posterity

Thank you for bringing this to our attention. NVD analysts use the reference information provided with the CVE and any publicly available information at the time of analysis to associate Reference Tags, CVSS v2.0, CVSS v3.1, CWE, and CPE Applicability statements. If any information is lacking, unclear, or conflicts between sources, the NVD policy is to represent the worst-case scenario. The NVD takes this conservative approach to avoid underreporting the possible severity of a given vulnerability.

 

We consider the CVSS vector strings provided by an organization along with the advisories as supplemental data. However, NVD analysis uses the text-based advisory information to determine the most appropriate CVSS metric values and if the text-based information was vague or conflicted with the CVSS vector string provided by the organization we would most likely not align.  

 

We kindly request you to provide publicly available information to justify the score provided by the vendor that would clearly align with the CVSS 3.1 specifications (https://www.first.org/cvss/v3.1/specification-document). Once this has been added publicly, we would be glad to review this information and make the appropriate changes. 

I think Atlassian should definitely give us more information on this and I was told by Jira support that Jira developers would be posting an update here "soon"

And, I agree that their risk assessment is rather suspicious, as the NIST/Mitre CVE, says, "The way in which velocity templates were used in Atlassian Jira Server and Data Center prior to version 8.8.0 allowed remote attackers to gain remote code execution if they were able to exploit a server side template injection vulnerability," yet Anton's assessment shows a local attack vector.  It is clearly remote and maybe that partially explains the score discrepancy.