How Sable Found a SQL Injection in a Legacy Financial Portal

Daniel Knight, CEO at Vulnetic

A customer recently ran Sable against the public-facing surface of a legacy financial services environment. Sable expanded beyond the main application, enumerated older paths, and uncovered a forgotten assistance portal that had fallen out of focus. Within it, the agent reached a password recovery workflow and identified a SQL injection vulnerability buried in legacy functionality that had likely gone untested for years.

Baseline and Differential Testing

Once Sable reached the recovery flow, it started probing the input surface the way a good operator would. Normal submissions returned a standard identity verification failure. That established a baseline. From there, Sable moved into controlled differential testing on the last-name field to determine whether the backend was safely handling input or whether something deeper was happening behind the page.

That is where the behavior changed. In the trace, the line to notice is [sqli-lastname-or], which returned Your password hint is .Click here to continue. instead of the baseline verification failure shown in [baseline-normal]. That was the first signal that the request logic could be influenced from the input. Sable then escalated carefully. The [sqli-lastname-union] line returned Your password hint is 1.Click here to continue., showing that attacker-controlled output could be injected into the application response. At that point, this was no longer a suspicious edge case or a reflected-input artifact. The application was clearly executing backend query logic influenced by user input.

Confirming the Injection

Sable did not stop at one changed response. It verified the finding the right way. After confirming union-based behavior, it extracted backend metadata through the same vulnerable response path.

The application disclosed live database-derived values back into the page, confirming that the injection was real and that the backend could be queried through the vulnerable parameter.

To close the loop, Sable tested stacked-query execution with WAITFOR DELAY. The result was clean. Delay payloads introduced the expected response timing differences over normal baseline requests, proving that the backend was not only injectable, but that the injection had meaningful execution capability inside the SQL engine. That is the point where an interesting anomaly becomes a real SQL injection finding.

Why This Matters

Offensive AI is no longer theoretical. Agents like Sable are already enumerating forgotten paths, running differential tests, and chaining findings into full exploitation with minimal human steering. A workflow like this assistance portal would take a human tester hours of patient probing to find. Sable did it autonomously, and anyone can rent that same class of capability.

That is why waiting is the wrong posture. If autonomous agents can reach a forgotten password recovery flow and confirm database-owner access through it, that capability already exists on the offensive side whether your team has adopted it or not. Annual engagements and quarterly scans were built for a slower threat model.

Bringing these capabilities in-house closes the gap. Running an agent like Sable against your own environment, continuously and across the full external footprint, gives you the same signal an attacker would get, on your timeline, before it becomes an incident. The teams that adopt offensive AI internally will find their forgotten assistance portals first. The ones that don’t will find out the other way.

Learn more about Sable

Book a demo