Case studies.

In the sitewide notification settings, a surface meant for administrators. An access-control gap left the endpoint behind it answering ordinary logged-in accounts, and whatever was stored there rendered for every user who loaded the site. Neither weakness is remarkable on its own. The reach is what made the second one matter.

Our AI reached the notification settings from an ordinary customer account, stored script there, and confirmed it executed for other users of the site rather than only for the account that saved it. With a staff session running that script, the chain continued to administrative control of the store application.

Two weaknesses, neither decisive alone. Chained, total compromise.

Two checks, not one. Enforce the administrator requirement on the endpoint behind the notification settings, and escape stored notification content where it renders. We showed the exact handler for each, the fix, and steps a developer can replay in five minutes to watch the chain break.

Authentication was enforced on every request. Whether the record you asked for is yours is a second, separate check - and it is the one automated scanning is least able to see.

Our AI signed up as a new tenant, then requested a record belonging to another. It came back in full. We confirmed it from two accounts.

A broken access control flaw, also called IDOR.

Before the app hands over a record, confirm it belongs to the account asking. We showed where that check belongs, with a re-test a developer can run on every release.

The one-time code travelled on the sign-in request as well as by email. When a value is supplied and verified on the same side, the verification stops being one.

Our AI put its own code on the request and told the app it was correct. It logged us in as another user, with no password and no access to their inbox.

An account takeover, with no credentials at all.

We pointed to the exact field the server must stop trusting, explained why it was reachable, and handed over a five-minute test to confirm the door was shut.

Admin-only features were taken off the menu for ordinary users. A request does not read the menu - it addresses the endpoint directly, and that is where the same decision has to be made a second time.

Our AI signed in as an ordinary user, worked out what that account was meant to be able to do, then asked the app to run the admin-only actions anyway. It ran them: adding and removing users, changing settings, privileged actions, all from an ordinary account.

A broken function-level authorization flaw, also called BFLA.

We listed every admin action that answered a normal user, the one check each of them was missing, and the single place to enforce it for all of them, with a re-test a developer can run on every release.

The form displayed two fields. The endpoint behind it accepted whatever the request carried, including one it never displayed: the field that decides whether an account is an administrator.

Our AI saved its own profile the normal way, with one extra field attached. Before the save, the admin pages turned it away. After the save, they opened. Same account, same button, nothing in between but an edit to its own profile.

A mass-assignment flaw, ending in full admin access.

We named the exact field the server must stop accepting, the short list of fields it should accept instead, and the before-and-after steps a developer can replay in five minutes to watch the escalation close.

Not in the application. One layer below it, in the PHP interpreter that runs every request. The flaws needed no bug in the code, no vulnerable plugin and no misconfiguration, and an ordinary file-upload request was enough to reach them. Scanning the application would never have surfaced this, because nothing in the application was wrong.

Code execution on the web server, with no login and no user interaction. A crafted upload pushes the interpreter into a memory error part way through a request, and the cleanup that follows acts on memory that is no longer valid. From there an attacker runs commands as the web server account, which reaches the application, its configuration and its database credentials.

PHP2Shell: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 of 10.

Update the interpreter on every host, restart every worker, then confirm which binary the web server actually loaded, because a package can update cleanly while the old one keeps serving traffic. Updating was the only complete fix: every workaround published that week closed one path and left the weakness open. Then review the window before the patch, because updating stops the next attempt and says nothing about the previous one.