PHP Security Flaws Trigger Millions of Hacking Attempts

Companies and governments worldwide are racing to patch critical vulnerabilities in PHP after cybersecurity providers reported millions of hacking attempts following the flaws' public disclosure on October 21, 2026. The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, can allow attackers to execute code remotely on affected servers without authentication, potentially exposing sensitive information and disrupting online services.

The response has extended beyond routine software maintenance. Organizations in Japan and Europe have temporarily taken websites and online services offline while applying security fixes, while authorities in several Asian countries have urged businesses to inspect their systems and strengthen monitoring. The scale of the response highlights the risks associated with vulnerabilities in software used throughout the web's infrastructure.

PHP's developers released patched versions on October 21 and urged users to update immediately. The security team identified both vulnerabilities as critical, with CVSS v4.0 scores of 9.2. The immediate priority for administrators is to identify exposed PHP installations, apply the appropriate updates and determine whether any systems were compromised before patching.

Hacking Attempts Surged After Public Disclosure

Cloudflare reported a sharp increase in attempted exploitation after the vulnerabilities became public. Chief executive Matthew Prince said the company observed thousands of attempts across its network during the 10 hours before public disclosure. The number then rose to tens of thousands within 45 minutes, hundreds of thousands within two hours and millions thereafter, according to his public account reported by Reuters and ABC News.

Amazon also reported widespread attempts to exploit the flaws, according to Reuters. The figures describe attempted exploitation observed by security providers, not millions of confirmed successful intrusions or a verified count of compromised websites.

The rapid escalation illustrates how quickly attackers can react when technical information about a critical vulnerability becomes available. Once a flaw is publicly documented and patches are released, malicious actors can study the changes to develop or adapt exploit techniques against systems that remain unpatched.

Security researchers have also reported that exploitation attempts began before the formal public disclosure, raising concerns about the timing and coordination of the vulnerability disclosure process. WIRED reported that Amazon Web Services had recorded attempts to exploit the flaws several days before the security fixes were released.

What Are the PHP Vulnerabilities?

PHP is a server-side programming language used to build websites, process requests, interact with databases and run application logic. It underpins a broad range of online services, including content management systems, business applications and government websites.

The two vulnerabilities affect PHP's internal handling of memory and request-related state.

CVE-2026-109618 concerns an out-of-memory condition that can leave internal request data partially initialized. Under certain conditions, subsequent cleanup operations can mishandle that data, resulting in memory corruption.

CVE-2026-109619 involves stale internal state being used after the memory backing it has been freed. Such errors can create opportunities for attackers to influence a program's behavior or execute code.

The PHP security advisory warns that successful exploitation can lead to unauthenticated remote code execution. This means an attacker may be able to run code on a vulnerable server without first logging in through the affected service. The consequences depend on the server's configuration, privileges and other security controls.

The PHP security team identified the risk across installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It highlighted mod_php as particularly high-risk because a demonstrated exploit can trigger the vulnerability before application code runs.

The vulnerabilities were reportedly uncovered with assistance from artificial intelligence, according to Reuters and other news organizations. That does not mean AI alone discovered or resolved the flaws: the precise contributions of automated analysis, human researchers and software maintainers should be distinguished when evaluating the discovery process.

Which PHP Versions Need to Be Updated?

The PHP security team released fixes for four maintained release branches on October 21, 2026. Administrators should confirm the version running on each production system rather than assume that updating an application or website automatically patches PHP itself.

The corrected releases are:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

These versions address both critical vulnerabilities.

The official PHP security advisory identifies the affected deployment environments and recommends immediate updating.

Organizations running older, unsupported PHP releases face an additional challenge.

They may need to migrate to a supported branch rather than rely on a routine security update.

The PHP team has also warned that PHP 8.2 reaches end of life on December 31, 2026, after which it will no longer receive standard security fixes.

Updating the PHP runtime is only part of the response.

Applications, hosting platforms, containers and third-party products may bundle their own PHP versions, so administrators must confirm that the actual internet-facing service is using a corrected release.

Governments and Businesses Take Emergency Measures

The vulnerability disclosure prompted a range of precautionary measures across Asia and Europe.

In Japan, companies and financial institutions temporarily suspended selected online services while applying security measures.

Reuters reported that Mitsubishi UFJ Financial Group, airline ANA, railway operator East Japan Railway and other organizations took steps to address the risk.

Some websites and services were temporarily unavailable as operators assessed exposure and installed fixes.

European organizations also faced disruption.

Finland began restoring government websites after installing patches, with officials warning that recovery could take days or weeks as systems were tested.

Such delays reflect the difficulty of updating complex production environments without introducing additional operational problems.

China's industry ministry urged organizations to inspect their systems, install secure PHP versions and strengthen cybersecurity monitoring.

South Korea raised its private-sector cybersecurity alert level and activated emergency response measures.

Japan also announced plans to establish a team using AI to simulate cyberattacks and identify weaknesses in technology systems.

The initiative reflects growing government interest in using automated analysis to find vulnerabilities before attackers can exploit them.

The measures demonstrate the difficult balance between maintaining online services and preventing an attack.

Taking a system offline can reduce immediate exposure, but it may also interrupt essential services.

Leaving a vulnerable service available without effective mitigation can carry a different and potentially greater risk.

What Website Owners and IT Teams Should Do Now

Organizations should treat the incident as an urgent infrastructure-security issue, especially if they operate public-facing PHP applications.

Identify exposed systems. Inventory PHP installations across production servers, cloud environments, containers, staging systems and third-party services.

Prioritize systems accessible from the internet.

Install the appropriate security fixes. Upgrade to the corrected version for the relevant supported branch.

Confirm that the running web application uses the patched runtime and restart services when required by the deployment process.

Isolate systems that cannot be patched promptly. Follow official security guidance.

If immediate remediation is not feasible and no effective mitigation is available, consider taking the affected service offline until it can be secured.

Check for evidence of compromise. Review web server and system logs, unexpected processes, unauthorized file changes, unusual outbound connections and suspicious account activity.

Patching prevents exploitation of the known flaws in the corrected runtime, but it does not automatically remove an attacker who gained access earlier.

Protect credentials and connected systems. If an intrusion is suspected, assess whether database passwords, API tokens, application secrets or other credentials may have been exposed.

Rotate affected credentials and follow the organization's incident-response procedures.

Monitor official advisories. Hosting providers and third-party vendors may release additional instructions or updates for products that bundle PHP.

Continue monitoring for new guidance and indicators of compromise.

These measures are particularly important for smaller organizations that may operate websites without dedicated security staff.

Older applications can be difficult to update, and an unsupported PHP version may require a broader migration rather than a quick patch.

How AI Changes the Cybersecurity Response

The incident has highlighted both the potential and the limitations of artificial intelligence in software security.

AI-assisted analysis can help researchers examine code, identify suspicious memory-handling patterns and investigate weaknesses that might otherwise take considerable time to locate.

When combined with human expertise and conventional testing, these tools can accelerate vulnerability research and remediation.

The same acceleration can benefit attackers.

Automated systems can help scan for exposed services, analyze publicly available technical information and adapt exploit attempts to vulnerable targets.

Once a vulnerability becomes widely known, organizations may face pressure to patch faster than their usual maintenance schedules allow.

Microsoft CEO Satya Nadella referenced the PHP incident at an event in Germany, emphasizing the importance of building software that can be maintained securely as systems grow more complex.

The broader lesson is that finding a vulnerability is only one stage of cybersecurity.

Researchers and maintainers must disclose it responsibly, develop and distribute a fix, and give operators enough time and guidance to deploy the update.

Organizations must then verify the fix and investigate whether the vulnerability was exploited before remediation.

The PHP incident shows how failures or delays at any stage can increase the exposure of services that millions of people depend on.

Sources

• PHP.net — Official security advisory, October 21, 2026. Confirms the vulnerability identifiers, affected deployment environments, corrected PHP versions and the recommendation to update immediately.
• UK National Cyber Security Centre (NCSC) — October 21, 2026. Explains the remote code execution risk and recommends identifying exposed systems, installing updates and isolating systems that cannot be remediated promptly.
• Reuters — October 22, 2026. Reports the surge in exploitation attempts, Cloudflare's observations, emergency website shutdowns and government responses.
• Reuters — October 23, 2026. Reports Japan's plans for AI-assisted cyberattack simulation and further government responses to the PHP vulnerabilities.
• WIRED — October 21, 2026. Examines evidence of exploitation attempts before the public security fixes and the challenges surrounding the vulnerability disclosure timeline.
• Associated Press — October 23, 2026. Provides broader context on the vulnerabilities, AI-assisted security research and disruptions affecting public and private services.