13 May 2026 Threats

Criminals Used AI to Build the World's First Zero-Day 2FA Bypass — What Australian Businesses Must Know

On 11 May 2026, Google's Threat Intelligence Group confirmed the first documented case of criminals using an AI model to write a working zero-day exploit — a Python script designed to bypass two-factor authentication on a widely deployed open-source web administration tool. The campaign was stopped before it reached mass exploitation, but the shift it represents is permanent: AI-assisted exploit development is no longer a theoretical risk for Australian SMBs, it is an operational one.

Disclosure: This post contains affiliate links. We only recommend tools we've researched and trust. If you purchase through our links, we may earn a commission at no extra cost to you.

What Google's Threat Researchers Discovered on 11 May 2026

Google's Threat Intelligence Group (GTIG) published a disclosure on 11 May 2026 documenting the first confirmed case of a criminal group using an artificial intelligence model to develop a working zero-day exploit. The target was a popular open-source web administration tool used by organisations worldwide — including many Australian businesses — to manage servers, databases, and web services. Google has not publicly named the tool, consistent with responsible disclosure practice.

The exploit itself was a Python script designed to bypass two-factor authentication (2FA) for any user who already had valid login credentials. This is an important technical nuance: the flaw did not allow attackers to skip the login step entirely. What it did was neutralise the second factor — the authenticator app code or TOTP token that most users treat as their final line of defence. Once an attacker had a set of stolen credentials (increasingly easy to obtain given the scale of infostealer campaigns targeting Australian networks), 2FA would no longer protect the account.

According to GTIG's analysis, published on the Google Cloud Blog, the criminal group fed the target tool's source code directly to an AI model and instructed it to identify potential logic flaws. The model surfaced a high-level semantic logic error — a hard-coded trust assumption in the 2FA verification pathway — that a developer reviewing the code under normal time pressure might plausibly overlook. This is precisely the kind of subtle, intent-versus-implementation discrepancy that large language models are particularly effective at finding.

The resulting Python exploit carried recognisable hallmarks of AI-generated code: oversized explanatory docstrings, a clean class structure consistent with training-data examples, and — notably — a fabricated CVSS score baked into the comments, a detail no human attacker would include but an LLM might generate when asked to assess severity. These markers allowed Google's researchers to identify the exploit's provenance with confidence, as reported by Bleeping Computer.

Google coordinated with the affected vendor to patch the vulnerability before the campaign could be deployed at scale. The criminal group's stated intent, based on GTIG's assessment, was mass exploitation — systematically targeting every organisation running a vulnerable, internet-exposed instance of the tool. Google's intervention disrupted that plan, but researchers were clear: this incident establishes a template that other threat actors will follow.

Why a 2FA Bypass Is Particularly Dangerous for Australian SMBs

Two-factor authentication has become the single most recommended security control across every major framework — the Essential Eight from the Australian Signals Directorate, CISA guidance in the US, NCSC recommendations in the UK. The reason is simple: even when passwords are stolen, a second factor stops most attackers cold. This incident challenges that assumption in a direct and specific way.

For Australian small businesses, the credential theft risk is already acute. The infostealer campaigns active throughout 2025 and 2026 have harvested passwords at extraordinary scale from compromised devices, phishing pages, and fake software installers. When those credentials are used in account takeover attempts, 2FA has been the reliable backstop that prevented the attempt from succeeding. An AI-discovered flaw that removes that backstop — even in a single widely-used admin tool — represents a meaningful degradation of defence for every organisation running that software.

The risk compounds when you consider the typical administrative tools deployed by Australian SMBs and their hosting providers. Open-source web administration panels are ubiquitous in this segment: they reduce costs, simplify server management, and are routinely deployed by managed service providers across thousands of client systems from a single template. A single unpatched vulnerability in a popular admin tool, exploited via a mass campaign, can simultaneously affect a managed service provider and every client whose server they manage.

There is also an important distinction between the types of 2FA in common use. SMS-based 2FA — where a code is sent to a mobile number — has known weaknesses including SIM-swapping attacks and interception. This is why the ACSC's Essential Eight Maturity Model now requires organisations at Maturity Level 2 and above to use authenticator app-based TOTP or hardware security keys rather than SMS codes. The flaw identified in this incident targeted a software-level logic error in the admin tool's authentication flow, meaning even TOTP-based 2FA could potentially be bypassed if the underlying application code contained the flaw in question.

That is the significance of this incident: it is not about a weakness in the 2FA mechanism itself (SMS vs app vs hardware key), but a weakness in how a specific application implemented its trust logic around 2FA. Defenders cannot simply "upgrade to a better 2FA method" and consider themselves protected. They also need to ensure the software implementing the authentication flow is patched, updated, and not running known-vulnerable versions.

How AI Found the Flaw — and What Makes Semantic Logic Bugs Hard to Catch

The attacker's method: source code as input

The attacker's approach was deceptively straightforward. Open-source software, by definition, publishes its source code publicly. Any threat actor can download the repository, feed it to a capable AI model, and ask: "Find me any logic flaws in the authentication pathway." The AI reads the code not as a compiler does — checking syntax — but more like a security-aware developer: it understands the intent expressed in comments and function names, then compares that intent against what the code actually does.

In this case, the AI identified a hard-coded trust assumption: a condition somewhere in the 2FA verification flow that the original developer had written to handle an edge case — perhaps a fallback path for API integrations, a legacy compatibility mode, or a test fixture that was never removed from production code — but which, under specific conditions, allowed authentication to proceed without completing the second factor check. This category of flaw is called a semantic logic vulnerability. The code is syntactically correct, passes linting, and is unlikely to trigger automated security scanning tools that look for known vulnerability patterns. It requires understanding what the code should do and identifying where the implementation diverges from that intent.

Why LLMs are effective at finding semantic logic bugs

Large language models process code in a fundamentally different way from static analysis tools. Where a traditional scanner checks code against a database of known-bad patterns (SQL injection patterns, unsafe function calls, known CVE signatures), an LLM applies probabilistic reasoning about intent. It can read a block of code and infer, based on its training, that a particular condition should not be reachable in a secure authentication flow — then flag the specific line where that unreachable condition is, in fact, reachable.

This capability is genuinely useful for security research. Bug bounty hunters and penetration testers use AI models to accelerate code review. Red teams use them to find attack surface in codebases they have limited time to review manually. Google itself uses AI-assisted analysis in Project Zero and other internal research programmes. The issue is that this capability is equally available to criminal threat actors, and the barrier to entry is low: an API subscription and a public repository are all that is required.

The AI code markers GTIG identified

GTIG researchers identified the AI-generated nature of the exploit through several consistent characteristics. The Python script contained unusually detailed docstrings — comment blocks that explained each class and function as though the author were writing tutorial material rather than a production tool. The class structure followed a textbook, highly regularised pattern consistent with code produced from LLM training data. Most tellingly, the script included a CVSS severity score in its comments — a piece of information no human attacker would think to include, but which an AI model asked to "assess the vulnerability severity" would naturally generate as part of its output. These markers, taken together, gave Google's analysts high confidence that AI had written the exploit rather than adapted it from an existing public proof-of-concept.

Five Steps Australian Organisations Must Take Now

The vendor affected by this specific vulnerability has been patched — Google coordinated the fix before the campaign launched. But the incident surfaces several actions that are relevant regardless of which specific tool was involved, because this method of attack will be repeated against other software targets.

1. Audit your open-source admin tools and apply updates

Identify every open-source web administration tool running in your environment. This includes database management interfaces, server control panels, container orchestration dashboards, and any browser-accessible tool that manages infrastructure or application configuration. Check the version running against the vendor's current release. If you are not on the latest release, update. If you cannot update immediately — because of a compatibility constraint or a managed hosting provider's release schedule — consider whether the tool needs to be internet-accessible at all until the update is applied.

2. Restrict admin panel access to trusted networks only

This is the most effective single control for admin tool exposure: never allow public internet access to an administrative interface. Use IP allowlisting to restrict access to your office's static IP addresses, or require staff to connect through a VPN tunnel before the admin panel is reachable. Many Australian SMBs run admin panels on default configurations that are accessible to the entire internet — this is the condition that mass exploitation campaigns depend on. Removing public accessibility reduces your attack surface regardless of whether a specific vulnerability is patched.

3. Upgrade from SMS-based 2FA to TOTP or hardware security keys

The ACSC's Essential Eight Maturity Model requires organisations at Maturity Level 2 and above to use multi-factor authentication that is resistant to phishing and interception. SMS-based 2FA does not meet this requirement. The preferred methods are TOTP authenticator apps (Google Authenticator, Microsoft Authenticator, Authy) and hardware security keys (YubiKey and equivalents). If your organisation still relies on SMS codes for admin account access, this incident is a prompt to upgrade.

4. Subscribe to vendor security advisories

Most open-source projects publish security advisories through GitHub's security advisory mechanism or a dedicated mailing list. Subscribe to advisories for every open-source tool in your environment. When a critical update is released, you need to hear about it within hours, not discover it weeks later during a routine update cycle. The Australian Cyber Security Centre also publishes alerts at cyber.gov.au/alerts — subscribing to their alert RSS feed or email notifications is free and directly relevant to the Australian threat context.

5. Apply the principle of least privilege to admin accounts

Admin tool accounts should be separate from day-to-day user accounts, scoped to the minimum permissions required, and audited regularly. If an attacker does bypass authentication — whether through a logic flaw, a stolen credential set, or any other mechanism — a least-privilege account limits what they can do once inside. Shared admin credentials that have never been rotated, and accounts with superuser permissions on every system in the environment, are a routine finding in incident response engagements following breaches of Australian SMBs.

The Bigger Picture: AI-Augmented Threats Are Already Operational

GTIG's May 2026 report placed the 2FA bypass exploit in a broader context. AI is being used by criminal threat actors across multiple stages of the attack lifecycle — not just for exploit development. The Google Cloud Blog report documented AI-assisted reconnaissance, AI-accelerated social engineering, and self-morphing malware designed to evade signature detection as separate active threat categories observed in early 2026. The 2FA bypass zero-day is the most technically sophisticated example, but it is part of a pattern rather than an isolated incident.

For Australian businesses, the practical implication is a compression in the time between public vulnerability disclosure and active exploitation. When human researchers find a flaw, it typically takes days or weeks for a working exploit to be developed and weaponised. When AI can accelerate the code-analysis phase from weeks to hours, that window narrows. The Essential Eight patch management guidance already requires critical patches within 48 hours for Maturity Level 3 organisations — this incident reinforces why that timeline exists.

What ACSC guidance says about MFA and AI-augmented threats

The ACSC's multi-factor authentication guidance for small businesses explicitly recommends against SMS-based 2FA and provides implementation steps for authenticator apps and hardware keys. The ACSC has published simplified guides for small businesses and individuals, recognising that this audience is disproportionately targeted and underresourced.

The Essential Eight Maturity Model positions MFA as one of eight foundational controls because it delivers substantial security uplift at relatively low implementation cost. At Maturity Level 1 — the baseline recommended for most Australian SMBs — MFA is required for remote access, privileged accounts, and internet-facing services. This incident is a concrete illustration of what happens when that control is circumvented.

Legal obligations if an admin tool is compromised

Under Australia's Privacy Act 1988 and the Notifiable Data Breaches (NDB) scheme administered by the Office of the Australian Information Commissioner (OAIC), organisations holding personal information about Australians must notify the OAIC and affected individuals when a breach is likely to result in serious harm. A compromised admin tool granting access to customer records or financial information almost certainly triggers this obligation, with a notification window of 30 days from the point the organisation becomes aware.

The cost of upgrading 2FA, restricting admin panel access, and applying patches is orders of magnitude lower than the cost of breach notification and reputational damage. Google's intervention stopped this specific campaign before it caused harm. The next one using this method may not be caught in time.