How Rust helps prevent memory errors like those behind PHP2Shell

Imagine a small business owner starting her morning with a cup of tea and opening the company website.

Everything looks normal. Customers are browsing products. Enquiries are coming in. Yesterday’s orders are waiting to be processed.

Then a message arrives from the hosting provider: “An urgent security update is required for your website.”

She calls her developer. “But we updated the website last week. What is wrong now?”

The concern is deeper than the pages she can see. The software running behind the website may have a security weakness—even though the website looks perfectly normal.

That is why the PHP security disclosures on 21 October 2026 deserve attention. Two critical vulnerabilities, collectively known as PHP2Shell, were serious enough to require emergency updates. Under exploitable conditions, they could allow an attacker to run code on an affected server without logging in.

As the news spread, an alarming claim began circulating: “75% of websites have been hacked.”

For anyone running an online store, hospital portal or business application, that sounds frightening. But the claim confuses how widely PHP is used with how many websites have actually been compromised. The available evidence does not establish that 75% of PHP websites were hacked.

The vulnerabilities are serious, and attack attempts have been observed. AI also played a role in helping researchers investigate the weaknesses.

For business owners, the immediate question is practical: What is running behind our website, and has it been secured?

Let us look at what happened, what the evidence confirms, and what website owners should do.

A widely used part of the web has a serious security problem. Two critical vulnerabilities in PHP, collectively called PHP2Shell, prompted emergency security releases on 21 October 2026. They can allow an attacker to run code on an affected server without logging in. Website owners should urgently establish whether their hosting environment has received the fixes.

However, the statement that “75% of PHP websites have been hacked” is not supported by the evidence reviewed for this article. Reports about how widely PHP is used have been confused with the number of websites successfully compromised. That distinction matters: it allows businesses to respond urgently without spreading an unverified breach statistic.

This article explains the vulnerabilities, the role of AI in investigating them, what is known about attack attempts, and the actions businesses should take. It also includes an additional PHP advisory published on 23 October, which is important even for organisations that installed the first updates.

What the percentage actually measures

On 26 October 2026, W3Techs reported that PHP was used by 69.2% of websites whose server-side programming language it could identify. This is a technology usage measurement with a defined denominator. It is neither a measurement of every website on the internet nor a count of hacked websites.

Four different questions are often mixed together in security headlines:

• How many websites use a technology?
• How many installations contain an affected software version?
• How many systems have received an attack attempt?
• How many systems have been successfully compromised?

An answer to the first question cannot establish an answer to the fourth. Even an observed attack request does not, by itself, prove that the attacker gained control.

The accurate description is that critical vulnerabilities in widely deployed PHP created a substantial security risk and triggered urgent patching. A global claim that 75% of PHP applications were hacked would require evidence that the available sources do not provide.

Why a flaw in PHP can affect many different businesses

PHP is software that runs on a server and helps generate website content, process requests and interact with databases. A business may use it through a content management system or a hosting package without its staff ever writing PHP code. The UK National Cyber Security Centre also warns that PHP can be bundled into other products, making an infrastructure inventory important.

Think of a website as a shop. The pages and features are what customers see, while the runtime is part of the machinery that keeps the shop operating. A weakness in that machinery can matter even when the shop itself is well organised.

This explains why a company should ask its hosting provider about PHP rather than judge exposure from the appearance of its website. For example, a hospital booking portal and a retailer's online store could depend on the same runtime while looking and working very differently. These are illustrations of possible dependencies, not claims that those sectors have suffered confirmed breaches in this incident.

What are these two security problems?

Researchers found two serious security weaknesses in PHP, the software that helps many websites work. Together, these problems are commonly called PHP2Shell.

A security weakness is a mistake in software that an attacker may misuse. Think of a faulty door lock. The door may appear properly closed, but someone who knows about the fault might find a way to open it.

Each problem has a separate reference number:

• CVE-2026-109618
• CVE-2026-109619

These numbers help developers and security teams identify exactly which problem they are discussing. They work like complaint reference numbers: each number points to a particular issue.

Security problems also receive a rating to show how serious they are. Both these problems received a critical rating of 9.2 out of 10. This tells website owners that they need urgent attention.

However, 9.2 out of 10 does not mean that 92% of websites have been hacked, or that your website has a 92% chance of being hacked. It measures the seriousness of the weakness.

Just as finding a faulty lock does not prove that a thief has entered a building, finding a software weakness does not prove that a website has already been hacked. That requires a separate investigation.

CVE 2026 109618 and interrupted memory handling

PHP has limits on the memory a request can consume. The first vulnerability involves what happens when memory allocation fails while internal request data is only partly prepared. Error handling can exit that operation abruptly, leaving invalid data that later cleanup code treats as usable. Under exploitable conditions, this can lead to remote code execution.

A simple analogy is an interrupted office process in which an unfinished form is accidentally filed as an approved instruction. The danger comes from the system acting on data that has not reached a valid state.

How Rust helps prevent this type of memory problem

In the problem described above, an operation stops before its data is ready. Later, the software mistakenly treats the unfinished memory as usable. Safe Rust has built-in rules that help prevent this kind of mistake.

Think of the same office example. An employee starts filling out a form but is interrupted halfway through. The danger begins when another employee treats the unfinished form as ready for processing.

Rust provides a check somewhat like preventing someone from reading a section of the form before anything has been entered there. Before the program can run, Rust’s compiler—the tool that checks and prepares the code—rejects attempts to read variables that might not have been initialised. Here, “initialised” means given a proper starting value. It does not mean that the information is factually correct or approved.

Rust also tracks who is responsible for each value in memory. During normal cleanup, its rules help ensure that successfully created values are handled correctly. If an operation fails, safe Rust must preserve memory safety, even though developers still need to decide how the application should recover.

Rust can still run out of memory. With the standard library’s default allocation-error handling, the program stops rather than returning normally and continuing the failed operation. This can interrupt a service, but avoids continuing through that failure path as though memory allocation had succeeded.

These protections apply to components written in safe Rust with correctly implemented dependencies. Unsafe code and connections to other languages need additional care. Adding Rust to another part of a website does not repair the vulnerable PHP software itself.

CVE 2026 109619 and references to released memory

The second vulnerability involves internal state that continues to refer to memory after that memory has been released. A later request handled by the same worker can encounter this stale reference before normal initialisation resets it. Carefully arranged conditions can turn this use-after-free problem into remote code execution. The relevant paths depend on the state involved and the deployment.

The analogy here is reusing an old desk reference after the desk has been cleared and assigned to someone else. The system believes the reference still points to the original information.

PHP's advisory identifies installations serving web requests as requiring attention, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies the highest risk in mod_php, where an attack has been demonstrated before application code starts running. This does not mean that one exploit works identically against every deployment.

How Rust prevents the use of memory that has already been released

In the problem described above, the software keeps an old reference to information after the memory holding that information has been released. When another request arrives, the software may follow that old reference and use memory that now contains something else.

Safe Rust is designed to prevent this type of mistake, known as use-after-free. Its references must remain valid for as long as the program uses them.

Think of the office desk example. An employee writes down where a document is kept. Later, the desk is cleared and given to another person. The employee returns using the old note and mistakenly treats the new person’s documents as the original ones.

Rust’s checks enforce a rule similar to this: you cannot clear and reassign the desk while someone still needs to use a reference to its original contents.

Before the program runs, Rust’s borrow checker examines how long information remains available and when references to it will be used. If the code tries to use a reference after the information would have been removed, Rust rejects that code. The developer must correct the problem before the program can be built.

Applied to the situation described here, these checks prevent safe Rust code from carrying a usable reference to one request’s memory into a later request after that memory has been released. This blocks the underlying memory mistake that makes this kind of attack possible.

These protections depend on correctly implemented supporting code. Rust’s unsafe operations require additional care, and adding Rust elsewhere in an application does not fix an existing weakness inside PHP itself. The component managing the affected memory must be secured.

What could happen if attackers get in

In controlled tests, Wiz showed that attackers could run their own code on affected WordPress, Drupal and Joomla servers without logging in. They could also read server memory containing passwords and access keys. These tests showed what was possible, not how many live websites had been hacked.

An attacker might steal sensitive information or change website content. How far they can go depends on what the affected software can access. Breaking into a website does not automatically open every system in the organisation.

We recommend keeping the public website, internal records and admin systems separate, and giving each service only the access it needs. This can limit the damage if attackers get in, but the PHP security updates are still necessary.

What we know about attack attempts

Amazon detected an attack attempt on 17 October, before the flaws were publicly announced. More attempts followed, including widespread attempts after disclosure. These were recorded by systems set up to attract and detect attackers. Amazon said it was unclear whether those attempts would have succeeded against real websites.

On 25 October, Palo Alto Networks Unit 42 withdrew an earlier claim linking a break-in to PHP2Shell because it could not confirm how the attackers first entered.

India’s CERT-In also cited reports of large-scale exploitation and urged businesses to apply updates urgently.

The threat is serious and attack attempts are confirmed. However, these reports do not establish what percentage of websites were successfully hacked.

How AI helped researchers

Wiz used AI to study how PHP handles memory, demonstrate attacks and check security fixes. Different PHP versions and server settings made this work difficult. AI helped researchers work through those differences with less manual effort.

This does not mean every attack used AI or that every affected website could be hacked automatically.

We believe businesses should prepare to respond faster, as AI can help both researchers and attackers understand weaknesses sooner. Each business should assign someone to manage urgent updates, know who to contact if problems arise, and check that the fixes are installed and running.

Why the fix took time

The PHP Foundation says warning signs appeared after a 2024 security review, but researchers had not yet shown how attackers could exploit the problem. Possible fixes risked breaking existing software, causing service failures or requiring changes to add-ons. A shortage of specialists and slow decision-making also delayed the work.

Later reports from Calif, OpenAI and Wiz made the danger clearer, and fixing it became a priority. The Foundation acknowledged its shortcomings and described changes to staffing and security decisions.

For businesses, the lesson is simple: even widely used free software needs skilled people and funding to stay secure. When choosing software, consider who maintains it and how quickly fixes arrive, alongside features and price.

Which PHP releases contain the original fixes

The PHP project released the following fixes on 21 October 2026. These are the upstream fixed releases for the original two PHP2Shell CVEs, rather than a permanent statement about the latest recommended release. Check current vendor guidance before deploying.

Some vendors apply security fixes to their existing packages without changing to the same upstream version number. CloudLinux explicitly documents these backported packages. Consequently, an older-looking version string is not enough to determine patch status: obtain the exact package build and the vendor's confirmation that it fixes both CVEs.

PHP 8.1 and earlier no longer receive normal upstream security releases. Owners should move to a supported branch or verify a vendor-maintained security fix rather than assume an old installation is protected.

Another warning on 23 October

PHP identified another security issue, CVE-2026-115560, that could allow attackers to run code on a server under unusual conditions. CERT-EU added it to its warning on 23 October.

It affects applications that change how visitor session information is stored—from php_binary or php_serialize to php—while running, before starting a session, with upload progress enabled.

PHP recommends disabling upload progress by setting session.upload_progress.enabled=0 until the next regular bugfix release. Applications that never make this change to session storage can keep the feature enabled. Administrators should check the full advisory.

The 21 October updates fix the original two flaws. Website owners should also ask their providers to check this later issue and confirm exactly which problems their fixes cover.

Why updating WordPress is not enough

WordPress says these flaws are in PHP, the software running behind the website. Updating WordPress, themes or plugins does not fix them. Your hosting provider must update PHP itself.

You can check the reported PHP version under Tools > Site Health > Info > Server, or in your hosting panel. Some providers add fixes to older versions, so the version number alone may not confirm protection.

Ask your provider: “Have you fixed CVE-2026-109618 and CVE-2026-109619 and checked the additional warning from 23 October? Please confirm the exact PHP package installed and when the updated version started running.”

What businesses should do now

• Find where PHP is used. Ask your providers to check websites, apps and software that includes PHP. Deal with publicly accessible systems first. The NCSC advises temporarily taking affected services offline if they cannot be secured quickly.
• Install and verify the fixes. CERT-In recommends updating PHP, restarting services where needed, and checking that the fixed version is running on every live server.
• Look for signs of a break-in. Check activity records, unexpected file changes, new admin accounts, unfamiliar programs and unusual connections to outside systems. Amazon recommends reviewing activity from at least 17 October. Installing an update does not remove an attacker who entered earlier.
• Test your services and backups. Check login, booking, payments, uploads and scheduled tasks after updating. Keep backups protected and make sure they can be restored.
• Get help if anything looks suspicious. Preserve activity records, isolate affected systems and involve security specialists. They should check for hidden access left by attackers, stolen passwords or access keys, and help restore a clean system.

Why firewalls alone are not enough

Cloudflare added website firewall rules to block known attack methods, including the later upload progress issue. However, that later rule does not cover applications using a custom name for the upload progress field. Providers should check whether the protection applies to their setup.

CERT-EU advises installing fixes immediately. If that is not possible, consider temporarily isolating affected systems. Firewall protection can reduce risk while updates are arranged, but cannot replace them.

Strong passwords, extra login verification and HTTPS remain useful, but they do not fix a PHP flaw that attackers can exploit without logging in. Backups help restore a damaged system; they do not prevent an attack.

What this teaches us about memory safety and Rust

The technical causes make memory safety relevant. Rust's ownership system uses compiler-checked rules to manage memory and reject invalid uses in safe Rust. That approach helps prevent classes of errors involving invalid references and released memory.

Joint guidance published by CISA and its partners recommends planning transitions to memory-safe languages. It also recognises that no single language fits every requirement and that other serious vulnerabilities remain possible. A measured migration plan is more defensible than a rushed rewrite during an emergency.

Rust also has unsafe capabilities and can interact with components outside its safety guarantees. Those boundaries require careful review. Rust's own documentation explains both the guarantees and the responsibilities that remain when unsafe operations are used.

Our conclusion is that memory-safe development is a useful preventive investment for appropriate new components. It cannot justify a claim that a product is unhackable, and rewriting a website in Rust would not automatically secure its hosting stack, dependencies, access controls or business logic. For an organisation already exposed to PHP2Shell, the immediate work is still to verify fixes and investigate possible compromise.

A practical lesson for digital businesses

PHP2Shell shows why organisations need visibility into the software below their applications. A website can appear normal while its runtime needs an urgent update. A supplier's reassurance is most useful when it includes the affected components, installed fixes and verification of the running service.

The responsible message for customers is specific: establish exposure, apply the required updates, check the later advisory and investigate suspicious activity. The available evidence supports that urgency. It does not support publishing a claim that 75% of PHP websites have been hacked.