Short version
Since 2025, AI has been finding real flaws in long-established software, such as a critical bug in SQLite and one of the PHP vulnerabilities of October 2026. According to Google, the number of reported vulnerabilities per month doubled in 2026, and the number of exploited ones rose sharply too. Attackers use the same AI. An AI scan on its own is not enough: it produces many findings that are wrong or do not matter. In our local security audit, the analysis runs on our own hardware, a person checks every finding, and you get a report with severity and concrete fixes. We only audit with written permission from the owner.
On October 21, 2026, Smartschool, Knack, and DigiD went offline as a precaution because of two flaws in PHP. One of those flaws had been found with an AI model. That is good news for anyone who defends software. It is also bad news, because attackers have the same tools. If you run an online web app with a login, a customer portal, or a connection to other systems, it makes sense to have it audited before someone else finds the gaps.
An AI scan on its own does not solve that. In this article, you’ll learn what an AI security audit is and why the balance is shifting so fast. You’ll also see why you need an expert to check the results, and how our local audit works.
What is an AI security audit?
A security audit is a thorough review of a website or web application for weak spots in its security. You look at the code, the settings, the libraries it uses, and the way users log in and request data. In an AI security audit, an AI model searches through those parts. The model reads far more code than a person can in the same time, and it follows paths through the code that a quick review would miss.
The AI finds possible problems. An expert decides what happens with them. The expert checks whether a finding is real, whether it can be exploited in your web app, and how serious the risk is. Only then does a finding go into the report. That second step is the difference between a long list of warnings and a list you can work through.
Where things often go wrong in practice is listed in the OWASP Top 10:2025, the best-known list of risks for web applications. Broken Access Control is at the top: a user can see or change data they should not have access to. Next come misconfiguration, problems in the software supply chain (third-party libraries and packages), weak cryptography, and injection. A good audit checks those risks for your web app.
Why AI is shifting the balance
For a long time, finding vulnerabilities was manual work. Researchers went through code line by line and wrote custom tools. Daniel Stenberg, the creator of the open source project curl, told Cybernews in June 2026 that it took them weeks to find something. That changed in a short time.
AI finds flaws that people missed
In July 2025, Google reported that its AI agent Big Sleep had found a critical vulnerability in the SQLite database engine (CVE-2025-6965). According to Google, the flaw was known only to threat actors and was at risk of being exploited. Google was able to cut it off beforehand.
Closer to home, the two critical PHP vulnerabilities of October 21, 2026, were also found partly with AI. According to OpenAI, the security firm Calif found one of them with an AI model, while Wiz discovered both on its own. You can read what that meant for WordPress sites in my article on the PHP vulnerability and WordPress.
These are not just a few isolated cases. The Google Threat Intelligence Group counted 5,045 reported vulnerabilities in January 2026 and 10,740 in August 2026: twice as many. What AI finds is also more often serious. Half of the vulnerabilities discovered with AI let an attacker run code remotely. Across reported vulnerabilities in general, that figure is 26%.
Attackers use the same tools
OpenAI says so itself in the same PHP disclosure: AI can uncover flaws with internet-scale impact, but the same capabilities can also help attackers rapidly build attack tools. According to Google, exploitation went up as well: from an average of 10.5 exploited vulnerabilities per month in 2025 to 18 per month in the first eight months of 2026.
IBM X-Force looked at 223 publicly reported vulnerabilities that were discovered with AI. 55.2% were rated high or critical, and 91% were remotely accessible. IBM draws a clear lesson from this: finding flaws is getting easier, and the hard part is shifting to deciding what comes first and fixing it in time.
For the owner of a web app, that means something simple. With AI, finding vulnerabilities goes much faster, for defenders and attackers alike. The only question is who finds the flaw in your web app first.
Why an AI scan without an expert is not enough
Today you can ask an AI model yourself to check your code for vulnerabilities. That quickly produces a long list. The problem is what ends up on that list.
Curl, which has billions of installations, was among the first to feel the effects. Stenberg wrote in January 2026 that the share of real vulnerabilities among incoming reports dropped from more than 15% to below 5% in 2025. Much of the rest were AI-generated reports that did not hold up: invented functions, problems that did not exist, ordinary bugs presented as critical flaws.
Starting 2025, the confirmed-rate plummeted to below 5%. Not even one in twenty was real.
The AI models have improved since then. In the same Cybernews interview, Stenberg said the reports are now more often technically accurate. Still, the heavy lifting stays with people. Someone has to read, understand, and verify every report and judge its severity. According to Stenberg, suggested patches are rarely fully correct: a human still has to step in to fix the bug.
What the expert adds
That is exactly where an expert adds value to your audit. There are three things an AI scan cannot do alone:
- Understand context. A finding about an open admin page is critical on a live online store and harmless on a test server without real data. Someone who knows the web app can tell the difference.
- Set priorities. Ten medium-severity findings are less urgent than one flaw that lets a customer see another customer’s invoices. You want to know what has to happen this week and what can wait.
- Choose a safe fix. A quick patch that closes a hole but breaks the login helps no one. An expert tests the fix in the context of the whole web app.
So an AI scan without review mostly creates work: someone has to go through every finding. In an audit, that review happens before the report, not after.
Security audit, AI scan, or penetration test?
The terms are often mixed up. This table puts the three side by side.
| Aspect | AI scan without review | Security audit with AI and an expert | Penetration test |
|---|---|---|---|
| What it does | A model searches code or a site and reports findings | AI searches, an expert checks and ranks every finding | A tester attacks the web app the way an attacker would |
| Looks at | Whatever you provide | Code, configuration, libraries, and settings | The running web app, from the outside |
| False alarms | Many, unfiltered | Filtered out before the report | Few, everything is tested |
| Severity and priority | Often exaggerated or missing | Per finding, for your situation | Per proven attack path |
| Where your code goes | Often to a cloud AI service | With us: it stays local | Not needed, the test runs from the outside |
| When it makes sense | As a first look by a developer | Before launch, after big changes, periodically | When you need to prove what can be exploited |
A penetration test does not replace an audit, and vice versa. An audit finds weak spots in the code that no attacker has found yet. A penetration test proves what an attacker can do with them today. For most small and mid-sized businesses, an audit is the logical first step.
How our local security audit works
We run the audit locally, on our own hardware. That is a deliberate choice. Your code and data do not go to a cloud AI service, and they never leave our office. That way, you don’t have to choose between a thorough review and keeping your software confidential.
- Permission and agreementsWe only start after written permission from the owner of the web app. Together, we agree on what we check, which environment, and how far we go.
- Local analysis with AIAn AI model on our own hardware searches the code, the configuration, and the libraries for possible vulnerabilities. Nothing is sent to an outside AI service.
- Every finding checkedAn expert reviews every finding: is it real, can it be exploited in your web app, and how serious is it? Findings that do not hold up are dropped.
- Report with severity and fixesYou only get confirmed findings, with the severity, the location in the code, and a concrete recommendation to fix it.
- Fixing it, if you wantYou can apply the fixes yourself or have your own developer do it, or you can leave them to us.
The AI does the searching that would otherwise take days. The expert does what AI is not good at: judging, choosing, and explaining. So you don’t get raw AI output, but a report you can act on. We don’t promise that a web app is “100% secure” after an audit. No one can honestly promise that. What you do get is a clear picture of the risks we found and how to address them.
Only with the owner’s permission
A security audit is not a hack, and the difference is permission. In the Netherlands, breaking into a system without permission is a criminal offense under article 138ab of the Dutch Criminal Code. It is a criminal offense in Belgium too. In February 2023, Belgian lawmakers approved a legal framework for ethical hackers, but it only protects people who strictly follow the procedure of the CCB, the national cybersecurity authority.
That is why we only work for the owner of the web app, or for someone with written authority to decide on the owner’s behalf. If an agency built your web app and another party hosts it, we agree in advance who gives permission for which part. We don’t audit an app that you don’t own.
When should you have your web app audited?
An audit is not a yearly formality. There are moments when it really makes a difference:
- Before you launch a new web app, especially if it handles logins, payments, or personal data.
- After a big change: a new connection to another system through an API, a new customer portal, or a different way to log in.
- If your web app was built quickly with AI tools. An app from Lovable or another AI builder often works right away, but you can’t tell from the outside whether the access rules are right. You can read what else such a site tends to lack in my article on Lovable SEO.
- If your web app or website runs on older software or plugins that no longer get updates. An audit does not replace good maintenance, but it does show where the risk is greatest.
- After a major flaw in software you use, such as the PHP vulnerability of October 2026, when you want to know whether more is going on than that one update.
Not sure whether your web app qualifies, or want to know what an audit would involve in your situation? Our page on the security audit for your website or web app explains what we check and what you get. Or get in touch right away: we’ll look together at which web app it is, who owns it, and what we would check.
