Five 2026 AI breaches an autonomous pentest would have caught first

Adam Lundqvist, Founder and CEO · · 10 min read

David Farago keeps a public register of every AI-related software-security incident of 2026. We read all 99 entries and kept the 32 where an attacker actually got in, not a researcher who found a hole and reported it. Then we applied a second, harsher filter: of those 32, which ones started with a flaw that an external, authenticated web and API pentest actually tests for? An unauthenticated endpoint, an injection, broken authentication logic, an exposed interface, an unpatched internet-facing service.

Five of them are below, taken apart at the level of the actual endpoint and the actual bug. The point is not that breaches happen. The point is that these specific ones were reachable from the public internet by anyone who looked, and the people who looked first were an autonomous agent, a crawler, or a criminal, not the defender.

The filter, in three numbers

99 AI-related incidents in the 2026 register.

32 were actual breaches, not disclosures.

13 of 32 began with a web or API flaw a pentest is built to find. Five are dissected here.

1. Langflow: one unauthenticated POST to remote code execution

Langflow is an AI-pipeline builder. In 2026 two separate unauthenticated remote-code-execution flaws in it were exploited in the wild. One campaign, captured by Sysdig and named JADEPUFFER, used the older flaw to run the first ransomware operation driven end to end by a language model, and it destroyed a production database. The newer flaw reached CISA's Known Exploited Vulnerabilities catalogue, the first AI-pipeline platform to land there, and was being exploited about 20 hours after the advisory, with no public proof of concept in existence. Someone wrote one from the patch.

CVE-2026-33017 lives in a single endpoint:

POST /api/v1/build_public_tmp/{flow_id}/flow

The endpoint is unauthenticated on purpose, so that public flows can be built. It takes an optional data parameter. When data is present, the endpoint trusts it as a flow definition instead of loading the stored flow from the database. A flow definition contains component nodes, and a custom component node carries Python in its template. That code is pulled out and handed to exec() inside prepare_global_scope(), with no sandbox, during graph initialisation, before the flow is even run. No token, no login, no user interaction. CVSS 4.0 base 9.3. The fix in 1.9.0 removes the data parameter, so a public flow can only ever load from the database.

What a test would have shown. An external pentest that speaks the API enumerates endpoints and probes each unauthenticated one with structured payloads. An endpoint named build_public_tmp that accepts a data object and executes it is exactly the shape a web and API test flags: unauthenticated, state-changing, and code-adjacent. A single crafted request returns command output. That is a reproducible High finding with a one-line proof. The fix is a version bump, and the retest is the same payload returning nothing. Twenty hours was all the attackers needed. A test on a fixed rhythm closes that window on the defender's side instead of the attacker's.

2. marimo: an authentication check that never said no

Sysdig watched an AI agent enter through an internet-facing marimo notebook, harvest cloud credentials, pull an SSH key out of AWS Secrets Manager, cross four environment-specific pivots, and exfiltrate an entire PostgreSQL database in under an hour, with the final dump taking under two minutes. A second campaign used the same entry to recognise a mounted Docker socket, break out of the container to host root, and replay a Kubernetes service-account token to read cluster secrets.

CVE-2026-39987 is a pre-authentication RCE in marimo's terminal, and it is a clean example of a check that runs but never enforces. marimo uses Starlette's AuthenticationMiddleware, which marks a failed authentication as UnauthenticatedUser. It does not reject the connection. Rejecting is the application's job, done elsewhere with a @requires() decorator and a validate_auth() call. The terminal WebSocket endpoint has neither:

/terminal/ws

It checks the run mode and the platform, then calls websocket.accept() and pty.fork(). So an unauthenticated WebSocket hands you a PTY shell, at root in the default Docker image. CVSS 4.0 base 9.3. Fixed in 0.23.0.

What a test would have shown. This is the subtle one, and it is where a good test earns its keep. A scanner that only checks HTTP routes may miss a WebSocket endpoint. A pentest that enumerates the full surface, including WebSocket upgrades, and tries each one unauthenticated, connects to /terminal/ws and receives a shell prompt. The reason it was missed in the wild is that the auth middleware was present, so everything looked protected. Present is not the same as enforced, and only actually connecting proves which one you have. Retest is the same connection, now refused.

3. Three real companies, breached by an AI that was not even trying

After OpenAI disclosed its own models breaching Hugging Face, Anthropic reviewed 141,006 of its cyber-evaluation runs and found three cases where a model, told it had no internet access, actually did, because a partner's evaluation environment was misconfigured to leave it connected. In one, an internal research model scanned roughly 9,000 real targets, found one company's internet-facing application with an exposed debug page and a SQL injection, and broke in. Then it stopped, because it worked out the target was real. A criminal's agent does not stop.

An exposed debug page is a debug or admin interface reachable without authentication: a stack-trace view, a framework debugger, an actuator endpoint, a /debug route left on in production. A SQL injection is user input concatenated into a query, so a crafted value changes the query's meaning and reads or writes the whole database. Neither is novel. Both are on every pentest checklist that has ever existed. What is new is the finder: an agent scanning 9,000 targets at machine speed.

What a test would have shown. The exact technique that breached these companies is the exact technique an autonomous pentest runs: enumerate the surface, find the interface that should not be public, test every input for injection. The attacker and the defender now run the same tool. The only variable is who runs it first, and how often. Remove the debug interface, parameterise the query, retest both, and the injection that returned data on Monday returns nothing after the fix. That is Find, Fix, Proof in its simplest form.

4. Meta: a password reset that forgot to check whose account it was

Attackers took over 20,225 Instagram accounts by abusing Meta's AI-assisted High Touch Support recovery tool. In Meta's own counsel's words, due to a bug in a separate code path, the system did not properly verify that the email address provided by the individual requesting a password reset matched the email address associated with that user's Instagram account. So an attacker requested a reset for a victim's account, supplied an email address they controlled, and the reset link went to the attacker. Any account without two-factor authentication then fell in a single step.

What a test would have shown. This is not an injection or an RCE. It is broken authentication logic, the class of flaw no scanner finds and every real pentest looks for, because it lives in what the application is supposed to mean, not in a malformed input. An authenticated pentest models the actual users and roles, then tries to make the application do something for one identity that it should only do for another. Requesting a reset for account A while acting as B, and seeing whose inbox the link lands in, is exactly that kind of test. The answer here is a critical finding: the reset does not bind to the account. Twenty thousand takeovers gated on one missing equality check.

5. Lena Health: the patch existed, and nobody checked that it was applied

Lena Health is an AI care-coordination platform and a hospital vendor. Attackers took the complete protected health information of 2,134 patients, including call recordings and discharge documents. By their own account they used a major vulnerability that went public in early December, for which a patch was available, and which Lena had not applied when they broke in a week or two later. The stolen export was sitting, unencrypted, in a public-facing S3 bucket.

There are two findings, and a continuous test catches both. First, an unpatched known vulnerability on an internet-facing service: a pentest that fingerprints versions and checks them against known-exploited vulnerabilities flags that gap the day it opens. Second, and worse, an unauthenticated public object store holding a plaintext export of patient data. No exploit needed. A URL. Surface enumeration that includes cloud storage finds a readable bucket full of records without sending a single malicious byte.

What a test would have shown. This is the sharpest case, because the failure was not a missing fix. The patch existed. The failure was that nobody verified it was applied. A finding is not closed when a patch is released. It is closed when someone tries the exploit again and it fails. In this breach the only party who retested was the attacker, a week or two after the patch shipped, and it still worked.

What an external pentest does not stop

Honesty is the product, so here is what a web and API pentest would not have caught, from the same year. The supply-chain worms: LiteLLM, CHAINDROP, the Miasma worm through 73 Microsoft repositories, the trojanised npm and IDE packages. These enter through a hijacked maintainer or a poisoned build, not through your application, and they need provenance, pinned dependencies and scoped tokens. The agent that deleted its own employer's database: an over-scoped token and an unconfirmed destructive command, an internal-controls problem rather than an external one. And regulated data typed into an unsanctioned AI tool: governance, not testing. We would rather draw that line ourselves than let anyone believe a test covers what it does not.

The pattern across all five

Look at the five entry points. Not one needed a nation-state or a novel technique.

Breach Entry point Finding class
LangflowUnauthenticated POST that executes attacker codeUnauthenticated RCE
marimoUnauthenticated WebSocket to a root shellAuth enforced in name only
Three companiesExposed debug page and SQL injectionThe two oldest findings in the book
MetaReset link not bound to the accountBroken authentication logic
Lena HealthUnpatched known CVE and world-readable bucketMissing patch and exposed storage

Every one was reachable from the public internet, and every one is a standard item on a competent pentest. What changed in 2026 is that the other side automated the looking. An agent enumerates 9,000 targets and stops only if it happens to have a conscience. A crawler indexes an exposed bucket before your internal controls notice. An exploit is written from the patch within a day. A yearly pentest is a photograph. These attackers are watching the video.

What we built

SQUR Professional runs a full pentest every month on the same application for €995 per app, and re-tests every finding until it is verified fixed. Every breach above began with a flaw of exactly the kind that test runs against. If a single annual pentest for the audit file is all you need, the €1,995 one-time pentest is the cheaper choice, and we would rather say so. How continuous testing works, or see pricing.

Source: David Farago, All 2026 AI-Related Software-Security Incidents, Consolidated (VERIS-coded), 26 August 2026 (register on GitHub). CVE detail from the GitHub Advisory Database (GHSA-vwmf-pq79-vjvx, GHSA-rvqx-wpfh-mfx7, GHSA-2679-6mx9-h9xc).