Jira & Confluence Attacks Have Started – What Changed Overnight?

Yesterday we covered a serious security problem affecting Jira, Confluence and other Atlassian systems, and at the time there was no evidence of real-world attacks. That has now changed. Security researchers are seeing exploitation attempts, and they started within hours of technical details becoming public.

There is another story today that’s just as important. Thousands of exposed AI servers have already been compromised, and some are now being used to attack other systems. I’m Dustin Gray, I’ve been building production software for 25 years, and each day I look at the security topics that matter. Here are today’s five stories.

Let’s start with Atlassian, because this story changed overnight. Yesterday we knew about a serious vulnerability affecting self-hosted Jira, Confluence, Bitbucket and other Atlassian products. It can allow someone who isn’t logged in to retrieve specific files from the application.

There is an important condition: the attacker needs to know which file they’re looking for. But now exploitation attempts are being observed, and researchers say they started appearing within hours of technical details becoming public.

Here’s why that matters. Some application files can contain credentials, and those credentials may connect one trusted system to another. Under certain configurations, researchers have demonstrated that this could lead to administrator access.

That does not mean every Jira server can instantly be taken over, because configuration matters. But yesterday this was a vulnerability, and today people are trying to exploit it. So if your organisation runs its own Jira, Confluence, Bitbucket or other Atlassian systems, confirm that they’re patched.

If they were exposed before they were patched, review the logs and look for unusual file requests. Check whether credentials may have been exposed and review administrator access. Patching closes the vulnerability, but it does not tell you whether somebody already used it.

Next up, this one matters if your organisation is experimenting with AI. Researchers at Black Lotus Labs have uncovered a malware campaign called PoeLLM, and this is not theoretical. More than 3,400 servers have been compromised, and many were running internet-facing services, including LiteLLM, Ollama and Gotenberg.

Here’s where this gets interesting. The attackers aren’t just using those servers themselves. Some compromised machines are being turned into scanners and used to find the next victim.

Imagine someone puts an AI service online for a quick test. It works, and nobody thinks much more about it. But that server might have access to API keys, development tools, internal systems or other applications, and that changes the blast radius.

Researchers reported victims in the United States and Western Europe. I have not found any authoritative confirmation of Australian victims yet. So ask whether your organisation has AI services directly exposed to the internet, and if they don’t need public access, remove it.

Check the versions, review network activity and compare historical connections with the indicators published by the researchers. If a vulnerable system was publicly exposed, treat it as an investigation, not simply an update.

Next up, Cisco, and this is not about Wi-Fi or somebody’s laptop. Cisco has released a critical security advisory for Cisco License On-Prem. That’s a system used by some organisations to manage Cisco licensing inside their own environment, and the vulnerabilities affect its web interface and APIs.

Cisco says the flaws could allow unauthorised access, sensitive information exposure, system disruption or increased privileges. Some of those problems include missing access controls, command injection and database injection. But you don’t need to understand those terms.

The important point is much simpler. This is a trusted management application, and management applications often have access to other important systems. So the risk isn’t just what’s inside the application; the real question is what that application can reach next.

If your organisation uses Cisco License On-Prem, ask IT to check the version, compare it with Cisco’s advisory and install the fixed release. Then check whether the management interface or APIs are exposed to the public internet. If they do not need public access, restrict them and review administrative activity for anything that does not belong there.

Next up, WordPress Events Manager has released version 7.4.7 to fix a serious database vulnerability. But the interesting part is how this happened. The vulnerable code was not new; it had already been inside the plugin, but through the normal website it was not reachable in this dangerous way.

Then the developers added an API. That API sent information into the old code differently, and suddenly an old assumption was no longer safe. An attacker does need a WordPress account, but even a basic subscriber account is enough.

Affected versions are 7.3 through to 7.4.6, and I have not found evidence of confirmed active exploitation. So if your website uses Events Manager, check the version and move to 7.4.7. If you use Events Manager Pro, check the developer’s Pro update guidance too.

Then review who has user accounts on the website, because this issue does not require administrator access. And if your team is adding APIs to older applications, test the old code those APIs expose, not just the new endpoint.

And finally, Express Gateway sits in front of APIs and helps decide who is allowed through. A newly discovered vulnerability affects its OAuth refresh token process through version 1.16.11.

Here’s the simple version. A refresh token lets somebody get a new access pass without logging in again. But the vulnerable system does not properly verify all the information that proves who that token belongs to.

An attacker still needs valid client credentials, and they also need part of another user’s refresh token information. So this is not an attacker instantly becoming an administrator. But under those conditions, they could potentially receive another user’s access token, and that could allow them to impersonate that user against protected APIs.

I found no evidence of active exploitation. So if your applications use Express Gateway, check the version and determine whether OAuth refresh tokens are enabled. If you’re running 1.16.11 or earlier, review the remediation guidance.

Then check authentication logs for unusual refresh activity. Look especially for one client requesting access for multiple users.

There’s one security principle running through almost every story today: exposure changes risk. A file inside Jira becomes reachable from outside. An AI service meant for testing ends up exposed to the internet.

A trusted Cisco system accepts requests it should not trust. A WordPress API makes old code reachable in a new way. And an authentication system checks part of a request but not the whole relationship.

None of these systems necessarily looked broken. They worked, and that’s the distinction. “It works” is a functional test, while “it’s secure and production ready” is a totally different question.

So today, ask this: what have we made reachable that was never designed to be trusted from there?