Broken access control is considered a blind spot of AI-generated code. Startup VulX presents a deterministic verification mechanism that doesn’t just suspect vulnerabilities but proves them — and rejects unproven findings just as rigorously.
Code is now written faster than it can be reviewed. One vulnerability class benefits least from that speed: broken authorization, also known as Broken Object-Level Authorization (BOLA) or IDOR, which barely lends itself to automated detection.
The London-based company VulX Ltd has published a technical whitepaper describing a new approach to a vulnerability class that is notoriously hard to catch with automated tooling: broken authorization. Rather than relying on a language model’s own assessment, the paper describes a deterministic “exploit oracle” that verifies suspected vulnerabilities experimentally instead of simply accepting a model’s claim.
According to the company, the core of the problem is that authorization is not a syntactic property that a conventional pattern-matching scanner can detect — it is a property of an application’s intended access policy. This is precisely where AI code generators tend to fail most often, the paper by founder Minh Danh Ngo argues: a language model produces a working database query but silently omits the check confirming that the requesting user actually owns the data being retrieved.
As evidence of real-world relevance, the whitepaper points to CVE-2025-48757, a vulnerability affecting applications built with the AI tool Lovable. According to the cited analysis, 170 of 1,645 examined projects (10.3 percent) were affected, with 303 vulnerable endpoints and a CVSS score of 9.3.
At the heart of the system VulX presents is a deterministic exploit oracle. Instead of trusting a language model that merely considers a vulnerability plausible, a fixed rule checks three measurements: whether an attack actually succeeds before a patch, whether it no longer succeeds afterward, and whether a legitimate request still succeeds — the so-called negative control. Only when all three conditions are met is a finding classified as confirmed and shipped. According to the description, the language model itself never renders the final verdict.
According to the whitepaper, the approach was tested against eleven real, publicly available applications. The oracle confirmed six authorization vulnerabilities and declined five further findings, for three distinct reasons: unreproducible impact, no way to establish a control measurement, and target systems that could not be technically stood up. Only one of the six confirmed vulnerabilities was discovered fully autonomously by the system itself; the other five were tested against hand-fed attack scenarios. As a purely deterministic detection layer — without any language-model judgment — a separate component correctly located five of the six confirmed vulnerabilities at high confidence (at least 0.7), the paper states.
For comparison, VulX ran the established analysis tools Semgrep and CodeQL. According to the tests documented in the whitepaper, neither tool flagged a single one of the five reviewed, confirmed authorization vulnerabilities — a result the authors cite as evidence that this vulnerability class sits structurally outside the reach of conventional static analysis.
The language model used for constructing the attacks was, according to the company, the hosted model Claude Opus 4.8 — explicitly not a model trained by VulX itself. The cost per verified case is said to be roughly $0.065 to $0.11.
The company itself acknowledges clear limitations in a dedicated section on scope and honesty: the sample is small, the method is at an early stage, and on real applications the applied fixes to date are reference patches rather than autonomously generated corrections. A fully autonomous fix capability is explicitly not yet part of the product, the paper states, but is planned for the future. Also unresolved, according to the whitepaper, is the problem of database configurations managed outside the code repository — for three of the eleven test applications, no working test environment could be built for this reason.
For security leaders at companies increasingly relying on AI-generated code, the whitepaper primarily offers a diagnosis: automated code generation intensifies a risk for which conventional scanning tools so far offer no reliable answer. Whether VulX’s proposed proof-based, deterministic verification mechanism holds up at scale remains to be seen, given the still-small sample size and the early development stage the company itself acknowledges.
Beyond simple confirmation, the whitepaper places particular emphasis on the cases where the system deliberately rejects a finding. In one documented example, the oracle did detect a genuine authorization flaw in a sharing feature, but could not measurably prove the resulting data leak — the cause, according to the analysis, was a misconfigured database policy that unintentionally blocked the actual attack path. Rather than reporting the apparent vulnerability anyway, the system explicitly rejected it as not reproducible. It is precisely this refusal logic, the authors argue, that distinguishes the approach from purely language-model-based verification methods, which tend to report plausible but unproven findings as real.
Dr. Jakob Jung is Editor-in-Chief of Security Storage and Channel Germany. He has been working in IT journalism for more than 20 years. His career includes Computer Reseller News, Heise Resale, Informationweek, Techtarget (storage and data center) and ChannelBiz. He also freelances for numerous IT publications, including Computerwoche, Channelpartner, IT-Business, Storage-Insider and ZDnet. His main topics are channel, storage, security, data center, ERP and CRM.
Contact via Mail: jakob.jung@security-storage-und-channel-germany.de