A few weeks ago, one of my final thoughts on “Atlassian, CVE 2022-26134, and You” was to say, “Honestly, I think this is far from the last CVE we’ll see from Atlassian.”
The hackers didn’t have to be in such a rush to prove me right. Yep, today’s post delay was to get past Atlassian’s embargo so I can talk about the newest Atlassian Vulnerability, CVE 2022-26135. Unlike the one a few weeks ago, I’m (relatively) healthy this week, so I get to cover it hot off the presses!
Benefits of the TAM Program
So, you might wonder, “How did Rodney know he should delay this post today?”
Atlassian only released the public notification about this vulnerability an hour before I published this article. So, how did I have this post ready to go so shortly after Atlassian?
This is where I’ll point to the TAM Program. These Technical Account Managers work with Jira Admins at companies to ensure they follow best practices and have the resources they need to succeed. I have worked with Atlassian’s TAMs several times before. I still consider many TAMs I’ve worked with before to be friends, and I know more than a few follow the Blog.
One benefit you get from being a part of the TAM program is an advanced notice about upcoming vulnerabilities. This notification lets you perform any mitigation steps and/or upgrades required before the issue becomes public knowledge, allowing you to stay one step ahead. Advanced notice isn’t always possible, especially with Zero-Day vulnerabilities, but it’s a nice perk. What I’m saying is if you need help to secure the budget for a TAM, and your company is security conscious, well, now you have your justification.
So let’s get on with this CVE
So CVE 2022-26135 is a Full-Read Server Side Request Forgery. With this, a hacker could use a specially crafted URL to access Data and Information they would otherwise not be privileged to. This kind of attack isn’t as bad as CVE 2022-26134, which was a Remote Code Execution, but it’s still not great.
I should note here that to use CVE 2022-26135, an attacker must start with an authenticated session. HOWEVER, the session doesn’t have to be privileged and can be a session someone just signed up for (if you have user sign-up enabled). So it lets hackers bypass any permissions you have in place and access any data stored on your Jira instance. Considering what some of you leave in Jira tickets, that should be scary enough to motivate you to fix this.
What Versions does it affect?
So this affects both Jira Server and Data Center. In short, this affects:
Jira Core and Software:
- versions after 8.0 and before 8.13.22
- 8.14.x
- 8.15.x
- 8.16.x
- 8.17.x
- 8.18.x
- 8.19.x
- 8.20.x before 8.20.10
- 8.21.x
- 8.22.x before 8.22.4
This also impacts Jira Service Management versions:
- Versions after 4.0 and before 4.13.22
- 4.14.x
- 4.15.x
- 4.16.x
- 4.17.x
- 4.18.x
- 4.19.x
- 4.20.x before 4.20.10
- 4.21.x
- 4.22.x before 4.22.4
I should note that Jira versions 8.13, 8.20, and 8.22 (4.13, 4.20, and 4.22 for JSM) are LTS releases that are still actively supported, so that they will be getting the bug fix. If you are on any other version of Jira, I recommend moving to the closest LTS release as soon as possible.
The fix versions for this vulnerability are:
Jira Core and Software:
- 8.13.x >= 8.13.22
- 8.20.x >= 8.20.10
- 8.22.x >= 8.22.4
- 9.0.0
Jira Service Management:
- 4.13.x >= 4.13.22
- 4.20.x >= 4.20.10
- 4.22.x >= 4.22.4
- 5.0.0
Other Mitigations
While I still thoroughly recommend you upgrade Jira where possible to resolve this, I fully admit that isn’t always possible in a timely manner. As such, Atlassian has provided an alternate Mitigation for the vulnerability. This can be used as a band-aid until such a time as you can upgrade.
The key to this mitigation is understanding that this affects a system-installed App within Jira, specifically the “Mobile Plugin for Jira” App. This App is what provides you with the mobile interface when you access your Jira instance from a mobile device. Don’t get me wrong – I find this interface unbearable, but it’s there, and now it’s a problem.
So, as a mitigation, you can upgrade it within your Universal App Management tool within Jira. You will find it in the User Installed or System Apps on the dropdown on “Manage Apps.”
Go to the Atlassian Marketplace page for the Mobile Plugin for Jira, and download the following version based on your Jira instance.
- For Jira 8.13.x or JSM 4.13.x: download Version 3.1.5
- For Jira 8.20.x and 8.22.x, or JSM Version 4.20.x or 4.22.x: download version 3.2.15
From there, you will go to your Manage Apps page, click “Upload App,” and upload the version you downloaded from the Marketplace. After the App upgrade, I should note that if the App was shown as a system app, it would now be shown as a User-Installed App.
Let’s talk about Atlassian Cloud for a moment.
I saw a tweet the other day implying that Atlassian Cloud doesn’t suffer from as many vulnerabilities as Jira Server or Data Center does. And well…I don’t think that’s true.
There are vulnerabilities found in Jira Cloud. Although Atlassian hasn’t shared the numbers, I suspect they find Vulnerabilities in Atlassian Cloud at about the same frequency as their Server and DC products. So, why do we hear about so many more problems with Server and DC? Well, think about who has to do the fix.
With Jira Cloud, Atlassian is a first-party maintainer of those instances. This arrangement means they can quietly handle any problems found in Jira Cloud behind the scenes. However, you are the maintainer for Jira Server and DC instances. This difference means that to fix these instances, Atlassian has to notify people about problems and how to fix them. This fact is why the Server and DC vulnerability notices feel so much more apparent.
Now am I saying one is better than the other? NO! I’m just trying to get you to understand that every Software system will have issues. It’s just a part of the game. As always – I recommend the right tool for the job. There are cases where I’d recommend Jira Cloud over Server/DC and visa-versa.
Look – the CVEs have been coming out often this year. But I think this is just the nature of Atlassian being as big as it is now. When you have a tool with a wide adoption, it becomes an attractive target for Hackers. They know they will likely come across a Jira or Confluence instance in the wild, so having methods to break in is well worth the effort.
Even before this, I still recommended upgrading your instances about every six months. Doing so allowed you to resolve bugs that required an upgrade and gave your users access to new features. That advice hasn’t faded; if anything, it’s just gaining new importance.
Something else that came across my Newsfeed
I came across an …interesting site that someone shared on LinkedIn this past week. Unfortunately, I couldn’t find who made the original post (it was very odd), but it did catch my eye. So I figured I’d share it with you.
Now – this harkens back to one of my early successful posts: “Jira Sucks, but it doesn’t have to“. I have no doubt people (effing) hate Jira. If for nothing else, it’s a work software, and people would rather not be reminded of work. BUT, I still say people who hate Jira probably have never seen it correctly done. Jira has its problems, but so does every other work management software.
I’ve also said it before, and I’ll say it once more: if you want to understand your users’ problems with Jira – use it yourself. My team does – for both our project work and our queue management. Jira is infinitely configurable, but that only means there are also an infinite number of ways to do it wrong. So the only way to see how you’re doing is to get messy and get involved.
That said, I still feel it’s crucial to read criticisms like this and not write them off. These people may be anonymous, but they are being absolutely sincere. I cannot say their problem is with their work culture as a whole, their particular Jira instance, or Jira as a platform without knowing more. Either way, you can’t improve the situation if you never listen to the naysayers.
One theme I did spot in reading these is most of the groups these people are a part of are trying to use Jira as a wholesale replacement for human interaction. Jira is a tool to facilitate these interactions, but it was never meant to replace them outright. Anyways, read the site yourself, and come to your own conclusions.
As for me? Well, a new “Jira Sucks” article might be on the horizon.
Final Thoughts
As always, you can find my social media links on my Linktree. Please comment and like the posts wherever you are on Social media, and share them with your colleagues. This is the best way to help me out!
You can also subscribe below to the Blog. Doing so will tell the Blog to send you an email with any new articles I publish. I still think it’s the fastest and most reliable way to be notified of new things from the Blog.
But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”
The Jira Guy 