An AI Agent Accessed Another Australian Government Website

If you’re responsible for a business website or application, there are five security stories you need to know about today. The first one is here in Australia, because another Australian government web application has been accessed by an AI agent. But this isn’t another story about AI hacking Medicare, and according to Cyber Security NSW, this may not actually be a hack at all.

I’m Dustin Gray and I’ve been building production software for 25 years. Every day I look at what’s happening across websites, applications and the infrastructure behind them. So let’s get into it.

First up, another Australian government web application has been accessed by an OpenAI agent. This time it belonged to the New South Wales National Parks and Wildlife Service. The incident actually happened back in June, but was only reported to the New South Wales Government on 1 October.

The agent accessed an application containing historical information about fires in New South Wales. Now, here’s where this gets interesting. Investigators have found no unauthorised access to personal information, and Cyber Security NSW is investigating this as something called AI misalignment.

In other words, this isn’t necessarily a story about an AI breaking through security. It may be a story about an AI discovering that an application allowed it to do something that nobody expected it to do. And that’s the part anyone building websites or applications needs to pay attention to.

For years, we’ve designed applications around how we expect humans to use them: click this button, fill out this form, follow this link. But an AI agent doesn’t have to use your interface. It can potentially interact directly with endpoints, APIs, parameters and application behaviour.

So today, look at your application without looking at the interface. What could an automated agent discover if it completely ignored the way you expected people to use it?

Next up: what happens when the security problem isn’t behind your login page, but is the login system itself? That’s the situation facing users of ZITADEL. ZITADEL provides authentication and identity management for web applications, and several serious vulnerabilities have just been disclosed.

One affects its hosted Login V1 interface. Under the vulnerable conditions, an unauthenticated attacker can potentially forge external identity information and create an account associated with somebody else’s identity.

But there’s another vulnerability that’s even more interesting. It affects Login V2. If an application uses email or SMS one-time passwords, an attacker who knows someone’s username may potentially be able to obtain those authentication codes from the application’s responses.

And now the consequence becomes obvious. If the application trusts ZITADEL to tell it who someone is, breaking that identity boundary can potentially mean account takeover, and that could include administrator accounts.

So this is a useful lesson for anybody building applications with AI. Adding authentication doesn’t automatically make your application secure. You’ve simply moved one of your most important security boundaries into another component.

So if you’re using ZITADEL, identify which login flow you’re running and check the version today. For Login V1, pay particular attention to versions below 3.4.14 and 4.16.2. For the separate Login V2 issue, the fix is in 4.17.1.

There’s currently no evidence I’ve found of active exploitation. But when the vulnerable component is deciding who gets through the front door, I wouldn’t wait around.

Next, here’s one for anybody building applications that let users upload documents, because a Word document doesn’t have to contain malware to cause you a problem. A new vulnerability has been disclosed in Mammoth.js, a JavaScript library used by applications to convert Word documents into HTML. This one demonstrates a security mistake that’s incredibly easy to make when you’re vibe coding.

Imagine asking AI to let users upload a Word document and convert it to HTML. Ten minutes later, it works. Job done, you’d think, except you’ve just created a new attack surface.

The vulnerability affects Mammoth from version 1.3.0 through to 1.12.2. An attacker can create a specially crafted Word document that causes extremely expensive processing when Mammoth tries to parse it. And here’s the consequence: because that processing can block the Node.js event loop, one malicious document could potentially make the application unavailable to everybody else.

That’s the bit people miss. An uploaded document isn’t just a file. It’s attacker-controlled input being handed to code that has to interpret it.

So if you’ve built a Node application that accepts Word documents, check your dependency tree today. If Mammoth is in there, move to version 1.12.3 or later. More broadly, don’t let untrusted document processing run without sensible resource and execution limits.

Now to WordPress. This next vulnerability requires an attacker to have an account, which sounds reassuring until you look at what the plugin is actually designed to do. The vulnerability is in Ultimate Member, and Ultimate Member is specifically designed to let people register and manage accounts on WordPress websites.

So on many affected websites, getting an account isn’t exactly difficult. The vulnerability affects versions through 2.13.1, and it can allow a lower-privileged user to cross an authorisation boundary and potentially gain privileges they shouldn’t have. That’s where an ordinary website account can become something much more serious.

And there’s another important lesson here. When you hear that a vulnerability requires authentication, don’t automatically assume the risk is low. Always ask: how difficult is it to become an authenticated user?

On a private corporate application, that might be difficult. On a public membership website, it could take 30 seconds.

So if you’re running Ultimate Member, check your version today and move beyond 2.13.1. But don’t stop there: review recently created accounts and look for unexpected privilege changes. Installing the fix can close the vulnerability, but it can’t tell you whether somebody already used it.

And finally this morning, another major WordPress plugin has a newly disclosed vulnerability. But before anybody starts posting that a million WordPress websites can suddenly be hacked, that’s not what this vulnerability means.

The plugin is WP Statistics and the issue affects versions through 14.16.14. It’s a reflected cross-site scripting vulnerability. An attacker doesn’t need a WordPress account, but they do need something else: they need the victim to interact with a specially crafted request.

That condition matters, because this isn’t somebody simply sending a request to your website and taking control. They need to convince somebody to interact with their malicious link.

But here’s why it’s still worth knowing about. If the person clicking that link is logged into WordPress as an administrator, attacker-controlled JavaScript could potentially execute in the context of that website. And suddenly who clicks the link becomes more important.

The fix is in version 14.16.15, so check that version today. And if you manage WordPress websites, be suspicious of unexpected links that supposedly take you to analytics reports or WordPress administration pages.

So that’s today’s Website & Application Security Briefing, and there’s a common thread running through these stories. The New South Wales incident is about assumptions around how someone will use your application. ZITADEL is about assumptions around who your application can trust.

Mammoth is about assumptions around the files people upload. Ultimate Member is about assumptions around what an authenticated user should be allowed to do. Security failures often happen at the boundary between what we expected someone to do and what the system actually allows them to do.

So don’t just test whether your website works today. Ask a different question: what happens when somebody deliberately uses it in a way you never intended? I’ll be back tomorrow with the next five stories that matter.