A flaw in a programming language might seem like an issue restricted only to those who write code. But when that technology is present in millions of systems, a vulnerability can trigger a reaction involving companies, governments, and security teams across different countries.

That is what happened on October 21, 2026, when two critical vulnerabilities were disclosed in PHP, a language used in the development of websites and web applications. Known collectively as PHP2Shell, the flaws can allow an attacker to remotely execute code on vulnerable servers without needing a login or password.

The severity led the United States National Security Agency (NSA) to recommend the immediate application of patches and, when that was not possible, taking systems temporarily offline until they were protected. In Brazil, public agencies also adopted preventive measures, including the suspension of external access to the Electronic Information System (SEI).

What is PHP?

PHP is an open-source programming language used primarily in web application development. It runs on the server and allows for processing requests, querying databases, managing sessions, and producing dynamic content before the page is delivered to the browser.

The technology is present in systems of various sizes and purposes. Among the examples is WordPress, a famous system used for creating and managing websites. The ecosystem also includes enterprise applications, institutional portals, and management tools.

The security company Wiz estimates that PHP is used on about 70% of the world's websites.

Why does it affect so many websites and systems?

The scope of the problem is related to PHP's position in the infrastructure. An application may have been developed years ago, use a well-known framework, and have its own authentication rules, but still depend on the language's execution engine installed on the server.

When the vulnerability lies within that component, merely updating the content management system or plugins does not necessarily resolve the issue. It is necessary to check the version of PHP running the application and, when applicable, also update the products that bundle their own version of the language.

This distinction is important for companies using hosting services, e-commerce platforms, or systems developed by third parties. The person responsible for the site might not even directly manage the server, but they need to know who is responsible for applying the patch.

The risk is also not limited to public-facing pages. PHP can be present in administration interfaces, internal tools, and other products that incorporate the language. For this reason, advisories recommend inventorying the systems and services that depend on it, rather than checking only the most visible websites.

What are the PHP2Shell vulnerabilities?

The flaws were registered as CVE-2026-109618 and CVE-2026-109619. Both are related to memory management and the handling of internal states during the processing of requests by PHP.

To understand the problem, it is worth recalling that a server must allocate and free memory while processing requests. This memory temporarily holds data needed to execute operations. If a flaw leaves internal references in an inconsistent state, the program may end up using invalid information or accessing memory regions that have already been freed.

The first vulnerability, CVE-2026-109618, involves handling situations where PHP runs out of available memory during an operation. The interruption can leave internal structures partially initialized, which end up being treated as if they were in a valid state.

The second, CVE-2026-109619, involves references to request data that remain present after the corresponding memory has been freed. A subsequent operation may reuse this state before it is properly reinitialized.

Under certain conditions, these flaws can allow remote code execution, known by the acronym RCE (Remote Code Execution). In practice, this means an attacker can execute commands on the vulnerable server from a network-sent request without needing prior authentication.

The impact depends on the execution conditions and the permissions available to the compromised process. Among the risks are access to sensitive data, file alteration, application downtime, and the use of the server as an entry point to reach other components of the infrastructure.

The PHP team published fixes on October 21, 2026. The announced patched versions include PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Older installations also need to be evaluated, especially when running versions that no longer receive regular updates.

How did AI help find the flaws?

The vulnerabilities were identified by researchers using tools capable of analyzing code, exploring hypotheses, and assisting in the investigation of complex behaviors.

OpenAI reported that Calif, a California cybersecurity firm, identified one of the flaws using the GPT-5.6 Sol model as part of the Patch the Planet initiative. Wiz also found the vulnerabilities independently, using AI tools and models in its research process. The findings were submitted to the PHP maintenance team for investigation and remediation.

The work involved understanding the software's internal workings, formulating hypotheses, testing behaviors, and evaluating whether a flaw could be exploited.

In the case of PHP, the participation of AI helped reveal flaws that had been present for years. This does not mean the technology replaced experts or handled all steps on its own. Researchers needed to validate the results, report the findings, and work with maintainers so that fixes could be developed and published.

What happened in Brazil?

The impact reached Brazil when public agencies were advised to evaluate their systems and implement preventive measures. The Digital Government Integrated Cyber Security Center (CISC) issued an alert, and the Institutional Security Cabinet also published technical recommendations for updating PHP.

Among the systems affected by preventive measures was SEI, a platform used by public agencies to generate, organize, and process administrative documents and cases digitally.

The National Telecommunications Agency (Anatel) temporarily suspended external access to SEI and other services. Federal regional courts also confirmed preventive suspensions of system access while technical teams assessed exposure and implemented necessary measures.

The measure did not mean that a breach of these systems had been confirmed. The goal was to reduce risk while the infrastructure was being inspected and protected. In public services, this decision requires balancing the continuity of operations with the need to safeguard information and prevent unauthorized access.

In a statement, the Ministry of Management and Innovation in Public Services explained that the alert was sent to agencies using SEI and that preventive measures could include temporary access suspension. The ministry also clarified that the patch must be applied to PHP, not necessarily through the installation of a new version of SEI. There is, however, a caveat: agencies using older versions of SEI must evaluate upgrading the platform itself, as current PHP patches are intended for 8.x versions. 

The federal government also reported that technology units were instructed to disable external access and update servers with the available patch. During the temporary unavailability of SEI, agencies were instructed to use alternatives for urgent documents that depended on external routing. According to the official statement, government websites using different technologies and the GOV.BR platform were not impacted.

How to fix the PHP flaw?

The primary recommendation from authorities is to identify environments running PHP and apply the corresponding updates. Because the flaw is in the core of the language, it is not enough to check if the website uses WordPress or if its plugins are up to date. It is necessary to identify the version of PHP that actually executes requests and also inspect products that incorporate this technology.

Guidance from the Digital Government Integrated Cyber Security Center prioritizes upgrading to patched versions and identifying systems exposed to the internet. For organizations unable to apply the fix immediately, the advisory recommends evaluating temporary mitigation measures and restricting access to vulnerable services.

An initial response plan should include:

• Inventorying environments: identify servers, applications, administrative panels, and appliances running PHP, including systems maintained by external vendors.

• Prioritizing exposed services: start with internet-accessible systems and those that process sensitive data or support critical operations.

• Applying patches: update to a patched version compatible with the environment and follow official instructions from PHP and the vendors of the products involved.

• Evaluating unsupported systems: legacy installations may require migration to a maintained version or a patch provided by the vendor.

• Monitoring for signs of compromise: review activity logs, unexpected crashes, and suspicious processes, especially where there was a delay between disclosure and patching.

• Planning for service continuity: if it is not possible to secure the environment in time, evaluate restricting access or temporarily taking the system offline.

The patched PHP versions include 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The proper update path depends on the version currently used and how PHP was installed or distributed. Organizations using hosting control panels, appliances, or third-party packages should also follow advisories from their vendors.

A new vulnerability, identified as CVE-2026-115560, was disclosed by the PHP Foundation on October 23, just days after the PHP2Shell alert. This flaw can also allow remote code execution, but it depends on an uncommon combination of settings related to session management and upload progress tracking. So far, there have been no reports of in-the-wild exploitation. Because the condition required for the attack is less common, the definitive patch was scheduled for a future regular update, with no announced date yet. In the meantime, the recommendation is to temporarily disable the `session.upload_progress.enabled` feature. This measure had also been recommended in the context of the previous flaws, which means environments that already adopted it may be protected against this new vulnerability.

It is also important not to confuse installing a patch with confirming that an environment is secure. If there are indications that the vulnerability was exploited prior to patching, the organization must assess potential signs of compromise and, when necessary, conduct a security investigation.

For everyday users, the guidance is less technical. Anyone managing a website should consult their hosting provider or infrastructure team and confirm whether the patches have been applied. It is also wise to be wary of phishing messages that use the incident as a pretext to request passwords or prompt file downloads.