Citrix NetScaler Is Being Exploited – Plus 7 Next.js Fixes

Australian organisations have now confirmed exploitation of critical Citrix vulnerabilities. That means this is no longer a theoretical overseas threat. We also have seven security fixes for Next.js, a critical vulnerability affecting React applications built with TanStack Start, malicious npm packages that remained undetected for more than a year, and a WordPress theme vulnerability that can potentially let an anonymous attacker upload PHP directly to the server.

If people inside your organisation are now building websites and applications with AI, these stories matter. AI can make the software incredibly fast, but it doesn’t automatically manage your dependencies, your infrastructure, your access controls, or what eventually reaches production. I’ve spent 25 years building production software, so let’s look at what happened, what it could mean for your business, and what you need to check today.

The Australian Signals Directorate has updated its warning about serious vulnerabilities affecting Citrix NetScaler, and Australian organisations have now reported confirmed exploitation. One of the vulnerabilities can potentially allow an attacker to execute code remotely without needing an account. According to the ASD, affected organisations need to investigate activity going back to at least the 4th of September.

That date matters because simply installing the patch today doesn’t tell you whether somebody got in three weeks ago. For a business, Citrix infrastructure can sit in front of some extremely important systems: remote access, internal applications, corporate networks, and sometimes systems containing customer or employee information. If that infrastructure is compromised, the attacker may be able to reach considerably more than one website.

So if your organisation runs NetScaler ADC or NetScaler Gateway, this isn’t just an update job. Patch the affected appliances, then investigate them. Check the indicators of compromise published by Citrix and ASD, review logs going back to at least the beginning of September, and determine what systems those appliances were allowed to access.

There’s also an important lesson here for website teams. You can build a perfectly secure application and still lose control of it through infrastructure sitting in front of the application. Application security doesn’t stop at the source code.

Next up is Next.js, and this one is particularly relevant to organisations using AI coding tools. Next.js has released versions 16.3.8 and 15.5.27, fixing seven security vulnerabilities. One is rated high, five are medium, and one is low, while two additional vulnerabilities, including one critical issue, are still waiting on upstream fixes.

One of the problems fixed today involves Next.js image optimisation. Under certain configurations, an attacker-controlled image URL can potentially make the Next.js server connect to internal network addresses. That’s known as a server-side request forgery, but the business risk is easier to understand than the name.

Imagine your public website being used as a bridge to reach something that isn’t supposed to be public. That could be an internal service, a development system, a cloud metadata endpoint, or another application sitting behind your firewall.

There are also fixes involving caching, and one issue could allow draft mode content to leak into ordinary responses. That potentially matters if draft mode contains information that was never intended to be shown publicly.

There is a vulnerability affecting the development MCP endpoint, and that can expose development information such as source snippets, routes, project paths and logs. That endpoint is not part of normal production deployments. But it matters because development environments are increasingly being connected to AI coding tools.

So here’s the action. Find every Next.js application your organisation operates, including prototypes, internal tools, preview deployments, old branches, and AI-generated experiments somebody pushed online six months ago. Check the actual deployed version, update the supported branch, rebuild the application and redeploy it, because changing a dependency on somebody’s laptop does not patch what’s running in production.

Next is TanStack Start, and this one is worth paying attention to if your teams are building modern React applications. A critical vulnerability has been disclosed in TanStack Start, and the attacker does not need an account. They can create a specially crafted link, and if somebody opens that link, the vulnerable application can return attacker-controlled HTML from its own trusted domain.

That means malicious JavaScript can potentially execute as though it came from your application, and that changes the business risk considerably. Your customers trust your domain, your employees trust your internal application, and their browsers trust the session that they already have open. So malicious code running inside that trusted environment could potentially interact with information or functionality available to that user.

The affected React packages need to be updated to the fixed release. But there’s another part of this story that’s particularly relevant to vibe coding. You may already have fixed production while an old preview deployment is still online.

Someone created a branch, AI generated the application, the platform automatically published a preview URL, and the project moved on. Nobody remembered that the public copy still existed. So don’t just check your main website; check development deployments, preview deployments, staging environments and abandoned experiments.

AI makes it very easy to create another application, but it also means organisations are accumulating applications they don’t know they still have.

Now, let’s talk about the software supply chain. Researchers have identified a malicious npm campaign involving at least nine packages. The packages were capable of installing remote access malware, stealing credentials and maintaining access to Windows systems.

One malicious package reportedly went without a security advisory for around 14 months. That’s the part I’d pay attention to, because the package installed successfully, the application could still work, and the build could still pass. The developer might have absolutely no indication that anything was wrong.

This becomes particularly important when people are vibe coding. The AI says, “Install this package”, the developer runs the command, the feature works, and everybody moves on. But npm doesn’t guarantee that every package inside it is trustworthy.

As I said yesterday, the same principle applies to Python and PyPI. If somebody is building a FastAPI application, AI may recommend packages there as well. So organisations need a dependency policy.

Before a package reaches production, check who publishes it, check its history, and check whether the project is legitimate. Lock the version and know what dependencies your production applications actually contain.

If you’ve used one of the malicious packages identified in this campaign, don’t only remove the package. Assume credentials available to that development environment may have been exposed, including GitHub tokens, cloud credentials, API keys, database passwords and deployment secrets. Removing malicious code doesn’t invalidate secrets it may have already stolen.

Finally, today we have a serious WordPress vulnerability affecting the Zella WooCommerce theme. Versions before 2.6.3 contain an insecure file upload function, and the attacker doesn’t need a WordPress account. The vulnerable feature is used for uploading custom fonts, and that sounds harmless, but the server isn’t interested in whether you intended to upload a font; it cares about what file actually arrived.

The vulnerability can potentially allow an attacker to upload PHP, and PHP is executable code. So instead of uploading typography, an attacker may potentially upload instructions for your server to execute. That can lead to complete website compromise.

For an online business, that could mean malicious code on the site, customer information being accessed, payment pages being modified, new administrator accounts being created, or malware being left behind for later access. Version 2.6.3 contains the security changes, so if you’re using Zella, update immediately.

But because this vulnerability can potentially lead to server-side code execution, don’t stop when WordPress gives you a green tick. Check for unexpected PHP files, check administrator accounts, check recently modified themes and plugins, and review security logs if they’re available. Updating closes the vulnerable upload function, but it doesn’t remove something an attacker may already have uploaded.

Today’s stories come from completely different parts of the technology stack: Citrix infrastructure, Next.js, React and TanStack, npm dependencies, and WordPress. But the underlying problem is the same. Modern websites aren’t one piece of software anymore; they’re chains of trust.

Your application trusts its framework, and the framework trusts its dependencies. The application trusts the infrastructure underneath it, and the business trusts the people deploying all of it.

AI has made it dramatically easier for more people inside an organisation to build software, and that’s a good thing. But it also means somebody needs to know what was deployed, what it depends on, what credentials it can access, and who is responsible for keeping it secure.

Getting an application to work is only the first step. The next question is: is it safe to run in production? That’s your website security briefing.