How is AI changing the security risk of legacy applications?

AI models can now read source code and reason about it, and they find vulnerabilities far faster than human reviewers. That matters most for legacy applications, which tend to be hard to patch, are often no longer understood by anyone on the team, and usually sit outside modern security tooling. Work that once took an attacker weeks of manual reconnaissance can now be done much faster. The risk isn’t that every flaw gets exploited. It’s that the gap between a flaw being discovered and being exploited keeps shrinking.

Can attackers use AI to find vulnerabilities in a web application through the browser?

Yes, in part. Many web applications send far more to the browser than they need to, including front-end scripts, API routes, error messages and version details. An AI agent can read all of that and work out what is running underneath, for example which framework or language version. It can then point to the endpoints most worth probing. That doesn’t hand an attacker a working exploit, but it makes the reconnaissance stage of an attack faster and cheaper, especially against older applications.

Does browser isolation protect against server-side vulnerabilities like the 2026 PHP flaws?

No. Browser isolation does not replace patching. The PHP vulnerabilities disclosed in October 2026 (CVE-2026-109618 and CVE-2026-109619) are flaws in the PHP runtime on the server. An attacker who sends requests straight to the server can still reach them, whether or not isolation is in place. The fix is to update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Isolation helps in a different way: it limits what an application reveals through the browser and keeps bots off sensitive workflows.

How do you protect a legacy web app you can’t patch or rewrite right away?

Start by listing every older web application and patching anything critical in its runtime or dependencies. Next, review what each app sends to the browser, using the developer tools, and cut unnecessary exposure such as verbose errors and version strings. For apps you can’t modernize soon, isolation can keep the underlying code and APIs from ever reaching the visitor’s device. Limit automated access to high-risk workflows like logins and payments. Finally, use AI tools to document the old code, which speeds up modernization.

What is Haven Enterprise and how does it protect web applications?

Haven Enterprise, formerly MirrorTab, is a server-side isolation product from MirrorTab Corp. Instead of sending an application’s code, data and APIs to each visitor’s browser, it keeps the live session on the server and sends a sanitized rendering of the page. People use the application as normal, but tools running in their browser can’t inspect what’s underneath. Haven Enterprise can also block automation on selected workflows. It reduces exposure through the browser but doesn’t replace patching server-side vulnerabilities.

← Blog

For businesses

AI Can Read Old Code Now. What That Means for Your Legacy Apps

Brian Silverstein · Oct 30, 2026 · 5 min read

Explore an AI summary

Perplexity ChatGPT Claude

Most organizations have at least one web app nobody wants to touch. It was built years ago, it still runs something important, the people who wrote it have moved on, and the plan to modernize it keeps slipping to next quarter. For a long time, that app was protected in part by obscurity. Finding a serious flaw in it took patience, skill, and a lot of tedious reading.

That protection is wearing thin. AI models can now read code, reason about it, and find weaknesses at a speed no human team can match. That is good news for defenders who use it, and a real shift for anyone running software they cannot easily change.

What changed this year

The clearest signal came from the AI labs themselves. In February, Anthropic's Frontier Red Team reported that its model had found and validated more than 500 high-severity vulnerabilities in open-source code, some of which had gone unnoticed for years. Since then, the volume has kept climbing. Google Threat Intelligence Group found that monthly CVE disclosures doubled in 2026, and that half of the vulnerabilities it believes were discovered by AI lead to remote code execution, compared with about a quarter of those found by other means.

The time between disclosure and exploitation is shrinking too. CrowdStrike's 2026 Threat Hunting Report found that 88% of observed exploitation of vulnerabilities with public proof-of-concept code happened within 48 hours of release.

The PHP vulnerabilities disclosed on October 21 (CVE-2026-109618 and CVE-2026-109619, often called PHP2Shell) show how these trends meet. The flaws affect PHP versions going back to 5.4, allow unauthenticated remote code execution, and were added to CISA's Known Exploited Vulnerabilities catalog within days. If you run PHP, the right response is simple: update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 now.

Keep your business safe from online threats

Haven for Business protects every employee from phishing, fake sites, and browser-based attacks.

Keep it in perspective

More vulnerabilities being found does not mean every one of them becomes an attack. Cisco Talos noted that while CVEs rose 105% year over year, known exploited vulnerabilities grew by only 37%, and the large majority of AI-discovered bugs have not been exploited in practice. Talos also expects the spike to level off as the historical backlog gets cleaned up and new code is checked by AI before it ships.

That is a reasonable outlook for code that is actively maintained. The harder question is what happens to code that is not.

Why legacy apps carry more of the risk

Legacy applications are where AI-driven discovery and slow patching collide. They are often hard to update because of old dependencies, missing tests, or nobody left who understands them. They tend to sit outside modern security tooling. And many of them send far more to the browser than they need to: front-end scripts, API routes, framework and version fingerprints, verbose error messages, and the general shape of how the application works.

For years, turning all of that into a map of weak points was slow, manual reconnaissance. An AI agent can now read everything a browser receives, infer what is running underneath, and point straight at the parts worth probing. What used to take an attacker weeks can take an afternoon.

So the question for a legacy app is no longer only "is it patched?" It is also "how much does it reveal to anyone who loads it?"

Where Haven Enterprise fits

Haven Enterprise, formerly MirrorTab, was built around a simple idea: stop handing the browser things worth studying. Instead of sending your application's real code, data, and APIs to every visitor's device, Haven Enterprise keeps the live session on the server side and delivers a sanitized rendering of the page. People still see and use the application as normal. What they, and any tool running in their browser, do not get is the underlying code and API surface.

For a legacy application, that changes a few practical things:

Less to read. AI tools and scrapers that inspect what an app sends to the browser have far less material to work with. They cannot easily tell which framework or language version is underneath, or map the endpoints behind each page.
Fewer automated visitors on sensitive workflows. Haven Enterprise can shut off automation for selected workflows, such as login, checkout, or account changes, so bots and scripted agents cannot drive them.
No rewrite required. Protection is applied in front of the application rather than inside it, so it can cover an app you are not ready to change.
Time to modernize properly. Reducing exposure buys room to plan a real upgrade instead of an emergency one.

What isolation does not do

Isolation is not a patch, and it would be wrong to present it as one. A flaw in the server runtime itself, like the PHP vulnerabilities above, can still be reached by an attacker who sends requests directly to the server. Isolation also does not cover APIs that are meant to be called by something other than a browser, such as mobile apps or partner integrations. Those still need patching, access controls, and monitoring of their own.

The value of isolation is narrower and still meaningful: it reduces what your applications reveal through the browser, it keeps automated traffic off the workflows that matter most, and it makes reconnaissance harder at a time when reconnaissance has become cheap.

A practical checklist for legacy web apps

Inventory them. List every web application still running on older frameworks or language versions, including the internal ones.
Patch what you can, starting today. Critical runtime updates like this month's PHP release come first.
Look at each app the way an AI agent would. Open the browser's developer tools and review what the app sends: scripts, API calls, error messages, version strings.
Reduce exposure where patching is slow. For apps you cannot modernize soon, consider isolating them so the browser never receives the underlying code and APIs.
Protect the workflows that matter. Identify where automated access would cause real damage, such as logins, payments, and account changes, and limit automation there.
Use AI on your side, too. The same models that find flaws can help your team read and document old code, which makes modernization faster than it has ever been.

The bottom line

AI did not create the legacy software problem. It made the cost of ignoring it easier to see. The organizations that come through this well will patch quickly, modernize steadily, and stop exposing more of their applications than they need to.

If you have legacy applications you cannot rewrite this year, talk to us about Haven Enterprise.

Haven is operated by MirrorTab Corp.

Frequently asked questions

How is AI changing the security risk of legacy applications?: AI models can now read source code and reason about it, and they find vulnerabilities far faster than human reviewers. That matters most for legacy applications, which tend to be hard to patch, are often no longer understood by anyone on the team, and usually sit outside modern security tooling. Work that once took an attacker weeks of manual reconnaissance can now be done much faster. The risk isn’t that every flaw gets exploited. It’s that the gap between a flaw being discovered and being exploited keeps shrinking.
Can attackers use AI to find vulnerabilities in a web application through the browser?: Yes, in part. Many web applications send far more to the browser than they need to, including front-end scripts, API routes, error messages and version details. An AI agent can read all of that and work out what is running underneath, for example which framework or language version. It can then point to the endpoints most worth probing. That doesn’t hand an attacker a working exploit, but it makes the reconnaissance stage of an attack faster and cheaper, especially against older applications.
Does browser isolation protect against server-side vulnerabilities like the 2026 PHP flaws?: No. Browser isolation does not replace patching. The PHP vulnerabilities disclosed in October 2026 (CVE-2026-109618 and CVE-2026-109619) are flaws in the PHP runtime on the server. An attacker who sends requests straight to the server can still reach them, whether or not isolation is in place. The fix is to update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Isolation helps in a different way: it limits what an application reveals through the browser and keeps bots off sensitive workflows.
How do you protect a legacy web app you can’t patch or rewrite right away?: Start by listing every older web application and patching anything critical in its runtime or dependencies. Next, review what each app sends to the browser, using the developer tools, and cut unnecessary exposure such as verbose errors and version strings. For apps you can’t modernize soon, isolation can keep the underlying code and APIs from ever reaching the visitor’s device. Limit automated access to high-risk workflows like logins and payments. Finally, use AI tools to document the old code, which speeds up modernization.
What is Haven Enterprise and how does it protect web applications?: Haven Enterprise, formerly MirrorTab, is a server-side isolation product from MirrorTab Corp. Instead of sending an application’s code, data and APIs to each visitor’s browser, it keeps the live session on the server and sends a sanitized rendering of the page. People use the application as normal, but tools running in their browser can’t inspect what’s underneath. Haven Enterprise can also block automation on selected workflows. It reduces exposure through the browser but doesn’t replace patching server-side vulnerabilities.