# You own custom software. Who is looking for its bugs?

URL: https://casterconsulting.hu/en/ai-bug-hunting-custom-software/
Published: 2026-10-24
Updated: 2026-10-24
Author: Caster Consulting

> AI tools now find twenty-year-old bugs in widely used code, and attackers have the same tools. If your company runs custom-built software, settle today who watches the third-party components inside it, and how fast they patch.

**Short answer: if you can't name someone right now, it's probably nobody.** This week showed that AI tools can find twenty-year-old bugs in one of the most widely used programming languages in the world. That is good news. The bad news is that attackers have the same tools, and the gap between a fix and an attack is no longer weeks. It is days, sometimes hours. The security of your custom software is not settled on delivery day. It depends on who keeps watching it afterwards.

## What happened?

We covered [PHP2Shell](/en/php2shell-company-website/) yesterday from the angle of company websites. The other half of the story matters more now. According to TechCrunch, the two critical bugs had been present in every PHP version since PHP 5, released in 2004, and two security teams found them using AI tools: Calif, working within OpenAI's "Patch the Planet" initiative, and Google-owned Wiz, using its own AI agent and several large language models. PHP shipped fixed releases (8.5.12, 8.4.27, 8.3.36 and 8.2.35) on 21 October.

Wiz put the shift in one line: exploitation difficulty used to be a barrier, but "with AI this is no longer a barrier." The Register reports that VulnCheck built a working exploit overnight, one that also defeats the server's memory protections, and that the firm warns attackers are using AI to look for more ways in. According to Amazon, the first exploitation attempts were seen on 17 October, four days before the patches were released.

In the same week GitLab, the code hosting and development platform many companies run on their own servers, fixed a maximum-severity bug rated 10. According to The Register, it had been present since version 7.0 in 2014, across twelve years of releases, and allows unauthenticated code execution on self-managed instances. This one was not found by AI but by a researcher through a bug bounty programme. The lesson is the same: old, "proven" code is not the same as safe code.

Defenders are speeding up too. On 22 October AWS made AWS Continuum generally available. According to AWS, it uses AI to find code vulnerabilities, confirms them in an isolated sandbox, ranks them and proposes fixes to developers as pull requests.

## What does this mean for an SMB?

Plenty of small and mid-sized companies own some custom software: a customer portal, an internal records system, a webshop extension, an integration between two systems. Usually an external developer or agency built it, and after handover it "just works".

Most of such an application is not code your developer wrote. It sits on frameworks, open-source libraries and runtimes such as PHP. If one of those has a flaw, your software is vulnerable too, even if your developer never wrote a single bad line.

Many companies have quietly relied on the fact that nobody found the old bugs. That protection is going away. If an AI tool can find a twenty-year-old flaw in a widely used language, it can find one in a less famous library as well. And defenders are not the only ones running these tools.

**A typical situation:** the development contract spells out exactly what has to be delivered, but says nothing about what happens next. Who watches for critical flaws in the libraries the software uses? Who installs the fix, and how quickly? Who pays for it? If nobody wrote that down, everyone waits for someone else in a week like this one.

AI-based bug finders can help here, but they don't replace an owner. A tool can propose a fix. Someone still has to review it, test it and put it live. Note that even AWS describes a "learn mode" in which a person approves the proposed fixes before the tool is allowed to act on its own.

The same applies to where your code lives. A self-hosted code repository often holds not just source code but deployment settings and access keys. That makes it as attractive a target as the application itself, as the GitLab bug showed.

## What should you do now?

1. **Ask your developer for a component list.** What the software is built on (language, framework, key libraries), which versions, and where it runs. If you can't get this on one page, that is an answer in itself.
2. **Put maintenance in writing.** Who monitors security advisories, how quickly a critical fix goes live, and whether that is covered by the monthly fee. Measure the deadline in days, not months.
3. **Ask how they look for bugs.** Does the developer use automated, possibly AI-based, code scanning, how often, and who decides what to do with the findings? "We'll deal with it if something happens" is not an answer.
4. **Check where the source code is kept.** If it is on a self-hosted GitLab or similar, who updates that server? Are passwords and access keys stored in the code? Treat the repository as a target, not a filing cabinet.
5. **If nobody maintains the software any more, make a decision.** Update it, replace it or switch it off. Our article on [custom software versus off-the-shelf products](/en/custom-software-or-off-the-shelf/) covers how to weigh this, and the one on [commissioning software development](/en/commission-software-development/) covers what to put in your next contract.

If you'd like someone to review what your custom software is built on and how it is maintained, take a look at our [software development](/en/software-development/) service.

## Sources

- [TechCrunch – PHP Armageddon: OpenAI, Google's Wiz find ancient holes, panicking the internet](https://techcrunch.com/2026/10/21/php-armageddon-openai-googles-wiz-find-ancient-holes-panicking-the-internet/)
- [PHP.net – News archive 2026 (critical security advisory, 21 Oct)](https://www.php.net/archive/2026.php)
- [The Register – PHP2Shell exploit bypasses protections designed to stop remote code execution](https://www.theregister.com/security/2026/10/22/php2shell-exploit-bypasses-protections-designed-to-stop-remote-code-execution/5304883)
- [The Register – Max-severity GitLab bug allows remote code execution over 12 years of releases](https://www.theregister.com/security/2026/10/22/max-severity-gitlab-bug-allows-remote-code-execution-over-12-years-of-releases/5304854)
- [The Register – Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure](https://www.theregister.com/cyber-crime/2026/10/22/hackers-pile-on-php2shell-as-aws-reveals-attacks-began-before-disclosure/5304749)
- [AWS – AWS Continuum for code vulnerabilities is now generally available](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-continuum-for-code-vulnerabilities-is-now-generally-available)