Stolen AI API Keys + 101 Malicious npm Packages

If somebody in your organisation is building websites or internal tools with AI, today’s briefing is particularly important. Australia’s cyber security agency has just warned organisations that stolen AI API keys are already being used to access AI services, consume credits and potentially reach connected business systems. We’ve also got a major Next.js security release scheduled for today covering nine vulnerabilities, more than 100 malicious npm packages targeting developers, a Drupal API authentication flaw, and new Australian government guidance that specifically says security controls apply whether your software is written by a human or by AI.

I’ve spent 25 years building production software, and increasingly I’m seeing people who have never been software developers suddenly able to build real applications. That’s incredibly powerful. But getting an AI-generated application to work isn’t the same as making it safe to deploy. So let’s look at what happened, what it means for your organisation and what you should check today.

Let’s start here in Australia. The Australian Signals Directorate has issued new guidance about organisations protecting their AI services, and this isn’t a theoretical warning. ASD says malicious actors are obtaining access through compromised API keys, stolen authentication tokens, compromised user sessions, vulnerable applications and third-party access arrangements.

Once an attacker gets one of those credentials, they may be able to use your organisation’s AI account. That could consume your paid credits, disrupt legitimate services, or expose capabilities and information available to the account. But there’s another part of the warning that’s particularly important.

AI agents can now connect to other systems. An agent might have access to your database, your CRM, your files, your email or other internal applications. So compromising the AI credential may give an attacker a pathway into considerably more than the AI service itself.

And this is where vibe coding introduces a very practical risk. Imagine somebody inside your organisation asks AI to build a small application that needs to talk to an AI model. So they create an API key, they paste it into the project, the application works and everybody moves on.

But where did that key end up? Was it committed to GitHub? Was it included in client-side JavaScript? Is it sitting inside a .env file on a publicly accessible server, and does that key have access to considerably more than the application actually needs?

ASD’s advice is to maintain an inventory of AI accounts, service identities and credentials. Every credential should have an owner, and every credential should have only the permissions it actually requires.

Next up is Next.js, and I would pay attention to this one if your organisation is vibe coding websites or web applications. The Next.js team announced a scheduled security release for today, the 30th of September. It’s expected to address nine vulnerabilities: one critical, two high, five medium and one low.

The Next.js team says the planned patch versions are 16.3.8 and 15.5.27. At the time I’m recording this, the complete details of those nine vulnerabilities haven’t been published on the official Next.js security page. So I’m not going to invent the consequences, but there’s a very practical reason this matters.

Next.js has become extremely common in AI-generated web projects. Ask an AI coding tool to build a modern website and there’s a very good chance Next.js will be one of the frameworks it suggests. We’ve already had a serious Next.js security issue this month.

On the 22nd of September, a critical vulnerability was disclosed in the Node.js implementation of Next.js, and under the affected conditions, processing a malicious image could lead to remote code execution. That means code supplied through something as innocent-looking as an image can potentially become a server security problem.

So here’s today’s action. If your organisation has Next.js applications, find out what versions they’re actually running. Don’t assume the application is safe because it was generated recently, and don’t assume your AI coding assistant automatically selected a secure dependency version.

Watch for today’s official security release, then test and deploy the patch release for the appropriate supported Next.js branch. AI can generate the application, but it doesn’t automatically establish your vulnerability management process.

Now let’s talk about something particularly relevant to vibe coding. Researchers have uncovered 101 npm packages involved in a campaign called Phantom Sub. Together, those packages accumulated around 490,000 downloads.

The packages abuse the Baileys WhatsApp library, and they can silently subscribe developers’ WhatsApp accounts to channels or groups without their consent. This particular campaign isn’t stealing your customer database, but that’s not the reason I think it’s important. The important part is how modern software gets built.

When you’re vibe coding, the AI frequently tells you to install packages: run this command, install this library, add this dependency. Because the package already exists in npm, there’s an understandable tendency to assume somebody has checked it, but they might not have. npm is a distribution system, not a guarantee that every package inside it is trustworthy.

The same principle applies to Python’s package ecosystem. If you’re building FastAPI applications, you have exactly the same supply chain question with the packages you’re installing from PyPI. The Australian government’s updated software development guidance now explicitly says third-party libraries should come from trustworthy sources and dependencies should be pinned to approved versions.

So when AI tells you to install a package, don’t blindly install it. Check who maintains it, whether the project is legitimate, its release history and what you’re actually importing. Then lock the version you’re deploying, because AI generating a convincing package name doesn’t mean that package is trustworthy.

Next up is Drupal, and this one is particularly relevant to organisations running Drupal as a backend or exposing content through APIs. A vulnerability has been disclosed in the REST and JSON API Authentication module. The module is designed to add another authentication layer to Drupal’s APIs, but it doesn’t correctly enforce those authentication requirements across every API request, which can result in access bypass.

That’s an important distinction, because this isn’t a vulnerability in Drupal core; it affects a contributed authentication module. But think about why an organisation installs something like this. You’re specifically installing it because you want to control who can access your API, and if that control isn’t being applied everywhere, the security boundary you think exists may not actually exist at all.

This becomes particularly important when people start adding AI-generated front ends or integrations to an existing Drupal environment. Someone builds a Next.js front end, someone else creates an internal application and another person builds an AI agent. They connect everything to the Drupal API, and suddenly your original website has become the backend for several completely different applications.

That’s where API security needs to be treated as part of the architecture, not something added after the application started working. Check whether you’re using the REST and JSON API Authentication contributed module. Then review the Drupal security advisory, update to the patched release, and verify which API endpoints can actually be reached without authentication.

Don’t just test the login screen; test the API. And finally this morning, there’s a bigger development in Australia’s security guidance. The Australian Signals Directorate has updated its software development guidance, and there’s one sentence I think every organisation experimenting with vibe coding should understand.

The guidance now explicitly applies to human, AI-assisted, AI-powered and AI-driven software development. In other words, from a security perspective, it doesn’t matter who wrote the code. If AI wrote your application, it’s still software and it still needs software engineering.

The updated guidance includes controls around separating development, testing, staging and production environments. It says dependencies should be pinned to approved versions, source code commits should be scanned for credentials, keys and secrets, and those secrets should be prevented from entering the authoritative source code in the first place. It also calls for automated testing, code review, static security testing, dynamic security testing and software composition analysis.

That’s an important message for organisations right now, because AI has dramatically reduced the skill required to create software, but it hasn’t reduced the consequences of deploying insecure software. Your marketing manager can build something useful, your operations team can automate a process, and someone can create a Next.js website over a weekend. They can connect FastAPI to PostgreSQL and have the whole thing running in production incredibly quickly.

That’s the opportunity, but production doesn’t care how quickly you built it. If authentication is wrong, it’s wrong. If the database is exposed, it’s exposed, and if an API key is committed to GitHub, it’s compromised.

And if a malicious dependency gets installed, how quickly you built the application doesn’t magically make that dependency safe. There’s a common thread throughout today’s five stories. The barrier to building software has collapsed, but the barrier to building secure software hasn’t.

Next.js still needs patch management, and Drupal still needs access control testing. npm dependencies still need supply chain checks, and API keys still need proper secrets management. And AI-generated applications still need the same engineering controls we’d expect from traditionally developed production software.

So if people inside your organisation are vibe coding, don’t stop them from experimenting. Give them a safe path from experiment to production: separate development from production, keep secrets out of source code, review dependencies, test authentication and permissions, scan the application, and have somebody accountable for what eventually gets deployed. Because “it works” isn’t the same as “it’s safe to deploy”. That’s your website security briefing.