Hey Jira Guys and Gals, How have you been? Me, I’ve been busy. If you haven’t seen, I’ve partnered with Alex at Apetech Tech Tutorials to start a podcast/weekly video called The Jira Life. We’ve been hitting it hard since the start of the year and have seen good growth. We recently hit 1000 subscribers. So, if you have yet to see it, please check it out and subscribe! While I’ve missed working on the blog, I’ve needed a bit of a change of pace to recharge my creative batteries. But, I’m back!

Unfortunately, what brings me back here could be more fun. Yesterday, Atlassian dropped their monthly Security Bulletin, and this one is generating some buzz. Before I could even read it, I had a couple of tags from people talking about it. 

Starting in February, Atlassian publishes a monthly bulletin to share product vulnerabilities rather than just releasing them whenever needed. If a vulnerability is especially bad, it will be released ad hoc, but most will appear here.  

So, what was on this month’s Bulletin that had everyone talking? This month’s entries for Bamboo, Confluence, Jira Software, and Jira Service Management on both Server and DC flavors. These are based on a series of CVEs from downstream sources. So, let’s dig into this to see what’s going on, how bad it is, and what you need to do to fix this issue!

So, how bad is it?

Overall, these are relatively bad. The Bulletin’s lowest severity score is 7.5 out of 10. However, people are focusing on the wrong issue.

What causes most people to have panic attacks are the CVEs for Confluence, JSM, and JSW. These allow someone to initiate a Denial of Service attack against your system, which, don’t get me wrong, is bad but not the end of the world. This vulnerability is much better than allowing attackers to take over your system or access information they shouldn’t. This vulnerability causes downtime, which sucks, but it will get better. 

That being said, I’ve seen a few posts focusing on these three specifically. Don’t get me wrong, no one likes downtime, and if your Atlassian system is attacked, you will have a bad day, but things can be much worse.

The vulnerability on this list that makes me worried is the Server-Side Request Forgery vulnerability for Bamboo. This vulnerability could allow an attacker to cause Bamboo to perform all sorts of unauthorized actions, potentially leaking sensitive information from your Build system. This vulnerability is also rated higher than the Denial of Service vulnerability for a reason.    

What do I do to fix it?

So, you are running one of the products on an affected version; what can you do about it? If you are on Data Center, you need to upgrade to one of the fixed versions as soon as possible. They are:

• Bamboo:
  • 9.6.1 (LTS)
  • 9.5.3 (DC Only)
  • 9.2.13 (LTS, Sever Version Available)
• Confluence:
  • 8.9.0 (DC Only)
  • 8.8.0 (DC Only)
  • 8.7.1 or 8.7.2 (DC Only)
  • 8.5.7 or 8.5.8 (LTS, Server Version Available)
  • 7.19.20 or 7.19.21 (LTS, Server Version Available)
• JSW:
  •  9.15.0 (DC Only) 
  • 9.12.6 to 9.12.7 (LTS, Server Version Available)
  •  9.4.18 to 9.4.20 (LTS, Server Version Available)  
• JSM:
  • 5.15.0, 5.14.0, 5.14.1 Data Center Only
  • 5.12.6 (LTS, Server Version Available)
  • 5.4.19 (LTS, Server Version Available)

Don’t get me wrong—I get it. Planning an upgrade—especially if you are upgrading a feature or major version—is no trivial task. And doing so in a hurry is even more worrying. But the longer you sit on these versions, the more an attacker can exploit your system, especially if it sits on the open internet.  

The server-sized Elephant in the room.

So, I don’t think it’s a coincidence that Atlassian went to this monthly format just as Server saw its end of life around February. The only people offered an extension of their Jira Server license were those preparing to migrate to Cloud, so for most people, that’s it. You need an active maintenance agreement to upgrade Jira Server; without that, your system will be vulnerable to these issues. And the maximum extension given to the few that got them for Jira Server was one year, so even those people are on a ticking clock.   

The unfortunate news is that the information needed for a CVE is enough to tell hackers and malware programmers exactly how to exploit the vulnerability. As these security bulletins pile up, your systems are becoming increasingly insecure. Yes, you can still run Jira or Confluence Server, but at what point do you assume doing so is an open invitation? This situation was my main concern with some of the reactions I saw to the EoL, and I’ve seen nothing since that makes it sit any better with me.

That being said, this is our reality now, and the best advice I can give to people still running Atlassian Server products is to lock up your Jira instance as much as possible and keep an eye out for weird behavior.  

Atlassian Cloud Never has security issues.

Another point I want to make here is what’s missing. In these security bulletins, Atlassian never includes any information about Cloud. This exclusion is because by the time these vulnerabilities are released, the vulnerability has already been patched for you in Atlassian Cloud.

 I’ve made this point before, and I’ll keep saying the inconvenient truth. Jira Cloud is not more secure than running your own Atlassian system. It’s still fully dependent on someone finding a vulnerability, reporting it properly to Atlassian, and Atlassian fixing it. I worry that Atlassian purposefully leaving Jira Cloud off these reports will give Atlassian Admins on Cloud products a false sense of security. If an attacker has a vulnerability that was never reported to Atlassian, your Cloud instance will be just as vulnerable as any self-hosted system.

The one point I will give Jira Cloud is that, unlike self-hosted options, no intervention is required on your part to resolve a vulnerability once it is known. Atlassian will take action to automatically apply the fix to your instances behind the scenes to keep you safe. Compare that to a Self-hosted instance where someone has to figure out what version to upgrade to, test that upgrade, find a change window, push the upgrade through any change management process, and upgrade the production system. Staying safe on Atlassian Cloud products is easier, but not a bulletproof shield. 

So, what do you think?

Are you still running a Server instance? How are you keeping up with upgrades if you are running a Data Center instance? Or have you switched over fully to Atlassian Cloud? I’d like to hear from you!

Team ’24 is coming up fast. I have not one, not two, but three separate appearances in and around Team ’24, as well as four planned “The Jira Life” episodes we will air. If you are going, please let me know, and if you want to meet up, keep an eye on my LinkedIn profile, as that’s where I’ll be posting live updates.

But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”