PHP

PHP2Shell: What to Check, Patch, and Verify

Mohammad Shahid, , , Leave a comment

PHP2Shell can put a website at risk even when its application code is fully updated. The vulnerabilities sit in PHP itself: the software that runs many websites, online shops and business applications.

For organisations responding, installing a patch is essential. Getting that patch to every affected system requires knowing which applications use PHP, where they run and who maintains them.

Software visibility and vulnerability monitoring need to be part of everyday security and development work. When a critical vulnerability emerges, teams need an inventory they can act on.

What is PHP2Shell?

PHP2Shell is the name given to two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated critical at 9.2 out of 10. PHP released security updates on 21 October 2026.

The flaws involve how PHP handles memory and clears information between web requests. Under certain conditions, an attacker can exploit them to execute malicious code without logging in. Sensitive information held in memory may also be exposed.

The consequences can include stolen credentials, altered website content, unauthorised access to application data and interrupted services. The attacker initially gains the permissions of the PHP process; further damage depends on what that process can access.

Where the PHP2Shell Vulnerability Sits in Your System

Exploitation depends on the deployment and configuration. PHP identifies Apache mod_php as the highest-risk setup, but PHP-FPM and other configurations serving web requests also require attention.

Which organisations are affected by PHP2Shell?

Organisations running vulnerable PHP installations are in scope, including:

  • Website operators using PHP-based platforms such as WordPress, Drupal and Joomla.
  • Retailers and e-commerce businesses running Magento, WooCommerce or custom PHP storefronts.
  • Hosting providers and managed service providers responsible for multiple customers’ websites.
  • Public-sector bodies, healthcare providers and educational institutions maintaining PHP applications, including legacy services.
  • Software companies and other enterprises using PHP in customer applications, internal tools, containers or bundled third-party products.

These categories describe potential exposure, not confirmed breaches. An organisation’s actual position depends on its deployed software and patch status.

Smaller teams may struggle with limited security resources. Larger organisations face a different challenge: finding installations spread across departments, suppliers and older systems. ENISA specifically warns that products can contain PHP without their users realising it.

Check: Establish where you are exposed

Start by identifying the PHP installations that support your live services. Include production, staging and externally accessible development environments.

Your review should cover:

  • Servers and applications: identify the PHP version actually handling web requests.
  • Containers: check both the images being built and those currently deployed.
  • Hosting platforms and appliances: look for separately bundled PHP runtimes.
  • Managed services: ask providers whether affected PHP versions are present and what remediation they have completed.

Record the service, runtime or package version, deployment location, internet exposure and responsible owner. Prioritise publicly accessible systems while assessing the remaining installations.

An SBOM can support this work when it includes the relevant components and corresponds to the deployed release. An application dependency list alone may not capture the PHP runtime underneath it.

Meterian’s software composition analysis and container scanning help teams understand components in their codebases and images and identify known vulnerabilities within their scanning coverage. Teams must connect those findings to deployed services and confirm coverage of the relevant runtime.

How to fix the PHP2Shell vulnerability

Patch: Update the runtime and confirm vendor fixes

PHP published the following fixed releases:

PHP branchFirst fixed release
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35

Install the appropriate fixed release, a later supported release, or your vendor’s corresponding security package. PHP 8.1 and older no longer receive normal upstream releases. Some vendors provide backported fixes; otherwise, plan migration to a supported branch.

A backported fix may retain an older PHP version number. Confirm remediation through the vendor’s advisory and package details, rather than relying solely on the displayed upstream version.

For containers, rebuild and redeploy affected images. For managed hosting, obtain confirmation covering both websites and any separately maintained control-panel runtime.

If immediate patching is impossible, restrict exposure and consider taking affected public services offline. Firewall rules and configuration changes can reduce particular attack paths, but they do not replace the update.

Verify: Prove the change reached production

After updating, restart affected PHP workers or redeploy containers, then verify the build serving actual web requests. A command-line version check can report a different installation.

Before closing the remediation task:

  • Confirm deployment: check every affected instance and replica.
  • Test essential workflows: verify logins, checkout, uploads and other critical functions.
  • Review suspicious activity: examine unexpected processes, modified application files, outbound connections and unusual errors.
  • Retain evidence: record the fixed build, deployment time, checks performed and accountable owner.

Amazon observed an exploitation attempt on 17 October, so investigations should cover at least that date onward. Patching prevents further exploitation through the fixed flaws; it does not remove an existing backdoor or recover stolen credentials.

Keep Monitoring after the incident

PHP2Shell illustrates how AI-assisted research can make longstanding weaknesses practically exploitable. Organisations need a response process that keeps pace with new findings.

Integrate scanning into CI/CD, maintain release-linked inventories and monitor known vulnerabilities after deployment.

Where enabled, Meterian Sentinel performs daily checks against previously scanned components and can alert teams to newly identified vulnerabilities affecting their projects.

Knowing about a vulnerability is the beginning. Security improves when the right people can find affected systems, make the change and verify that it reached production.

PHP2Shell: What to Check, Patch, and Verify

Data Protection Day!

viviandufour, , , , , , , , , , , Leave a comment
Image of a screen if the label 'Security' and a cursor hovering on it.
https://www.pexels.com/photo/internet-screen-security-protection-60504/

Yesterday, 28th January was an important day… The Council of Europe celebrated this year the 14th edition of Data Protection Day. 

This practice was to raise awareness about good practices in this field, informing users about their rights and how to exercise them.

This date is aligned to the anniversary of the opening for signature of the Council of Europe’s Convention 108 for the Protection of individuals in relation to automatic processing of personal data. For the past 30 years this has been a cornerstone of data protection, in Europe and around the world.

Why is Data Protection so important?

Data protection issues are very present throughout everyone’s lives. Not to mention in the work environment, in public relations, in the health sector, when buying goods and services, in travel or merely whilst using the internet.

However, not all people are informed on their rights. For this reason, the 28th January has been allocated to inform more users on their rights and so that data protection professionals address data subjects. It is important our digitally advanced society understands what personal data is collected from them and why, as well as what their rights are when their data is processed. This in turn, will help users be aware of the risks which comes with illegal mishandling and unfair processing of personal data.

Meterian can help!

Here are a list of our blogs which can help users be more cyber resilient and diligent when it comes to managing sensitive data.

Read also our past blog posts about vulnerabilities in:

to make sure your apps are not susceptible to such exploits that would risk data confidentiality.

Data Protection Day!

Vulnerability Focus: PHP

viviandufour, , , 1 Comment

5min read

Image of thief climbing out of laptop shining flashlight on PHP icon, titled Vulnerability Focus: PHP.

Listen up, app sec community – Meterian has an exciting update! We have a new addition to our family of languages for which our vulnerability scanning solution operates on. Drumroll please… it’s PHP. This means another layer of defense for your apps’ open-source dependencies to  shield them against malicious exploits. To commemorate this special day, we have written on 2 high-priority PHP vulnerabilities which will undoubtedly make an interesting read!

  • CVE-2019-9081 A vulnerability in the Illuminate component of Laravel Framework 5.7.x. could result in a remote cyber attack impacting confidentiality, integrity and availability in the process of web development.
  • CVE-2019-14933 A CSRF vulnerability in the Bagisto framework v0.1.5 could lead to attackers removing or manipulating important functionalities which will cause mass denial of services within an application.

CVE-2019-9081 

Vulnerability Score: Critical––9.8 (CVSS v3.0)

Platform: PHP

Component: laravel/laravel

Affected versions: 5.7.0 – 5.7.27

Attention to all PHP programmers! Read up, this is important stuff. On the 24/02/19, a vulnerability was found in the Illuminate component of Laravel Framework 5.7.x., a PHP development framework based on PHP 7.1.3. The severity of the threat is understood when seeing that 107,933 live websites use Laravel. It is also said to be the most popular web app category in the United Kingdom. This demonstrates the scale of potentially affected users, and why action needs to be taken quickly to avoid security flaws. 

A graph depicting the rise in Laravel Usage Statistics. The statistics range from the years 2013-2019.
Laravel Usage Statistics: https://trends.builtwith.com/framework/Laravel

The vulnerability is related to the __destruct method of the PendingCommand class in PendingCommand.php. It is a deserialization RCE (Remote Code Execution) vulnerability originating from a laravel core package and has shown to be triggered as long as the deserialized content is controllable. The access vector was through the network.

So what is the threat? In regards to CWE-502, when developers place restrictions on ‘gadget chains’ and method invocations that can self-execute during the deserialization process, this can allow attackers to leverage them to make unauthorized actions. For example, generating a shell. Manipulation with an unknown input leads to a privilege escalation vulnerability (code execution). Therefore, this vulnerability could have a negative impact on confidentiality, integrity and availability. Even worse, an attack can be initiated remotely with no form of authentication needed for exploitation. 

It is suggested to upgrade the laravel framework to version 5.7.27 or higher as soon as possible. So don’t waste any time! Or risk being vulnerable to potential cyber attacks!

CVE-2019-14933

Vulnerability Score: High — 8.8 (CVSS v3.0)

Platform: PHP

Component: bagisto

Affected versions: 0.1.5

Bagisto is a tailored e-commerce framework designed on some of the hottest open-source technologies such as Laravel, a PHP framework.  It cuts down on the resources needed to deploy an e-commerce platform (i.e. building online stores or migrating from physical stores). 

Alas, we regret to be the bearer of bad news. Version 0.1.5 of Bagisto has been found to contain a cross-site request forgery (CSRF) vulnerability which could result in client side manipulation that forces end users to execute unwarranted commands on a web application for which they are currently authenticated.  It should be noted that this compromised version allows for CSRF attacks under certain conditions, such as admin Uniform Resource Identifiers (URIs).  This CSRF vulnerability manipulates authenticated users’ browsers to send forged HTTP requests, including cookie sessions to exposed web applications. 

Here is some background information on the nature of CSRF attacks. Unlike remote code execution or command injection attacks, CSRF attacks specifically target state-changing requests as opposed to misappropriation of restricted data. Nonetheless, unauthorised state-changing requests can be equally bad; with the help of social engineering tactics (i.e. sending unwarranted links via email or chat support), attackers may trick end users into executing unsanctioned commands of the attackers’ choice. A successful CSRF attack could lead to vexing situations whereby attackers coerce end users into performing fund transfers, email address changes, and so forth. Furthermore, CSRF attacks can go as far as compromising entire web application systems upon gaining access to an administrator account.

In this context, hackers can trick end users by sending requests (i.e phishing emails) to lure them to open and display some apparently innocuous content in a new tab on the browser, which in turn, prompts it to execute the hidden malicious script, than can operate on behalf of the user.

This is a graphic illustrating the play-by-plat on how attackers can exploit the vulnerability to perform CSRF and remove important functionalities, which could lead to denial of services and loss of data on an e-commerce platform.
How attackers can exploit Bagisto open-source vulnerability

 The graphic above illustrates the play-by-play on how attackers can exploit this vulnerability to perform CSRF and remove important functionalities, which could lead to denial of services and loss of data on an e-commerce platform. 

In Step 1, the user first logs into the Bagisto admin page panel and subsequently  accesses a seemingly innocuous website on another tab in the user’s browser. This website contains a malignant script (placed by the hacker), and the action of accessing this tab will lead to Step 3 where the script will be executed; the browser is instructed by said script to perform any possible harmful action on behalf of the user in Step 3. This course of user action culminates in Step 4 with the server executing the requested malicious actions, such as deleting data on the admin panel.

Nonetheless, affected users will be glad to know that all versions of Bagisto following v0.1.5 are untouched by this CSRF vulnerability. So, there you have it – update your application to the latest version of the Bagisto framework at the soonest to avoid further exposure!

Spread the word on these vulnerabilities and their fixes to help us improve application security all-around. In any case, you can certainly expect more engaging reads on PHP in the near future. Until then!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously.  Sign up here to download the Meterian client today.  You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Vulnerability Focus: PHP