AI uncovers a PHP bug dormant for 14 years: security lessons for legacy systems

A story currently making the rounds in the developer community under the hashtag #php2shell: an AI tool reviewing old source code discovered a PHP vulnerability that had quietly existed for 14 years — the kind of flaw that can let an attacker execute commands on the server and turn a website into a backdoor. The thought-provoking part is not how "smart" the AI is, but how a serious vulnerability could sit untouched through hundreds of maintenance cycles and thousands of days of operation without anyone noticing.

What happened?

According to the widely shared post, while using AI to re-read the source code of a long-running PHP system, an operator discovered a snippet that allowed user input to flow straight into a system command execution function — the classic mistake that leads to a condition known as "PHP to shell": starting from a web vulnerability, an attacker can run commands on the server, install a webshell, and take over the entire machine.

The striking part: this vulnerability had existed for 14 years. It survived multiple versions, multiple maintainers, and multiple rounds of code cleanup — without ever being detected, simply because nobody ever went back to read old code with a security-hunting eye.

Why did the vulnerability "hibernate" for 14 years?

This phenomenon is not rare, and the causes are fairly universal:

• Old code nobody reads. The original author has left, the documentation is gone, and successors only fix the exact spot that throws an error and never touch the rest — following the "if it runs, don't touch it" rule.
• Tests don't cover error paths. Test cases usually confirm that the main functionality works, while rarely traversed branches — where vulnerabilities typically live — go untested.
• Traditional scanners miss them. Rule-based static scanners catch well-known error patterns, but with complex logic and data flowing through many layers, they either stay silent or produce so much noise that no human can filter it.
• There is no incident to notice. As long as it has not been exploited, the vulnerability shows no outward signs. A system that "still runs fine" becomes false evidence that it is secure.

Legacy PHP: a worrying reality for many Vietnamese businesses

PHP still powers a large number of websites, information portals, and internal management systems in Vietnam — from business websites built years ago to homegrown internal portals. Quite a few systems still run PHP versions that have reached end of life for security support (for example, the PHP 7.x branch stopped receiving patches in late 2022), with inherited source code nobody dares to upgrade.

The double risk of legacy systems is this: the outdated foundation no longer receives vendor patches, while the custom-written code has never undergone a proper security review. Once discovered and exploited, the damage typically spreads to both customer data and the company's reputation.

AI changes how we review old code

The new element this story illustrates: the cost of "re-reading all the old code" has dropped sharply thanks to AI. It is very hard for an engineer to spend weeks reading tens of thousands of lines of undocumented code; but AI can scan the entire codebase, describe data flows, point out the places where user input reaches sensitive functions, and explain why they are dangerous — after which humans verify each warning.

Its limits must be stated clearly: AI misses things and also raises false alarms. It does not replace a professional security process; it is a first-pass filter that helps the technical team focus their energy on the riskiest spots. Combining automated scanning, security testing, and targeted manual review remains the standard practice.

Practical lessons for businesses

Even if your system is not written in PHP, the principles apply universally:

• Build a source code inventory: what systems are running, written in what, who is responsible, and when the last security review took place.
• Upgrade platforms that are past end of support: running on a language or OS version that no longer receives patches means placing yourself outside the reach of protection.
• Apply the principle of least privilege: web processes should have only the minimum permissions they need, so that even if a flaw is exploited, the damage is confined to a single zone.
• Bring automated review into the workflow: static scanners and AI review should run periodically across the entire codebase, including the part that has "run stably for years" — because that is precisely where the fewest eyes land.
• Reduce technical debt with a plan: you do not need to rewrite everything at once, but you need a part-by-part roadmap that prioritizes the modules directly exposed to the Internet.
• Monitor logs and anomalies: a long-lived webshell usually leaves traces in access logs — if anyone ever reads them.

Conclusion

A vulnerability lying dormant for 14 years is not a story about one careless programmer 14 years ago; it is a story about a long-standing habit: we only fix what breaks, and we rarely re-read what is still running. AI tools have now lowered the barrier to doing the opposite — periodically reviewing the entire system, including its oldest parts. For Vietnamese businesses operating legacy systems, this is the right moment to reopen the codebase and look at it with fresh eyes.

Source: compiled from technical discussions shared on Facebook, edited by Wotech Electronics.

If your business has been running a software system for many years and needs a security review or a technical debt assessment, the Wotech Electronics team is ready to help you carry out this "general inspection."