An Atlassian Confluence vulnerability is being exploited in the wild | Hacker News Reader

An Atlassian Confluence vulnerability is being exploited in the wild

techradar.com

62 pointsRadixDLT26 comments

From: https://nvd.nist.gov/vuln/detail/CVE-2023-22515

> Atlassian has been made aware of an issue reported by a handful of customers where external attackers may have exploited a previously unknown vulnerability in publicly accessible Confluence Data Center and Server instances to create unauthorized Confluence administrator accounts and access Confluence instances. Atlassian Cloud sites are not affected by this vulnerability. If your Confluence site is accessed via an atlassian.net domain, it is hosted by Atlassian and is not vulnerable to this issue.

This is a great time for Atlassian to be revoking self-hosting for the masses.

The cloud is someone else's computer, not secured how you might, and not out of the way.

Downvoting is fine, comments are even more welcome.

Could be a move by atlasian to get everybody on cloud.

I don’t think the Atlassian cloud is very good or fast. Self hosted instances have always been much faster

Do you work for a cloud provider? Self hosting is superior

I do not work for a cloud at all and prefer self hosting myself.

I guess I could see my comment being taken otherwise.

What is atlassian doing? Last year it was the RCE CVE-2022-26134. And now this. Getting published by CISA every year isn't a good look.

We once had a meeting with our ex-CTO. The question was how do you envision the technical future of Atlassian. The most popular tag was "fire", referring to the "Five-alarm fire" program they introduced to fight a series or emerging outages. This program was over at the time when we had this poll. Seems like everyone in the org saw that in 2021. Later it was confirmed multiple times, with one of the services down for almost a week for some clients, and TBH with other outages. And in 2021 the CTO just ignored the most popular "fire" answer saying something "while we're getting votes coming in, let's talk about..."

They replaced CTO, but it didn't help. At this point I'm pretty confident it's about founders who cannot keep it under control. So you know, this org is 70-80% KTLO.

IDK, I've used Jira and Confluence at almost every place I've worked the past 20 years, love those tools.

There is pretty substantial number of folks who hate Jira, TBH. But you're the reason is their stock is still flat, and the entire company worth something.

> reason is their stock is still flat

It's up 20% in the last 6 months https://www.google.com/finance/quote/TEAM:NASDAQ?sa=X&ved=2a...

Even if it's flat you can find a time frame when it's up. The reality is it's not the best stock by any means, and it will never will be. Why? Because it's Atlassian. No-innovation, KTLO-kind-of-company.

They probably don't hate Jira, but specific implementations of it, which can easily turn to shit with bad management because the tool is flexible enough to allow it.

> At this point I'm pretty confident it's about founders who cannot keep it under control.

They seem to be purely on the growth-by-acquisition trend, hell almost all of their products are acquisitions that have been more-or-less shoddily "integrated"... just a week ago they bought Loom for a billion $ - money that would have been better invested in bringing their code and service quality up to speed.

Atlassian is enshittification-as-a-service, just that this time it isn't the general population being squeezed but large corporations.

I don't remember if it was this one, but Confluence had a pre-login vulnerability a while back that was actively exploited on DI2E, which had been the DoD's largest unclassified system, used as a collaboration and platform layer for all defense and intelligence projects that didn't have their own isolated environment, ironically only a couple months before it was scheduled to sunset anyway. They had to lock and bring down their entire data center for months before they could be sure everything was clean, and all defense projects that didn't have their planning data backed up somewhere else just lost it that entire time. And we'll never know how many programs that were considered sensitive but not enough to be classified had planning data compromised or by whom.

The only reason Atlassian hasn't totally lost the entire US government at this point is inertia and the remaining influence of however many thousands of agile consultants and project managers out there just love Jira and don't want anyone to move their cheese.

I'm gonna assume that Confluence cloud is unaffected since it isn't mentioned.

Atlassian mentions in their original advisory[0] that Cloud is not vulnerable. But Atlassian usually just... leaves it at that. No clarification on if Cloud was ever vulnerable in the past or whether there was any evidence of exploitation attempts on Cloud customers. Something I wish they would provide more details on as my company is also an Atlassian customer.

[0]: https://confluence.atlassian.com/security/cve-2023-22515-pri...

In all of these advisories there has never once been a mention of cloud being vulnerable. I think it's safe to assume cloud runs a similar, if not identical, codebase, and that these issues are simply patched there first before vulnerability announcements are published. But that's the type of thing no company is ever going to be willing to say in public.

Someone in here claimed recently that the Cloud products were forked many years ago, which sounds believable - there's tons of little stuff that only works on either Cloud or on-prem.

They never seem to publish security vulnerabilities related to their cloud except in aggregate so who knows.

Are there bugs the FBI tells you not to patch?

No(I think), but I imagine they don't comment at all about most bugs.

Does confluence still require you to manually increase jvm memory so it won't crash?

You mean confluence won't run in your jvm with a default 128mb heap? Then I guess so, I'm not aware of any way a java application can automatically increase the heap size of the vm it's running in.

Its pretty common for Java applications to ship with a wrapper that spawns the JVM with whatever parameters it needs.

Reply on news.ycombinator.com