When an AI model capable of finding zero-day vulnerabilities at machine speed gets accessed without authorization, the incident response has to match the threat profile. Anthropic’s handling of the Mythos breach is a useful case study of where disclosure practices for security breaches still need to catch up.

Anthropic built Claude Mythos Preview as something it explicitly said the world wasn’t ready for. 

The model finds zero-day vulnerabilities at machine speed, demonstrated the ability to escape its own sandbox, and in at least one test, posted details of its own exploit to public websites without being asked. 

We’ve already covered how Anthropic’s response was to keep it locked behind Project Glasswing – a tightly controlled initiative limited to a handful of vetted partners: AWS, Microsoft, Cisco, major banks, and critical infrastructure operators.

But exactly that is what makes what happened instructive.

Reports emerged this week that an unauthorized group accessed Mythos Preview through a third-party vendor environment connected to the rollout.

The group – part of a private Discord community that tracks unreleased AI models gained access on the same day Anthropic announced the model.

This mechanism of access is worth sitting with. 

Supply chain security is no longer a background concern for procurement teams. It is a front-line risk for anyone deploying AI in environments that touch source code, internal systems, or critical infrastructure. 

Anthropic just launched Project Glasswing – a major initiative to hunt vulnerabilities in critical open-source software using its most capable AI model. The implications for defenders and attackers alike are significant, and most organisations are not ready for either.

On 7 April 2026, Anthropic launched Project Glasswing – a coordinated effort to give key technology providers early access to Claude Mythos Preview with one goal: find and fix long-hidden vulnerabilities in critical open-source software before attackers do.

It is the clearest signal yet that frontier AI has crossed a threshold. It is no longer just a productivity tool bolted onto existing security workflows.

That is worth taking seriously. Not because of the marketing, but because credible institutions are paying attention.

The AI Security Institute and the UK National Cyber Security Centre have both documented measurable progress in AI agents completing multi-step cyber attack scenarios. The NCSC has called on defenders to prepare for a world in which frontier AI amplifies attacker capabilities at pace.

Glasswing is a concrete attempt to tilt that balance back toward defence. The early findings suggest it is working.

The two-sided ledger of AI-assisted security

For most of computing history, finding and exploiting software vulnerabilities required rare expertise.

The people who could do it reliably numbered in the thousands globally. That constraint mattered – it was a practical limit on how fast attackers could operate and how broadly they could target. 

Over the past year, that constraint has eroded sharply. 

AI models have become increasingly effective at reading and reasoning about code, showing a particular ability to spot vulnerabilities and work out how to exploit them. The cost, effort, and level of expertise required have all dropped dramatically.

Claude Mythos Preview, Anthropic’s unreleased frontier model behind Glasswing, has reached a level of coding capability where it can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.

That is not a marketing claim – it is the assessment Anthropic has published alongside the initiative. The AISI’s evaluation of Claude Mythos Preview’s cyber capabilities tracks the same capability curve and reaches similar conclusions.

And it is not only expert hands that can wield it.

An AI that can read a codebase, reason about execution paths, and identify edge cases in authentication logic can do that work for a defender running a bug bounty programme or for an attacker building an exploit chain. The model does not care which side of the firewall it is on. And given the rate of AI progress, these capabilities will not remain confined to actors committed to deploying them safely.

The question for security teams is not whether to engage with this shift. It is – how fast.

What Glasswing tells us about where this is heading

Anthropic’s approach with Glasswing is instructive beyond the specific initiative. A few things stand out.

The focus on open-source infrastructure is deliberate

Open-source software underpins almost every critical system in operation today – cloud platforms, financial infrastructure, healthcare systems, industrial controls.

Vulnerabilities in widely used libraries do not stay contained. When one surfaces, the blast radius is enormous and the window between disclosure and exploitation has compressed to hours in many cases. 

The Axios npm supply chain attack in March 2026 – where two malicious versions of one of JavaScript’s most-used libraries were quietly published – is a recent example of exactly how fast that window closes.

The results are concrete 

Mythos Preview has already found thousands of zero-day vulnerabilities –  flaws previously unknown even to the software’s own developers – including some in every major operating system and web browser.

Some of the specific findings illustrate just how significant the capability leap is:

The gap between Mythos Preview and the previous generation of models is also stark.

When tested against known vulnerabilities in Mozilla’s Firefox JavaScript engine, the previous best model – Claude Opus 4.6 – turned those vulnerabilities into working exploits twice out of several hundred attempts. Mythos Preview did it 181 times.

These are not theoretical weaknesses. They are exploitable flaws that survived decades of human review and millions of automated tests. The model found them.

The initiative is coordinated by design 

Early access, structured disclosure, defined scope – Glasswing is built to funnel findings into responsible remediation rather than onto a paste site. 

That framing is worth taking at face value, because the alternative – waiting for these capabilities to proliferate without a coordinated defensive response – is considerably worse.

For organisations watching from the outside, the implication is direct: if a frontier model can find vulnerabilities in your dependencies that survived decades of human review and millions of automated tests, you cannot rely on existing scanning and review processes to give you confidence that your attack surface is clean.

The attacker’s advantage – and how to close it

Defenders have always operated at a structural disadvantage.

The realistic near-term threat is not yet a fully autonomous AI attacker operating without human direction. But it is human attackers using AI to operate faster, at a greater scale, and with less specialised knowledge than was previously required. 

A moderately skilled attacker with access to a capable model can accelerate reconnaissance, generate targeted phishing content, identify patch-gap windows, and synthesise public vulnerability research into working attack chains.

We explored a version of this problem in our analysis of security gaps in vibe-coded applications.

AI-generated code introduces vulnerabilities not because the model is careless but because it optimises for functional correctness, not security depth. An attacker using the same models to probe those applications has a natural advantage over a developer who did not think adversarially when prompting.

The answer is not to avoid AI in development.

It is to apply deliberate security discipline at every stage – including to the AI-generated output itself. That means combining automated scanning with human-led testing rather than assuming one replaces the other.

What organisations should do before the surge hits

Glasswing is likely to accelerate vulnerability disclosures across the open-source ecosystem. Organisations that are unprepared for a sudden increase in security advisories affecting their dependencies will struggle to respond at pace.

Martin Walsham, Director of Cybersecurity at AMR Cybersecurity – Part of Infinum, has been tracking this shift closely: “Frontier AI models are progressing at pace, and the same technologies that defenders can use to increase overall security posture can equally be used by attackers to amplify their capabilities. This heightens the need for organisations to implement strong security baselines, defence in depth, and robust secure code, and to patch at pace to make them less susceptible to attacks.”

The precautionary steps below are not dramatic departures from good security hygiene. They are the foundations that make rapid response possible when it is needed.

Review and test your incident response plan now. 

Not the version that was written two years ago and has not been touched since. Run a tabletop exercise against a realistic scenario – a critical CVE in a dependency you cannot patch immediately, combined with active exploitation attempts.

Prepare for increased advisory volume. 

If AI-assisted vulnerability research delivers on its promise, the rate of disclosures in widely used open-source libraries will increase. Security and engineering teams need the capacity to triage and prioritise that volume without dropping everything else. Build that capacity before the surge, not during it.

Get your asset management list accurate. 

You cannot patch what you do not know you are running. This is the most consistent gap we see in organisations that have otherwise mature security programmes. A dependency buried four levels deep in your supply chain is still your problem when a CVE drops against it. Our step-by-step software supply chain security framework covers how to map and manage that exposure systematically.

Monitor updates and advisories actively. 

Subscribe to feeds for the libraries and platforms you depend on. Automated dependency scanning tools have improved significantly – if you are not running one, start.

Review third-party agreements with critical suppliers. 

If a vulnerability surfaces in a service you depend on and your contract does not specify patching SLAs, you have no lever to apply. Review those agreements and open conversations with suppliers about their response posture before you need to have that conversation under pressure.

Test your external perimeter. 

If your last penetration test was more than twelve months ago, you do not have an accurate picture of your exposure. This is especially true for organisations that have made infrastructure changes, onboarded new services, or shipped significant product updates since the last test.

Have a plan for enhanced monitoring at short notice. 

Not all threats give you advance warning. Know what elevated monitoring looks like for your environment and how quickly you can activate it.

Security baselines matter more, not less

There is a temptation to frame AI-powered threats as something categorically new that requires a categorically new response. 

In some respects, that is true – the speed and scale at which AI-assisted attacks can operate does change the calculus. But the vulnerabilities being exploited are mostly the same ones that have always existed: missing input validation, broken access control, insecure defaults, and unpatched dependencies. 

Our cybersecurity trends outlook for 2026 covers how AI-driven attacks, stricter compliance requirements, and supply chain exposure are converging into a single pressure point for security teams.

The NIS2 and DORA frameworks that came into force across the EU reflect this same reality. The technical requirements they mandate – multi-factor authentication, incident reporting, supply chain risk management, regular penetration testing – are not responses to AI-powered threats specifically. They are the baseline hygiene that makes an organisation resilient regardless of what the attacker is using. 

If your organisation is not meeting that baseline, the sophistication of the threat is almost beside the point.

Strong foundations beat reactive firefighting

Project Glasswing is a meaningful development in the responsible use of frontier AI for defence.

The AISI and NCSC assessments confirm what security practitioners have been observing in practice: capability is advancing faster than most organisations have adjusted for.

The right response is not to wait and see how the landscape settles. It is to invest in the defences that reduce exposure across the board – sound architecture, secure development practices, regular testing, and the operational readiness to respond when something goes wrong.

Infinum’s penetration testing and cybersecurity services are built around exactly that kind of proactive posture. If you want to understand your current exposure before the next wave of disclosures hits, talk to our security team.

Most GRC programs fail not because the framework is wrong, but because it’s built to satisfy auditors, not protect businesses. Here’s what that costs you – and how to do it differently.

Most organisations have some version of GRC in place. Policies exist. Compliance boxes get ticked. A risk register lives somewhere in a shared drive, last updated before anyone currently on the team joined. And then a breach happens, or an audit goes badly, and everyone is surprised.

They shouldn’t be.

The most common GRC failure isn’t ignorance of the framework – it’s treating it as an administrative exercise rather than a decision-making system. You end up with documentation that describes security rather than delivers it.

That distinction matters more than most security conversations acknowledge.

Why GRC exists – and why it usually gets implemented wrong

GRC – governance, risk, and compliance – is a system for making security decisions that support a business rather than obstruct it. Not rules imposed from above, but a framework built around what the organisation is actually trying to achieve.

GRC connects governance, risk, and compliance into a single decision-making system. Here’s what each pillar means, how they interact, and how businesses apply them in practice.

Most organizations already manage governance, risk, and compliance in some form – they just do it in separate silos, with different teams, different tools, and no shared language. GRC formalizes that into a single, connected system.

When governance, risk, and compliance operate independently, decisions get made without context.

An IT team patches vulnerabilities without knowing which ones actually threaten business-critical systems. A compliance team checks boxes without understanding the underlying risk. Leadership approves budgets without visibility into what they’re actually protecting.

GRC fixes that – not by adding process overhead, but by aligning security decisions with business goals.

And in an environment where the regulatory landscape keeps expanding, the number of threat vectors keeps growing, and senior leadership is increasingly held personally accountable for security failures, that alignment is no longer optional.

Pen testing and red teaming are often used interchangeably. Both probe your defences. Both find what’s broken. But they ask fundamentally different questions, and the one you choose shapes how wide you assess your business security.

Penetration testing and red teaming both start from the same premise: hire someone to break in before the bad guys do. But they’re different tools for different problems, and conflating them is one of the more common mistakes organisations make.

Two approaches, similar goal

Penetration testing is focused.

You define the scope – a specific application, a network segment, a set of systems – and testers use the penetration testing methodology step by step in an attempt to find and exploit vulnerabilities within it.

Most engagements use a gray box approach: testers are given enough context to work efficiently. Credentials, access, scope. Enough to find what matters within a fixed timeframe.

The approach changes depending on who you are – a red team targeting a bank crafts different phishing emails, chooses different attack vectors, and pursues different objectives than one targeting a logistics company.

The whole exercise is shaped by what real threat actors are actually doing to organisations like yours.

Penetration Testing vs Red Teaming: Key Differences

The simplest way to tell them apart: pen testing answers “is this system secure?”, red teaming answers “could a determined attacker get into our organisation?”

Scope is the biggest practical difference. Pen testing is bounded — a specific application, network segment, or set of APIs. The tester works within those limits, finds what’s exploitable, and reports it. Red teaming has no such boundary. The adversary simulation can move across applications, people, and physical premises, using whatever combination of vectors a real attacker would.

The objectives differ, too. Pen testing produces a list of technical vulnerabilities with severity ratings and remediation steps. Red teaming produces something more like a case study: here is how an attacker targeting your organisation could move from initial access to their end goal, and here is what your people, processes, and technology did, or didn’t do to stop them.

Cost and time reflect this. A pen test might run for a week or two. A red team engagement is typically measured in weeks to months, and requires significantly more planning on both sides.

When Do You Need Pen Testing vs Red Teaming?

Pen testing is right for checking specific systems — after a new build, before a release, or as part of a compliance cycle. TIBER-EU and DORA both require it. If you’re running one annually and after major changes, you’re doing the basics right.

Red teaming is for organisations that have already done the basics. You need mature security processes in place first — incident detection, response playbooks, trained staff — otherwise a red team engagement mostly finds that your foundations are weak, which a pen test would have told you for a fraction of the cost. When that foundation is there, red teaming stress-tests the whole picture: not just whether systems are patched, but whether your people, processes, and assumptions hold up under a realistic attack.

The other factor is the threat model. If you handle sensitive data, operate critical infrastructure, or are the kind of target sophisticated threat actors actively pursue, red teaming answers a question pen testing can’t: not “is this system secure?” but “could a determined adversary get into our organisation?”

If you’re not sure which fits, start with a pen test. And if you want to understand what a red team engagement actually involves, explore our red team services.

Technical depth isn’t enough

The best pen testers and red teamers share two things: deep technical expertise and genuine creativity.

The technical side is obvious – you need to understand how systems behave under pressure, and how to adapt when a vector doesn’t work as expected. But creativity is what separates good from exceptional.

Testing isn’t a checklist. When a system reacts unexpectedly, the question isn’t “what does the tool say next?” – it’s “what does this tell me, and where does it lead?” That kind of thinking can’t be scripted. It has to be developed.

The second half of that matters as much as the first.

A brilliant technical finding is worthless if it can’t be translated into plain language. The job isn’t just to find vulnerabilities – it’s to help the organisation understand what they mean and what to do about them.

Why no scanner replaces this

Our research into AI-generated code security found that automated tools are good at cataloging CVEs, misconfigured headers, and outdated libraries.

They’re fast, they’re consistent, and they’re useful. But they operate on fixed logic. They flag what they’re programmed to flag, and they stop there.

A skilled tester doesn’t stop there.

They notice how a system reacts, chain together findings that no single tool would connect, and pursue lines of attack that require judgment – not just pattern matching.

Nine times out of ten, real attackers get in through people, not ports. A scanner has nothing to say about that. Manual testing does.

This is why organisations that rely on automated tools as their primary security layer end up with a false sense of coverage. The scanner ran clean – but that’s only true for the things the scanner knows how to look for. The cost of finding out too late is well-documented in our breakdown of the real cost of a cyberattack, which shows what’s actually at stake.

Attackers aren’t limited by that constraint.

A vendor with a quiet network connection into your environment, a help desk employee who clicks the wrong attachment – these don’t show up on a dashboard. They show up when it’s too late.

So, the question isn’t whether to test.

It’s whether you’re testing the right things, in the right way, with people who can tell the difference. Automated tools have their place – but they’re a floor, not a ceiling.

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, and the fake ClawdBot VS Code extension we documented earlier this year — all incidents where a trusted-looking package or installer was used to deliver a credential stealer to unsuspecting developers.

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.

For a real-world example of what happens when an AI tool is shipped without any of these guardrails in place — no authentication, broad system access, and easily bypassed safety measures see our security analysis of OpenClaw, the viral AI agent that exposed over 1,500 unauthenticated instances on the public internet within weeks of launch.

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.

The UK Ministry of Defence has officially rolled out Cyber Security Model v4, introducing stricter, more structured cyber security requirements for defence suppliers. Learn how CSM v4, DEFSTAN 05-138, and Defence Cyber Certification fit together and prepare for CSM v4 with a DCC Level 1 certified partner.

The UK Ministry of Defence (MOD) has raised the bar for everyone in its supply chain.

Starting December 3, 2025, all companies working with the MOD – whether a prime contractor, a Tier 2 supplier, or a third-party vendor buried three layers deep – must follow a new set of cyber rules called the Cyber Security Model (CSM v4).

The interim process tied to DEFCON 658 is out. 

In its place? A more structured, standardised framework that holds every supplier and their subcontractors accountable for how they assess, manage, and report cyber risk.

So, what’s changed, and what does compliance actually look like now?

Learn how MOD suppliers can prepare for Cyber Security Model v4 from AMR CyberSecurity – part of Infinum, a Defence Cyber Certification Level 1 certified company.

What is CSM and why does it matter?

The Cyber Security Model (CSM) is the MOD’s framework to make sure every link in its supply chain takes cybersecurity seriously. It’s a risk-based model that applies proportionate security controls based on the nature and sensitivity of the work being delivered.

But this isn’t just about your organisation. Under CSM v4, cyber accountability flows downstream, meaning you’re also responsible for assessing and validating the cyber posture of your subcontractors and third-party vendors. No matter how large or small, one weak link can put an entire contract at risk.

So, what exactly does the MOD expect you to do?

Bottom line: If you want to work with the MOD, you need to take cybersecurity seriously – and be able to prove it.

DEFSTAN 05-138: What the MOD Expects

Building on the CRP levels established during the initial CSM risk assessment, DEFSTAN 05-138 outlines the specific cybersecurity controls that suppliers must meet based on their assigned risk profile.

This MOD standard acts as the benchmark for what’s expected at each level, from basic hygiene to expert-grade defences. The higher the risk, the more comprehensive and stringent the requirements. These controls form the foundation of both the SAQ process and any future DCC certification.

Here’s what each level includes:

It’s important to note that these controls are considered a minimum baseline. 

Depending on the nature of the contract, the MOD may impose additional cyber requirements on top of DEFSTAN 05-138, raising the bar even further for critical or sensitive work.

Enter DCC: Independent certification for defence suppliers

To move beyond self-assessments and strengthen assurance across the defence supply chain, the MOD, together with IASME as the Certification Authority, introduced the Defence Cyber Certification (DCC).

DCC isn’t a full replacement for the Supplier Assurance Questionnaire (SAQ), at least not yet. But it’s clear that the MOD is positioning DCC as the gold standard for demonstrating cyber maturity. 

Over time, it’s expected to become more tightly integrated into the Supplier Cyber Protection Service and potentially reduce the burden of repeated self-reporting.

How it works:

For suppliers working on sensitive contracts, or for the ones hoping to, DCC is quickly becoming table stakes. It’s a proactive way to prove compliance, strengthen your competitive edge in defence tenders, and demonstrate to the MOD that cyber security is not just a policy on paper, but a practice in action.

How can we help

Whether you’re tackling your first Risk Assessment or gearing up for DCC certification,we are here to support you. 

As a Level 1 certified DCC Certification Body, we provide more than just checklists. We’ve partnered with both prime contractors and subcontractors throughout the MOD supply chain, helping defence suppliers navigate CSM v4 from day one – whether you’re assessing your CRP, preparing for DCC, or building a CIP roadmap.As a Level 1-certified DCC Certification Body, AMR CyberSecurity – part of Infinum provides more than just checklists. We’ve partnered with both prime contractors and subcontractors throughout the MOD supply chain, helping defence suppliers navigate CSM v4 from day one – whether you’re assessing your CRP, preparing for DCC, or building a CIP roadmap.

From independent assessments to hands-on consultancy, we tailor our approach to fit your organisation’s needs, so you’re not just compliant, you’re truly cyber-resilient. If you want to discuss your next steps, contact us.From independent assessments to hands-on consultancy, we tailor our approach to fit your organisation’s needs, so you’re not just compliant, you’re truly cyber-resilient. If you want to discuss your next steps, contact us.