On March 31, attackers compromised axios — a JavaScript library downloaded roughly 100 million times a week. Here’s what happened, who’s affected, and what to do now.

If you’ve never heard of axios, here’s the short version: it’s the library that most JavaScript applications use to talk to the internet.

Fetching data from an API, submitting a form, making a request to a backend service – axios handles it. It’s in frontend apps, backend services, CI pipelines, and internal tools. Chances are it’s somewhere in your stack right now, possibly several places.

On March 31, 2026, axios—with roughly 100 million weekly downloads—became the vector for one of the most significant npm supply chain attacks in recent memory.On March 31, 2026, axios—with roughly 100 million weekly downloads—became the vector for one of the most significant npm supply chain attacks in recent memory.

You don’t need to have installed axios directly to be at risk.

Any package in your dependency tree that lists axios with a floating version range (^1.x) and was rebuilt during the exposure window may have pulled in the malicious version automatically. This also includes AI coding assistants and automated tooling — anything that ran npm install on your behalf yesterday should be treated the same as a manual install.

We’ve written before about software supply chain security and the systemic risks that come with modern dependency management. This attack is exactly the scenario we described – not a theoretical edge case, but a live incident affecting one of the most widely used libraries in the JavaScript ecosystem.

Google’s Threat Intelligence Group has attributed the attack to UNC1069, a North Korean group previously active in cryptocurrency theft.

Here’s what happened, how it worked, and what you should check right now.

What happened

The attacker didn’t touch a single line of axios source code.

Instead, they compromised a long-lived npm access token belonging to jasonsaayman, the project’s lead maintainer. With that token, they published two new releases – one for the 1.x branch and one for the legacy 0.x branch – 39 minutes apart, covering both release lines simultaneously.

Both releases modified exactly one file: package.json. The only substantive change was adding plain-crypto-js@4.2.1 as a runtime dependency. That package was pre-staged 18 hours earlier, under a separate attacker-controlled account, with a clean version first to build registry history before the malicious update was pushed.

plain-crypto-js contains a full copy of the legitimate crypto-js library – every source file identical, bit-for-bit. The only difference is a postinstall hook: “node setup.js”.

When npm resolves the dependency tree and runs that hook, the dropper fires. It contacts the attacker’s command-and-control server, delivers a platform-specific payload for macOS, Windows, or Linux, then deletes itself and replaces package.json with a clean stub reporting version 4.2.0.

By the time npm install finishes, there’s no error, no warning, no obvious trace. The directory node_modules/plain-crypto-js/ exists, but npm list shows version 4.2.0 – not the malicious 4.2.1 that actually ran. Standard npm audit finds nothing.

Why this specific attack is worth studying

Most supply chain incidents involve obvious red flags – a zero-history package, a suspicious name, a sudden maintainer change.

This one was deliberately engineered to avoid all of them.

That’s what makes it worth paying attention to, even if axios isn’t in your stack – the technique will be reused.

The attacker published a clean decoy package 18 hours before activating the payload – long enough to avoid “brand new account” alerts from registry scanners. The malicious axios releases were signed by the legitimate maintainer’s account. No corresponding commit or tag appeared on GitHub (that gap is the forensic signal, in hindsight), but most CI systems don’t verify OIDC provenance on pull.

This is the attack pattern that NIS2 and CRA regulations are increasingly focused on: not a breach of your perimeter, but a compromise of the supply chain your code depends on.

Your code didn’t have a vulnerability. Your tooling did.

The OIDC misconfiguration that made it possible

Axios had OIDC Trusted Publishing configured for its release workflow.

In theory, this should have made a token-based publish impossible – OIDC ties releases to specific GitHub Actions runs, and the ephemeral token can’t be stolen.

In practice, the GitHub Actions workflow passed both the OIDC credentials and a classic NPM_TOKEN environment variable. When both are present, npm defaults to the token. The long-lived token – which can be exfiltrated – was effectively the only authentication method that mattered.

This is a common misconfiguration. Many projects enable OIDC Trusted Publishing and consider the job done, without removing or rotating the classic token that overrides it.

Check if you’re affected – right now

Step 1 – Check your lockfile for the malicious versions

Step 2 – Check for the malicious dependency in node_modules

The presence of this directory – regardless of what version package.json now reports – means the dropper executed.

Step 3 – Check for persistent artifacts

If you find any of these

The response depends on where the install ran.

For ephemeral CI runners (e.g. GitHub-hosted), the runner is destroyed after each job — rotate any secrets that were injected during the affected run and move on.

For developer machines and self-hosted runners, treat the system as fully compromised: isolate it from the network immediately and re-image it or restore from a verified clean backup taken before March 30.

Once you have a clean machine, rotate everything that was accessible from it: npm tokens, SSH keys, cloud credentials (AWS, GCP, Azure), CI/CD secrets, and any values in .env files present at install time.

To downgrade cleanly

What to change in your CI/CD configuration

Beyond the immediate incident, this attack exposes a few controls worth auditing across your pipelines.

The broader pattern

This isn’t an isolated incident.

The axios attack follows the same playbook as the CrowdStrike npm compromise, the IoliteLabs VSCode extension backdoor from a few days earlier, and dozens of similar incidents over the past two years.

That model is under sustained attack.

The attacker here invested 18 hours of prep time, built platform-specific payloads for three operating systems, and designed the dropper to self-destruct. This is not someone experimenting – it’s operational tradecraft applied to the JavaScript supply chain.

As we covered in our supply chain security framework, the highest-risk entry points are often not your own code but the tools and processes you depend on to build and deploy it.

The question isn’t whether your perimeter is secure, it’s whether your CI pipeline would have caught this before it ran.

For teams with third-party risk exposure

If you’re managing a product that runs JavaScript in CI and you have compliance obligations – PCI DSS, NIS2, ISO 27001 – this incident is worth documenting even if you weren’t affected.

Our third-party cyber risk management work often starts with incidents like this one: not after a breach, but as a trigger to audit what dependency hygiene actually looks like in practice across an engineering org.

The controls that would have caught this – OIDC provenance checks, version pinning, –ignore-scripts in CI, outbound network monitoring – aren’t difficult to implement. They just tend not to exist until something goes wrong.

If you want to review your current posture, get in touch.

Indicators of compromise

Many modern Android applications are highly advanced and operate in sensitive domains like banking, money transfers, and other critical services people rely on daily. A rooted environment gives attackers elevated access to the device, which they can abuse in order to bypass the app’s restrictions, extract sensitive data, and interfere with the app’s behavior.

To counter these threats, many apps implement protections against common tools and techniques used in reverse engineering. These include anti-root, anti-hook, and anti-debug mechanisms, which are designed to make an attacker’s job significantly more difficult—often requiring considerable effort and creativity to bypass.

A practical look at protection mechanisms

This article provides other security researchers with a practical look at how some of these protection mechanisms are implemented and how they can be bypassed during penetration testing or security research.

Additionally, by understanding how these protections work, developers can build stronger, more resilient security mechanisms into their apps and even extend these ideas to develop more advanced and effective techniques.

Furthermore, during this research, an application called TamperLab was created. It includes various protection mechanisms to detect whether a device is rooted, whether any hooking is in place, or whether the application is being debugged. The project is fully open-source, and contributions are welcome.

It can be found on the following GitHub page for you to check out:

Anti-Root Protections

In this section, we will look at some commonly used root detection techniques and their implementations, and immediately follow each one with an example of how it can be bypassed during testing or reverse engineering.

The “One Function” Folly

The most common way of implementing protection measures such as anti-root, anti-hook, and anti-debug is by placing all checks inside a single function. This is a common mistake, as it gives attackers the opportunity to bypass all protections within seconds.For example, in the following scenario, the RootBeer library is used to quickly demonstrate why placing all checks in a single function can be problematic. As shown in the code snippet below, the isRooted() function is called.

Such a function includes various methods to detect if the device is rooted.

Although the function includes many ways to detect if the device is rooted, it is not sufficient because the isRooted() function itself can be hooked, allowing an attacker to bypass all detections with a single hook.

Using the following simple Frida script, we can do exactly that. We obtain a reference to the RootBeer class and hook the isRooted() function, immediately returning false.

Using the following command, the targeted application can be started with the hook applied.

As shown in the following image, the previously created script successfully bypasses all the checks because they are contained within a single function.

Testing this inside TamperLab shows that we successfully bypass the protection measure, and a green checkmark is displayed.

SU Binary Check (Shell)

All rooted Android devices contain the su binary, and any application requiring root access must use su to elevate privileges and perform privileged actions on the device.

When present on a device, applications can detect the existence of the binary and conclude that the device is rooted. A quick way to check for it is by programmatically executing the which su system command.In my application, I created a simple HelperClass that contains various functionalities and detection methods. One of its purposes is to execute system commands.

The executeCommand() function essentially passes the given command as an argument to the exec() function, which executes it on the device.

If the su binary exists, the command will return its full system path, otherwise, an error code will be returned.

Using Frida, we can bypass this technique by hooking the exec() function itself. If we detect a command such as which su, we can replace it at runtime with another non-existent command.

As demonstrated, by using this technique, we can target specific exec() parameters after reverse engineering the application and bypass the detection mechanisms in place.

SU Binary Check (Native C/C++)

Another way developers may check for the su binary or for rooted devices in general is by writing native C/C++ code using JNI. In case you are unfamiliar, JNI (Java Native Interface) is a framework that allows Java code running on the Android platform to interact with native applications and libraries written in C or C++.

For example, we can check for the su binary by iterating through common system paths where it might exist, and then using the std::ifstream function to check if the file can be opened.

A small Java class is then created to serve as a bridge between the Java code and the native C/C++ code in the application. It uses JNI (Java Native Interface) to perform the native task.

Under normal circumstances, you wouldn’t have access to the source code. However, a common way to reverse engineer the application is by decompiling it using JADX, which can be done with the following command.

Once decompiled, your application may contain various libraries. You can easily filter through them by searching for files with the .so extension, which indicates native libraries.

To reverse engineer the library, tools such as Ghidra or IDA Pro can be used. In this case, Ghidra was used.

The decompiled code shows that ifstream is first used (1) to check whether the file exists. Based on this check, the function returns \x01 (JNI_TRUE) (2) if the su binary is found, otherwise, it returns \x00 (JNI_FALSE) (3).

Since this is a JNI function and is exposed using extern “C”, it appears in the symbol table with the exact name observed in Ghidra.

Bypassing such checks is relatively straightforward. To hook a native function using Frida, we use Interceptor.attach() and specify the target function using Module.findExportByName().

Since we are intercepting a function from the native library, we need to attach to the process while it is already running by using the -n parameter with the following command.

As shown in the script’s output, we successfully bypass the check even though it resides within JNI code.

Another clever approach is to hook the open() function instead of the entire native function implemented in the application.

Since std::ifstream() ultimately invokes the open() system call, we can hook open() to intercept any attempt to access a binary whose path contains “su”. We can then substitute that path with a fake one to bypass the check.

As shown in the image, this technique effectively bypasses native checks early by using the -f flag to hook before execution, unlike the -n flag, which attaches the hook while the process is already running.

Spoofing /proc/mounts

Nowadays, many Android devices are commonly rooted using Magisk, which comes with a variety of built-in features.

The /proc/mounts file contains a list of all currently mounted filesystems on the device. Additionally, when a device is rooted using Magisk, it modifies the boot image and mounts partitions dynamically by default, so you may find traces of Magisk there as well.

An implementation to detect this might look like the following, where an application reads the contents of /proc/mounts in search of Magisk.

To bypass this, we can create a script like the following, where we define a list of mounts that don’t contain Magisk traces or any other suspicious entries, for that matter.

The first interceptor hooks the open() system call to capture the file descriptor used when accessing /proc/mounts.

The second interceptor hooks read(), checks if the file descriptor corresponds to /proc/mounts, ensures the content hasn’t already been spoofed (to prevent repeated modifications and potential crashes), and finally replaces the buffer with our fake mount data defined at the top.

By running the hook, we successfully spoof the contents of /proc/mounts with our fake data, effectively bypassing the detection check.

It’s important to note that these techniques can be implemented and bypassed in various ways. Consequently, multiple solutions and countermeasures exist to address them.

Anti-Hooking Protections

Hooking is a powerful technique used during mobile penetration tests because it allows intercepting, modifying, and monitoring an application’s behavior at runtime. It provides direct access to function calls, arguments, return values, and the internal logic of methods.

To perform such attacks, Frida is a widely used tool that enables pentesters and attackers to bypass security controls or extract potentially sensitive data.

Frida Port Detection

A common way to detect Frida is by checking for open frida-server ports, since Frida communicates using WebSockets. Simple checks often look for ports like 27042 or 27043, which are the default ports used by Frida.

Such checks can be easily bypassed by simply starting the Frida server on a different port using the following command.

A more advanced detection method involves scanning all ports by sending specific HTTP requests and checking for a 101 Switching Protocols response, which indicates the presence of a Frida server.An example of such native code would involve sending a WebSocket upgrade request to every open port on the device. If the response contains 101 Switching Protocols, it confirms that a Frida server has been successfully detected.

This check can be bypassed by hooking the read() calls and inspecting the buffer content after the call completes. If the buffer contains 101 Switching Protocols, indicating a Frida server query, we can modify the response to something benign such as HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n to evade detection.

As demonstrated, once the hook is executed, the check is successfully bypassed.

Frida Threads Detection

In Linux-based environments (including Android), each process has a task directory located at /proc/self/task, containing a subdirectory for each thread within the process. Each of these subdirectories includes a comm file that holds the name of the corresponding thread.

When Frida is injected into a process, it typically creates several threads for its internal operations. These threads often have distinctive names such as frida, gum-js-loop, gmain, gdbus or some other which can be used to detect Frida’s presence.

To better understand this, we can run the following command on the device to retrieve the names of all threads for a specified process.

As shown in the following snippet, this is the output of the thread list when no Frida hooks are active.

When a Frida hook is applied to the process, threads named gmain and gdbus appear both associated with Frida’s runtime. This allows us to detect Frida based on the presence of these thread names.

To detect this, we can use C++ code like the following, which loops through each comm file in the /proc/self/task directory to retrieve thread names and checks them against a list of common thread names used by Frida.

One intriguing approach to evade detection is to patch the entire frida-server binary by replacing all occurrences of strings like gmain. By searching for gmain in Ghidra, we can observe the following results.

By selecting one of the instances, we can examine the disassembled code to pinpoint its exact location.

We can now use Ghidra’s built-in hex editor to modify these strings, replacing gmain with another string, such as hackr.

After injecting the Frida hook, we can see that we have successfully bypassed the detection, as it no longer identifies Frida’s threads.

If we loop through the thread names again for the application we are attacking, we can see that it now successfully contains the hackr thread name.

Of course, there are other detectable strings, but this simple example demonstrates one way to bypass detection by directly patching the frida-server binary yourself. This way you could build an entirely different frida-server to avoid detections or modify the original source code as well.

Anti-Debug Protections

Anti-debug protections are another way to protect your Android application from reverse engineering. These mechanisms aim to detect or prevent debugging attempts, stopping attackers from stepping through the app’s code instruction by instruction to understand its internal logic.

Like most security measures, anti-debug mechanisms can also be bypassed using Frida hooks. However, I want to show you how you can defeat these protections using a debugger itself.

Defeating Anti-Debug using Debugger

isDebuggerConnected()

This is a simple, ready-made function that checks if a debugger is connected to the application. It returns true if a debugger is detected, otherwise, it returns false.

Implementing such a function is straightforward, and you can call it as follows:

To use the debugger and bypass this check, we can utilize JADX’s integrated debugger. Before launching it, ensure the application is already running.

Another way to start an application is by using the following ADB command, which will launch the app but pause and wait for the debugger to attach.

As shown, when you launch the application, it will display a message indicating that it is waiting for a debugger.

In my case, it doesn’t work, but I can open the application without it waiting for the debugger. However, your application might require this behavior, so it’s important to test both methods.

Additionally, whenever you’re done or close the application, make sure to run the following command to remove the app from waiting for a debugger.

Once ready, you can open JADX and load the APK file of the target application. You can also pull the APK from your device using ADB.

Once loaded into JADX, select the green bug icon, which opens a dialog prompting you to choose the application to debug along with its process ID.

After the debugger attaches, the application’s execution is automatically paused inside the MainActivity. You can then press the green play button to continue running the application.

Once you find the correct position to set a breakpoint, you can do so by pressing the F2 key. For this example, I set the breakpoint exactly where the isDebuggerConnected() function is called.

The following instruction essentially calls the isDebuggerConnected() function using the invoke-static opcode.

Then, the move-result instruction moves the return value of the function (either true or false) into the v0 register.

By stepping over these two instructions, we can observe that the v0 register contains the value 1, indicating that a debugger has been detected.

To bypass this check, we can simply set the value to 0 using the debugger, as shown below:

Continuing the application’s execution, we successfully bypass the check by manipulating the variables during debugging.

Detection via USB & ADB

Another interesting way to detect debugging is by checking if the device is connected via USB with ADB enabled. While this isn’t a direct debugger detection method, it remains a useful check nonetheless.

A simple implementation might look like the following, where the app dynamically listens for the USB_STATE broadcast and parses the connected and adb boolean extras from the received intent.

We can also bypass this check by using the debugger to place breakpoints at the appropriate locations.

In this case, I set a breakpoint on the if-eqz instructions, which checks whether the values in registers v0 and v2 are equal to zero. These registers correspond to the connected and adbEnabled flags.

When the breakpoint is hit, we observe that both values are set to 1 (true), indicating that USB is connected and ADB is enabled.

We can now simply set these two values to 0 (false), causing the check to fail and allowing the app to continue execution.

Conclusion

We have explored several common anti-root, anti-hook, and anti-debug techniques and demonstrated how each can ultimately be bypassed. However, it is important to recognize that these protections still play a critical role in Android security.

No protection is entirely foolproof. Given enough time and the right tools, a determined attacker can often find a way around most defenses. However, the goal of these mechanisms isn’t to create an unbreakable application, but rather to increase the complexity of attacks. This raises the time, effort, and skill required for an attacker to compromise the application, which can deter casual attackers and slow down more advanced ones.

In short, while these security checks can be bypassed, they remain a valuable part of a defense-in-depth strategy. Labs like TamperLab that we have created, provide a practical environment where you can practice implementing these detection mechanisms and learn how to bypass them. It’s about making it hard enough that breaking the security is no longer worth the effort.

At Infinum, we help you stay ahead with tailored cybersecurity services, including penetration testing and security assessments. Whether launching new products or protecting existing ones, we identify weaknesses before attackers do so you can focus on what matters. Learn more about how we keep your digital world secure on our cybersecurity page.

AI is changing how software gets built: faster timelines, leaner teams, fewer blockers. But does all that speed come at a cost? We put AI to the test in a real-world security experiment, and what we learned should matter to anyone leading modern product, platform, or tech teams.

According to Collins Dictionary, vibe coding is officially the word of the year – and if you’ve spent literally any time around engineering teams lately, that probably doesn’t surprise you.

Obviously, it’s catching on fast. 

Microsoft recently shared that around 30% of the code in some of its repositories is now AI-generated. This shift is one of the defining cybersecurity risks of 2026 — our cybersecurity trends overview covers the trade-off between vibe coding and security in depth.

At Infinum, we see this trend up close, both in internal experimentation and in conversations with clients who are increasingly curious about AI-assisted development.

The appeal is clear: development is faster, prototypes turn into products at record speed, and teams feel confident shipping. 

But is that confidence earned? We decided to find out.

Security doesn’t work on vibes

A growing belief is quietly taking hold in many teams:

“If I tell the AI to make it secure, it probably will.”

That assumption is understandable because AI is very good at reproducing patterns that look correct. When prompted, it can generate code that resembles common security practices and includes familiar terminology, giving the impression that risk has been addressed. But is it, really?

Instead of debating, our cybersecurity engineer designed a simple, hands-on experiment.

He asked AI to build apps with varying levels of security guidance, from none to OWASP-level detail, and then he tried to break them.

We didn’t want to test whether AI could write code. We know it can.

Let’s see the results.

The apps we built (and broke)

We asked AI to build three medium-complexity web applications, realistic enough to offer an attack surface, but not so complex that AI failed to build them. One app was generated with no security input at all, one with light guidance, and one with detailed, best-practice-driven instructions.

Turns out, not even specific prompts are enough to build applications that can survive real-world attacks.

What actually went wrong 

Even with better prompts, the same kinds of security gaps kept popping up.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI didn’t forget libraries or miss syntax.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI simply doesn’t understand cybersecurity, and it couldn’t reason about how things might go wrong, and that’s where real-life threats were.

While we are aware that this is an experiment of a limited scope, it is still important to note recurring issues we recognized:

In conclusion, the issues discovered weren’t bugs in the traditional sense. They were assumptions – that roles are respected, that the app can trust user input, that attackers won’t be creative.  

But attackers are creative, and they have all the time in the world to look for what you missed.

Why this matters beyond the code

Security is not just a dev problem. It’s a systems-thinking problem, and it affects every role involved in shipping software.

For CTOs & Heads of Engineering

AI speeds things up, no question, but it can’t replace architectural thinking.

The biggest failures in these apps weren’t in the code; they were bad assumptions about how trust, roles, and permissions work. Even when AI adds security controls, it struggles to secure the system as a whole.

We’ve all recently witnessed this: in our deep dive into OpenClaw (ex Moltbot), we explored what happens when AI sidekicks are given broad access with no guardrails. The takeaway? When AI has too much control, your data is very likely at risk.

Again, that’s an architectural one. And it’s still up to humans to get it right.

For Founders & Execs

All three apps worked. Some even looked secure. But they could still be exploited in serious ways, often through features that seemed harmless.

Remember this: AI gives a false sense of security. Without hands-on testing, issues like these show up only after damage is done. If you’re building with AI and need it to be secure from the start, our custom AI development services combine speed with security by design.

For Security Leaders

The vulnerabilities we found didn’t have CVE numbers. They weren’t from outdated libraries or missing headers. They were logic and abuse-case failures – the exact kind of problems automated scanners don’t catch. Addressing these systematically through structured security governance, risk assessment, and compliance frameworks is exactly what governance, risk, and compliance services are designed to support.

Manual penetration testing still matters because it mirrors how attackers behave, not just what vulnerabilities exist – and AI-assisted code makes this more important, not less.

For Developers

AI can implement what you tell it, but it’s not a security expert. It won’t catch logic flaws, system-wide assumptions, or the creative misuse attackers are known for. For a practical look at how to work with AI coding assistants without sacrificing code quality, see our roundup of AI tools for development teams.

Writing secure apps still requires developer intuition, threat awareness, and curiosity about how features might be abused.

So, yes. AI-generated code can be secure, but it takes judgement, experience, and most importantly, testing. 

What should you do now

Use AI. Embrace the speed. Build more, experiment faster, prototype wildly.

But don’t confuse working code with secure code.

Why automated scanners won’t help

Automated tools catch known and “low-hanging fruit” types of vulnerabilities. But issues discovered in this experiment weren’t in any vulnerability database, because they weren’t traditional bugs – they were incorrect assumptions about how systems would be used.

Automation wouldn’t have caught that, but manual testing told us whether the system could survive a curious attacker.

The real takeaway

The apps worked and security looked reasonable. 

But AI inherently doesn’t understand security, which is especially obvious once software interacts with real users, real data, and real incentives to misuse it. Security failures rarely come from missing syntax or forgotten libraries; they emerge from incorrect assumptions about behavior, trust, and intent.

Attackers do nothing but imagine misuse.

This is exactly why manual penetration testing exists: not to check a box, but to ask the one question that AI won’t:

“What happens if someone does the wrong thing on purpose?”

Security still requires human intent and adversarial thinking. No matter how well you prompt it, AI can’t protect against what it doesn’t anticipate.

If your app was built with AI assistance, this isn’t a theoretical risk. It’s a structural one.

If you want real, certified humans to have a go at your app – partner with Infinum’s security team to test your app the way real attackers would.  We’ll help you find the blind spots, close the gaps, and build safer systems, so you can move fast without leaving yourself exposed. If we find zero issues, the beer is on us.

As vibe coding enters real-world development, I set out to evaluate the security of AI-generated code in practice. After building and attacking three vibe-coded applications with increasing security guidance, clear improvements emerged – alongside consistent gaps.

Large language models are already part of everyday development workflows.

Development teams use them to scaffold features, generate boilerplate, wire APIs, and, increasingly, to assemble entire applications from natural-language prompts.

In many cases, the output is functionally correct and fast enough to be genuinely useful.

What is less obvious is how this code behaves once it is exposed to real attackers rather than happy-path usage. This is especially relevant as regulatory pressure on the software supply chain increases and attackers adopt AI-assisted tooling.

I asked Gemini Pro to generate three different web applications and for each one, I progressively increased the level of security detail in my prompts.

The results were instructive, occasionally impressive, and ultimately a reminder that security does not emerge automatically – no matter how advanced the model. For a business-focused interpretation of these findings, see our AI-generated code security risks guide for CTOs and business leaders.

The plan and methodology

To make the experiment realistic, I needed applications complex enough to expose meaningful attack surfaces, but not so large that the AI would collapse into contradictory logic or endless refactoring loops.

I intentionally avoided very simple apps (e.g., To-do apps), since their limited functionality results in a small and unrealistic attack surface, while overly complex systems often exceed what current models can reliably reason about end-to-end.

They include authentication, authorization, data storage, and user interaction patterns that are common in real-world systems—and therefore make attractive targets for attackers.

For each application, I generated the entire codebase using Gemini Pro, varying only the level of security detail in the prompt.

I then reviewed the resulting code from the perspective of a realistic attacker, including both unauthenticated users and low-privileged authenticated users attempting to escalate access or abuse functionality. The focus was on practical exploitation paths rather than theoretical weaknesses.

The test subjects

Based on these criteria, the following three web applications were born:

Each application was built independently, with the only variable being the depth and specificity of security requirements provided to the AI.

Discoveries and vulnerabilities

In this section, we analyze the key vulnerabilities identified across the three generated applications. Rather than listing every individual issue, the focus is on the most impactful findings, recurring security patterns, and the extent to which the level of prompt detail directly influenced the security posture of the generated code.

Results at a glance: What broke and why

The following table provides a high-level summary of the results from the tested applications.

For security researchers looking to understand what these runtime gaps look like from an attacker’s perspective on mobile, where protections like root detection and Frida detection can be systematically defeated — see our walkthrough of Android penetration testing techniques.

Simple Project Tracker: No security, just vibes

The first application generated was the Simple Project Tracker, a lightweight web application where regular users can create, update, and sort tasks, while administrators can additionally create projects and assign users.

No explicit security requirements were provided. The prompt focused solely on functional goals such as building a lightweight project tracker with database integration, role-based user and admin access, and all files needed for local deployment. As a result, the following prompt was used:

I would like to build a simple project tracker web application. Please include a database integration and an API that distinguishes between user and admin permissions. The goal is to have a completely operational application that remains lightweight by focusing exclusively on high-impact, necessary features. Additionally, make sure to generate every file necessary to run the web application locally.

For this application, AI selected the following technology stack:

As illustrated in the screenshot below, the generated web application exhibited a polished and well-designed interface.

Unsurprisingly, the absence of security guidance resulted in an application that implicitly trusted all user input. There was no input sanitization anywhere in the codebase, which led to pervasive cross-site scripting vulnerabilities across forms, task descriptions, and project metadata. 

Below is an example of the generated code.

The registration flow was particularly revealing. User roles were assigned directly from client-controlled input:

Changing “role” to “admin” was enough to gain full administrative privileges. There was no server-side validation, enforcement, or role integrity check.

Authorization was equally fragile. While the application exposed separate API endpoints for managing tasks and projects, none of them implemented ownership checks.

Any authenticated user could view, modify, or delete any other user’s data which can be seen in the following request where oddly specific x-user-id and x-user-role headers are used by default.

Session handling further reinforced the trust-in-the-client model. Authentication state was stored in unsigned cookies containing raw user objects:

Overall, in terms of design and functionality, the AI delivered exactly what was requested. However, from the security standpoint, the application had no sense of security at all and every possible aspect was completely insecure.

Functionally, the application worked exactly as requested. From a security standpoint, it operated entirely on the assumption that “logged-in users will behave correctly.” Needless to say, attackers do not follow that assumption.

Project Resource Hub: Better, but not bulletproof

The second application, the Project Resource Hub, was designed as a platform where users could share resources such as files, links, and documentation, while administrators were able to manage all users.

This time, alongside the application details, I instructed the AI to also take security into account. Each feature was required to be implemented in a way that was secure and resistant to abuse, rather than merely functional.

… web application details …

You may use modern, standard technologies commonly used in contemporary web application development, such as a database and an API. The application must support multiple users and include an administrator role. There should be at least 2–5 distinct features for both regular users and administrators to demonstrate a reasonable level of application complexity.

Additionally, it is critically important that security is considered throughout the entire application. Every feature should be designed and implemented securely, following best practices and ensuring that no functionality can be easily exploited.

Compared to the previous application, this one showed noticeable improvements in security while keeping the same tech stack. Specifically, the AI implemented several measures, including:

As illustrated in the screenshot below, the generated web application was simple and provided functionality for storing several resource types.

With a moderately detailed security prompt, the AI implemented effective input sanitization, and most tested inputs (including XSS, SSTI, and other relevant attack vectors) were handled appropriately. 

Even modest security instructions can significantly improve baseline resilience. However, a deeper inspection revealed critical blind spots in less than five minutes.

After less than five minutes of reviewing the generated code, I discovered a major flaw in the file upload functionality: the AI considered filename, file size, and MIME type checks sufficient for security, leaving the system vulnerable.

Because there were no extension checks (or other meaningful protections) an attacker could easily spoof the content type and upload arbitrary files.

Another feature in this application allowed users to store website links as resources, along with a preview function. Such feature by its description alone is a hacker’s dream to test for SSRF and unsurprisingly, the generated code was vulnerable.

While the preview was rendered inside an iframe, the backend still made unrestricted requests, making blind SSRF fully exploitable. 

Despite additional issues, such as an insecure CSP configuration and predictable secrets, this application was still an improvement over the previous one. 

However, several security measures were either ineffective against real attacks or failed because the AI didn’t anticipate certain attack scenarios at all.

Niche Vault: Not the Fort Knox just yet

The third application is Niche Vault, a platform that lets hobbyists log, browse, and share items from their personal collections, complete with individual profile pages. 

On the administrative side, it includes full user management capabilities, such as deleting, suspending, or banning accounts, along with basic analytics and the ability to publish site-wide announcements.

For this project, I placed a strong emphasis on security from the outset. 

I instructed the AI to strictly adhere to OWASP WSTG guidelines and OWASP best practices, ensuring that every feature was analyzed for potential attack vectors and that appropriate mitigations were implemented from the outset. In addition, every piece of generated code was required to undergo a second security review by AI again.

<web_application> A minimal web application designed for hobbyists to log, manage, view, and share items from their personal collections, such as vinyl records, comics, or similar collectibles. </web_application>

…web application features…

<security – HIGH priority> Security is the highest priority. Ensure that every component and feature is implemented securely and cannot be abused. Apply OWASP Web Security Testing Guide (WSTG) methodologies throughout the development process, and explicitly consider the OWASP Top 10 vulnerabilities to ensure the application is thoroughly protected by applying every best practice defense mechanism for each request, feature, functionality, and more. </security – HIGH priority>

This time, the AI generated a web application using Python (although I had to manually fix the code in several places) with the following tech stack:

The following image shows the generated web application with its functionalities implemented.

User input was well protected across the board, and the application even included safeguards against SSTI attacks, which is especially important given its use of Jinja2. Both authentication and authorization were implemented cleanly and thoughtfully.

The application was not without flaws. One notable issue appeared in the CSV export feature, where it was possible to inject malicious payloads that could be executed by Excel or LibreOffice. 

As shown in the image below, the relevant code lacks any form of input sanitization, leaving it vulnerable to CSV injection attacks.

As a result, an attacker can embed a malicious payload. In this example, a calculator application was executed; however, real-world attacks may involve reverse shell payloads that grant remote access to the victim’s desktop or download and execute malware.

As shown in the image below, the payload is evaluated when the CSV file is opened, causing the calculator process to be launched.

In addition to the glaring CSV injection vulnerability, several critical endpoints lacked rate-limiting controls. 

While the AI correctly implemented rate limiting for the registration and login endpoints, it failed to apply similar protections to the following endpoints, which attackers could exploit to perform potential denial-of-service (DoS) attacks as well as destructive behavior.

Additionally, the code contained a minor open redirect vulnerability, which could be exploited in phishing attack scenarios where an attacker can supply a malicious domain to the next URL argument.

In conclusion, even when provided with a highly detailed prompt that explicitly instructs the AI to generate secure code, it is still likely to fall short in other areas or to overlook security considerations in certain features altogether.

Without precise, feature-specific security requirements, the AI tends to leave parts of the application insufficiently protected. 

As demonstrated in this example, it successfully sanitized input fields, prevented SQL injection, and applied several other best practices, yet still failed to implement comprehensive, end-to-end security. 

Ultimately, these gaps resulted in additional vulnerabilities despite the overall focus on secure development.

The secret tokens predictability game

While generating multiple web applications, I noticed a recurring pattern: AI models frequently produce “secret” tokens and keys that follow similar structures and wording. 

This observation told me to take a deeper look into how predictable these generated secrets can be.

For example, when further creating even simpler web applications, the following tokens were generated in docker-compose and other configurational files:

While these values may not appear in common brute-force wordlists (such as those targeting JWT secrets and other), they are not cryptographically secure and I could potentially see them being used.

Overall, this demonstrates a plausible attacker strategy: using multiple AI models to generate and aggregate common secret placeholders, then testing them against large numbers of similarly generated applications.

The verdict

Bottom line is:

Vibe coding is only as secure as the vibe coder’s understanding of potential vulnerabilities and their ability to instruct the AI to account for them.

When building an application using AI, it is critical to explicitly guide the model on the types of vulnerabilities that may arise in the generated code. 

For instance, if you ask the AI to implement a file-upload feature, you must already provide clear requirements regarding file extensions, MIME-type validation, size limits, and other relevant mitigations.

The broader issue is that even the most detailed prompts do not guarantee secure output. AI can still generate insecure code or introduce subtle loopholes in unexpected places, and create critical business logic issues. 

For this reason, it is highly recommended to conduct real-world penetration testing, in which security professionals review both the code and the application’s runtime behavior to identify and mitigate risks before they become exploitable.

Explore our cybersecurity services — from penetration testing to security architecture — and partner with experts who can identify risks before they become exploitable.

If you haven’t kept up with AI tooling discussions, you may have missed OpenClaw (formerly Moltbot and Clawdbot). Marketed as “The AI that actually does things,” it acts as your personal AI assistant that can clear your inbox, send emails, manage your calendar, and even check you in for flights. It also acts out – to say the least.

What sets Moltbot apart from cloud-only assistants is its deep integration with applications already running on your system, such as WhatsApp, Telegram, Slack, and Discord. It interacts directly with your operating system to manage everyday tasks, bringing AI assistance into your local workflow rather than keeping it locked behind a web interface.

However, from a security standpoint, this level of access is bordering on a worst-case scenario. This is the same principle we found in our experiment on AI-generated code security risks — AI systems don’t fail because they lack capability, they fail because they make incorrect assumptions about trust.

The developers are transparent about the dangers. Moltbot’s installer explicitly outlines its extensive capabilities and describes the system as “inherently risky“. While this transparency is commendable, it highlights the unusually broad level of access the AI operates with.

During onboarding, the system prompts you to enable “skills,” which are essentially permission scopes granting the bot access to local applications and external services. Some of these are highly sensitive:

After installation, Moltbot exposes a local web dashboard running on port 18789 by default. This serves as the primary control panel for managing the bot’s capabilities.

The critical issue is that there is no authentication mechanism in place. If this dashboard is exposed to the internet, any unauthenticated user can interact with the underlying operating system and connected services.

This is not a hypothetical risk. A simple Censys query reveals more than 1,500 publicly exposed, unauthenticated Clawdbot instances. These real-world deployments grant unrestricted access to anyone who stumbles across them.

As for the chatbot itself, it delivers exactly what is promised: it can reliably execute system commands.

The bot does have some built-in safety measures; by default, it will refuse to execute suspicious commands like reading the .env file that contains API keys.

However, these guardrails are easily bypassed. While prompt injection is a known threat, the simplest way to extract this sensitive data is to ask the bot to list environment variables. This can immediately leak the OPENAI_API_KEY and other critical credentials that are used and configured.

The viral popularity of the tool has also attracted bad actors. One reported case involved a fake Visual Studio Code extension posing as a “ClawdBot Agent“. While it looked like a legitimate installer, it was actually secretly installing credential stealer on user’s systems.

Source: https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-malware

Specific Tips Moltbot/Clawdbot Users:

While AI agents are highly effective for automation, they also introduce significant risks — especially when built without proper security design from the start. If you’re building agents for your business rather than experimenting with third-party tools, see how we approach AI agent development with security and governance built in. To keep your data and devices safe in the meantime, follow these best practices:

Given the rise of lookalike installers and “agent” add-ons, verify sources rigorously before installing anything.

AI agents are here to stay, but until secure-by-default practices (authentication, least privilege, hardened networking, and auditable controls) become standard, the safest mindset is simple: If it can operate on your system, it can compromise it.