AI Discovers PHP Flaws, but Premature Leak Sparks Criticism

The discovery of previously unnoticed vulnerabilities in the PHP programming language by an Artificial Intelligence tool has sparked debate about Cybersecurity, responsible disclosure and the growing dependence on technology. While the use of AI to identify weaknesses in widely used software has been welcomed as a positive development, questions have emerged over the decision to reveal details of the flaws before developers had an opportunity to fix them.

In response to a recent article by Chris Stokel-Walker examining whether technology companies should pay to repair problems affecting the internet, Guardian readers David Gibson and Charles MacKinnon offered different perspectives on the issue. Gibson argued that the AI-assisted discovery was beneficial but criticised the premature disclosure of vulnerability details. MacKinnon raised broader concerns about society’s dependence on complex technological systems that ordinary users neither understand nor control.

Their letters highlight two important aspects of the modern technology landscape: the potential of artificial intelligence to improve software security and the risks created when digital infrastructure becomes increasingly complicated, commercially driven and difficult to maintain.

AI Deserves Credit for Discovering the PHP Vulnerabilities

David Gibson, writing from Leeds, argued that the discovery of the PHP vulnerabilities should be viewed as a positive example of how artificial intelligence can contribute to cybersecurity.

PHP is a widely used programming language that powers websites, web applications and server-side systems across the internet. Because it is embedded in a substantial amount of digital infrastructure, weaknesses in its underlying code can have consequences for developers, businesses and website users.

According to Gibson, the recently identified bugs had existed in the PHP source code for a considerable period without being noticed. He described them as extremely obscure problems that had remained undetected without causing apparent harm.

His central point was that the vulnerabilities were not discovered through a conventional hacking operation. Instead, an AI tool was used to examine the PHP source code and identify weaknesses that human reviewers had apparently overlooked.

Gibson considered this an appropriate and useful application of artificial intelligence. Rather than treating AI as a threat to software development, he argued that its ability to examine large amounts of code and identify unusual problems could help improve the security of widely used technologies.

Modern software projects often contain millions of lines of code, making comprehensive manual inspection difficult. Automated analysis tools can help developers identify suspicious patterns, programming errors and potential security weaknesses that might otherwise remain unnoticed.

AI-assisted code analysis can therefore provide another layer of protection, particularly when used alongside established security testing methods and human expertise.

Why Revealing Vulnerabilities Before a Fix Can Be Dangerous

Although Gibson praised the AI-assisted discovery, he argued that the real problem emerged when details of the vulnerabilities were reportedly leaked before developers had an opportunity to address them.

In cybersecurity, discovering a software vulnerability and publicly revealing information about it are two separate activities. The first can help protect users by allowing developers to identify and correct weaknesses. The second can create additional risks if technical details become available before a security update has been released.

A vulnerability that remains unknown to the public may be difficult for malicious actors to exploit. However, once specific information about the weakness becomes available, attackers may be able to investigate the affected code and develop ways to take advantage of it.

This is particularly concerning when the software is used by large numbers of websites and organisations. A weakness in a widely deployed programming language or software component can potentially affect multiple systems, depending on how the vulnerable code is used.

Gibson argued that the person responsible for revealing the details before the flaws could be fixed deserved criticism. He suggested that such disclosure should attract legal consequences if it was not already covered by existing laws.

His letter stated that sufficient penalties should be introduced to discourage people from revealing sensitive vulnerability information prematurely.

The argument reflects a broader debate about responsible vulnerability disclosure. Security researchers frequently identify weaknesses in software and report them to the relevant developers before publishing technical details. This gives organisations time to investigate the issue, prepare patches and inform users about necessary updates.

However, disclosure practices can vary depending on the severity of the vulnerability, the availability of a fix and whether the developer responds to reports. The timing and level of technical detail in a public announcement can significantly influence the risks faced by users.

What Is Responsible Vulnerability Disclosure?

Responsible vulnerability disclosure is a cybersecurity practice in which researchers inform software developers or vendors about security weaknesses before making detailed information publicly available.

The objective is to balance transparency with user protection. Public disclosure is important because it allows organisations and users to understand security problems, monitor affected systems and take appropriate action. However, releasing technical details too early can give attackers information that they may use against vulnerable systems.

A typical coordinated disclosure process involves several stages:

• Discovery: A security researcher or automated tool identifies a potential vulnerability in software.
• Private reporting: The researcher contacts the relevant developer or security team and provides information about the issue.
• Investigation: Developers verify the vulnerability, assess its severity and determine which versions or systems are affected.
• Remediation: The development team prepares a security patch or another mitigation to address the problem.
• Public disclosure: Relevant information is released, ideally after users have had an opportunity to install the fix or apply recommended protections.

This process is not always straightforward. Some vulnerabilities are difficult to reproduce, while others affect multiple software components maintained by different organisations. Developers may also require additional time to prepare and test a reliable security update.

Nevertheless, coordinated disclosure helps reduce the period during which users remain exposed to a known security weakness without an available remedy.

Charles MacKinnon Warns About Society’s Dependence on Technology

While Gibson focused on the PHP vulnerabilities and the timing of their disclosure, Charles MacKinnon, writing from Glasgow, used the wider discussion to raise concerns about society’s increasing dependence on technology.

MacKinnon said that Stokel-Walker’s article reminded him of a warning made by astronomer and science communicator Carl Sagan in 1995.

Sagan observed: “We live in a society exquisitely dependent on science and technology, in which hardly anyone knows anything about science and technology”.

MacKinnon argued that the observation remains relevant as digital systems become more deeply embedded in everyday life. Citizens and customers increasingly depend on technological processes that they may not fully understand and, in many cases, did not actively choose.

He suggested that people have gradually been encouraged, persuaded and sometimes pressured into accepting new ways of working and behaving through digital tools and services.

From online banking and communication platforms to workplace software and public services, technology now plays a central role in activities that were previously handled through more direct or traditional processes.

MacKinnon’s concern was that ordinary users have little influence over how these systems are designed, maintained or operated. In many situations, their practical control may be limited to basic troubleshooting actions such as switching a device off and on again.

His letter also questioned whether the increasing use of technology always improves the quality of services. He argued that commercial priorities, including the pursuit of higher profits, can lead to job losses and declining service standards while customers become more dependent on digital systems.

Complex Software Systems Create New Security and Maintenance Challenges

MacKinnon also criticised the growing complexity of modern technology infrastructure. He referred to the numerous background tools and middleware components that organisations have gradually added to existing systems.

Middleware refers to software that connects different applications, services and components, allowing them to communicate and exchange information. It is commonly used in business systems, cloud infrastructure, websites and large-scale digital platforms.

These tools can make software more flexible and help organisations integrate systems that were developed at different times. However, the resulting infrastructure can become difficult to understand and maintain when new components are repeatedly added without a clear overall design.

Older applications are often kept operational because replacing them completely would be expensive or disruptive. Organisations may therefore connect newer services to legacy systems, creating complex networks of dependencies.

Over time, these arrangements can make it harder for developers and administrators to identify where a problem originates. A weakness in one component may affect other services that depend on it, while updates to one part of the infrastructure can create compatibility problems elsewhere.

Security maintenance also becomes more complicated when organisations rely on multiple software libraries, frameworks, plugins and external services. Each component may have its own update schedule, security requirements and maintenance responsibilities.

MacKinnon argued that this type of infrastructure often lacks a coherent overall design and adequate methods of security and maintenance. His criticism reflects concerns that commercial pressure to introduce new tools and services can sometimes take priority over long-term reliability.

What Is Y2K Mark 2 and Why Did MacKinnon Use the Comparison?

In his letter, MacKinnon described the situation as “Y2K Mark 2”, referring to the well-known computer problem associated with the year 2000.

The original Y2K problem, also known as the Millennium Bug, emerged because many older computer systems stored years using two digits rather than four. For example, the year 1999 could be represented as 99, creating the possibility that systems would interpret the year 2000 as 1900.

Because computer systems were widely used in banking, transport, government services, utilities and business operations, the problem raised concerns about potential failures when the calendar changed at the end of 1999.

Governments and organisations invested significant resources in identifying affected systems, updating software and testing infrastructure before the transition to 2000. Although the anticipated widespread disruption did not occur, the preparations demonstrated how dependent modern society had become on computer systems.

MacKinnon’s comparison suggests that today’s technological infrastructure could face another major reliability challenge, but one arising from a different set of problems.

Rather than a single date-related programming issue, his concern centres on the accumulation of interconnected software components, legacy systems and security weaknesses. These systems may be difficult to maintain because their complexity has increased gradually over many years.

The comparison is a warning about the consequences of neglecting long-term software maintenance. When organisations depend on infrastructure that few people fully understand, identifying and correcting problems can become increasingly difficult.

Why AI-Based Code Analysis Matters for Cybersecurity

The PHP discovery described by Gibson also highlights the growing role of artificial intelligence in software security. AI tools can assist developers by examining code, identifying unusual patterns and suggesting areas that require closer inspection.

Traditional static analysis tools examine source code without executing the program. They can identify issues such as insecure coding practices, incorrect data handling and potentially dangerous functions. AI-assisted systems can extend this process by analysing code patterns and helping researchers investigate complex relationships within large software projects.

Such tools may be particularly useful in projects with extensive codebases, where manual reviews require considerable time and expertise.

However, AI-based security analysis is not a complete replacement for human researchers. Automated systems can produce false positives, misunderstand the context of a particular function or fail to recognise vulnerabilities that depend on how software behaves during execution.

Security findings therefore need to be verified through testing and expert review. Developers must determine whether an identified issue is genuinely exploitable, how serious it is and what changes are required to fix it safely.

AI can improve the speed and scale of vulnerability discovery, but the wider security process still depends on responsible reporting, effective patch management and cooperation between researchers and software maintainers.

Should Technology Companies Take Greater Responsibility for Internet Security?

The readers’ responses also connect with the wider question raised by Chris Stokel-Walker’s article: whether technology companies that generate substantial profits from internet infrastructure should contribute more towards fixing its weaknesses.

Modern digital services depend on software maintained by a combination of large technology companies, open-source developers, independent researchers and smaller businesses. A vulnerability in one widely used component can create risks for organisations that did not develop the original software but rely on it for their operations.

This creates a complicated question of responsibility. The organisation that discovers a flaw may not be the organisation that owns or maintains the affected software. Similarly, companies using vulnerable components may have limited visibility into the security practices of every supplier in their technology chain.

Technology companies can contribute to better security through regular updates, independent audits, vulnerability reporting programmes and long-term support for software products. They can also help maintain the infrastructure on which their services depend.

However, responsibility does not rest with a single group. Software developers, service providers, businesses and users all have different roles in maintaining secure systems.

The challenge is to ensure that security is treated as an essential part of technology development rather than an expense that can be postponed until a problem becomes public.

Why the PHP Vulnerability Debate Goes Beyond One Programming Language

PHP is only one part of the wider software ecosystem that supports the internet. Websites and online services typically rely on multiple layers of technology, including programming languages, databases, web servers, frameworks and third-party libraries.

A weakness in any of these components can potentially affect the security of an application. The impact depends on the nature of the vulnerability, how the affected software is configured and whether the vulnerable functionality is exposed to external users.

This is why software maintenance requires continuous attention. Even systems that have operated without obvious problems for years may contain weaknesses that become visible only after new testing methods or security tools are introduced.

The use of AI to examine PHP source code demonstrates how newer technologies can help identify problems in established software. At the same time, the controversy surrounding the reported disclosure shows that finding a vulnerability is only the beginning of the process.

Developers must be given a reasonable opportunity to investigate and address security issues, while users need timely information that allows them to protect their systems.

Readers Highlight Two Sides of the Technology Debate

The letters from Gibson and MacKinnon approach the same technology debate from different directions. Gibson focused on the immediate cybersecurity implications of the PHP vulnerabilities, arguing that AI deserved recognition for identifying the flaws while the premature leak deserved criticism.

MacKinnon looked at the broader relationship between people and technology. His concerns centred on the complexity of digital infrastructure, the influence of commercial priorities and the limited control ordinary users have over systems that increasingly shape their daily lives.

Together, their arguments underline the importance of treating technological progress and digital responsibility as connected issues. AI can help identify security weaknesses, but its effectiveness depends on how discoveries are handled. Similarly, increasingly sophisticated digital systems can improve services, but they require careful design, transparent management and continuous maintenance.

The PHP incident therefore raises questions that extend beyond a single programming language. It demonstrates the value of using AI to strengthen software security while highlighting the risks of exposing vulnerabilities before they can be addressed.

As society becomes more dependent on interconnected technology, the challenge will be to ensure that innovation is accompanied by accountability, security and an understanding of the systems on which people increasingly rely.

The Guardian invited readers with opinions on its published articles to submit letters for consideration in its letters section.