P
Pankaj Sakariya
Guest
- Thread Author
- #1
Two critical vulnerabilities in PHP have triggered an urgent security response from developers, hosting providers, and website administrators. Identified as CVE-2026-109618 and CVE-2026-109619, these flaws could allow attackers to execute malicious code on vulnerable web servers without authenticating to an application.
On October 21, 2026, the UK National Cyber Security Centre (NCSC) urged organizations to identify systems running PHP and apply the appropriate security updates. The PHP development team has released patched versions, making immediate remediation a priority for businesses operating PHP-based websites and applications. Both vulnerabilities carry a critical CVSS v4.0 score of 9.2, according to the PHP security advisory.
The risks extend beyond individual websites. PHP supports content management systems, ecommerce platforms, customer portals, and custom web applications. A successful attack against a vulnerable runtime could affect application data, server operations, and connected services, depending on the permissions available to the compromised process.
This guide explains what the vulnerabilities mean, how they differ, which systems require attention, and how businesses can respond without overlooking important security gaps.
9.2
CVSS v4.0 score for both vulnerabilities
0
logins an attacker may need under certain conditions
4
supported PHP branches with official fixes
Quick Answer
CVE-2026-109618 and CVE-2026-109619 are critical flaws in the PHP runtime itself that can allow unauthenticated remote code execution. Updating WordPress, plugins or application code won’t fix them. Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a verified vendor package with the fix), restart the services that serve requests, then confirm the running version. Temporary mitigations reduce exposure but are not a complete fix.
Update: October 22, 2026
NCSC New Zealand says it is aware of reports of active exploitation, so treat this as an in-progress threat, not a routine patch cycle. The PHP project says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php considered the highest risk. Firewalls, edge devices and other embedded platforms that bundle PHP may need separate assessment. See the NCSC New Zealand alert for details.
PHP, short for PHP: Hypertext Preprocessor, is a server-side scripting language used to build dynamic websites and web applications. It processes requests, interacts with databases, manages application logic, and generates responses for users.
The newly disclosed vulnerabilities affect PHP’s internal memory handling and request-processing behavior. They are not limited to a particular WordPress plugin, ecommerce extension, or application framework.
The two flaws have different technical causes:
Under certain conditions, these weaknesses can lead to unauthenticated remote code execution (RCE). This means an attacker may be able to trigger vulnerable behavior without first logging in to the affected application.
The PHP team has released security fixes for supported branches. Organizations should identify every relevant PHP installation, verify its patch status, and ensure that the updated runtime is actually serving application requests.
PHP processes need memory to handle incoming requests, execute application code, and manage temporary data. When a process can’t allocate the memory it needs, it must handle the failure without leaving internal structures in an invalid state.
An out-of-memory (OOM) condition doesn’t automatically indicate a security breach. Ordinarily, a failed request may simply terminate with an error. The problem arises when the runtime’s error-handling and cleanup mechanisms don’t correctly account for the state of internal data.
CVE-2026-109618 involves an interruption during PHP’s request initialization. Internal request data may be only partially initialized when an out-of-memory condition occurs. Here’s the sequence:
Under exploitable conditions, this corruption may allow an attacker to influence the program’s behavior and potentially execute code remotely.
The important distinction is that the vulnerability isn’t simply about consuming too much memory. It concerns how PHP handles a resource failure while its internal request state is incomplete.
Consider an ecommerce website that validates form submissions, checks customer permissions, and restricts administrative access. These protections are important, but they operate within the application’s security model.
A vulnerability in the PHP runtime may be triggered at a lower level, potentially before normal application safeguards can protect the affected operation. Consequently, developers can’t rely on input validation or plugin updates alone to resolve this issue. The underlying runtime must receive the appropriate security fix.
The second vulnerability concerns the relationship between memory allocation, memory release, and the lifecycle of a request.
Software allocates memory when it needs to store data and releases that memory when the data is no longer required. A use-after-free condition occurs when software continues to access memory through a reference that is no longer valid.
If the released memory has been reused, the program may encounter unexpected data or behave incorrectly. Depending on the circumstances, this can lead to crashes, memory corruption, or other security consequences.
According to the PHP advisory, request-owned internal state can survive after the memory backing that state has been freed. A later request handled by the same worker may encounter the stale state before normal initialization resets it. If the runtime incorrectly uses that state, the result may create an exploitable condition.
This matters in environments where PHP workers handle multiple requests during their lifetime. Each request must begin with the correct internal state, without retaining invalid references from an earlier operation.
The issue isn’t simply that a developer has failed to clear an ordinary application variable. It involves internal runtime state and memory management.
Application teams should review their PHP deployment and ensure that the runtime has been patched. They should also examine relevant request-processing workflows and error-handling behavior where appropriate.
However, ordinary application code changes can’t reliably repair a flaw in the PHP interpreter itself. Runtime remediation remains essential.
Remote code execution is a security condition in which an attacker can cause a remote system to execute code. When it affects a web server, the potential impact depends on the compromised process’s permissions, the server configuration, and the surrounding infrastructure. Possible consequences include:
Keep It in Perspective
These are potential consequences of successful exploitation, not evidence that every vulnerable website has been compromised. The practical impact depends on the environment. A PHP process running with limited permissions and strict network restrictions generally has fewer opportunities to affect other systems than one with broad access to application files, databases, and internal services.
The PHP project has published fixes for four supported release branches.
These are the official upstream fixed releases. If an organization uses packages maintained by a Linux distribution, cloud provider, or hosting vendor, it should also consult that vendor’s security advisory to confirm whether the necessary patch has been applied.
PHP 8.1 and earlier branches no longer receive regular security updates from the PHP project. Some operating-system vendors and long-term support providers may supply backported security fixes for particular deployments. NCSC-NL’s operational notes also report that PHP has published limited source backports for PHP 7.4, 8.0 and 8.1 for this incident.
Organizations shouldn’t assume that an older version is secure simply because a vendor maintains the package. They should obtain confirmation that the relevant vulnerabilities have been addressed.
Where a legacy application can’t run on a supported PHP release, businesses should assess compatibility and plan a controlled upgrade or migration. That’s often a legacy software modernization decision, not just a patching task.
PHP is used by many popular content management systems and custom applications. The relevant question is whether the underlying PHP runtime is affected, not simply which platform a website uses.
Using an affected version doesn’t prove that a website has been compromised. Nevertheless, organizations should treat the issue as urgent and verify the status of exposed systems.
1. Inventory all PHP installations
Start by identifying PHP across production, staging, development, and other relevant environments. Include internet-facing websites, PHP-FPM services, Apache deployments using
2. Verify the active PHP runtime
Administrators can use the command below to inspect the command-line PHP installation. It doesn’t necessarily identify the PHP version serving a website, though. A server may have different PHP installations for the command line, PHP-FPM, Apache, or individual containers. Check the actual web-serving configuration, installed packages, and vendor security notices before deciding that a system is patched.
php -v
3. Install the appropriate security update
Upgrade to the relevant fixed release or install a verified vendor package containing the security fix. Before making production changes, test application compatibility where feasible. Check framework requirements, extensions, and dependencies, and maintain a tested recovery plan. The update must reach the runtime that actually processes requests. Depending on the deployment, this may involve updating PHP-FPM, replacing an Apache PHP module, updating a container image, or redeploying a cloud application.
4. Restart services and verify deployment
After patching, follow the PHP and hosting vendor’s instructions for restarting or redeploying affected services. Long-running workers may continue using an older runtime until they are restarted or replaced. Containerized applications may also continue running vulnerable images if the deployment pipeline doesn’t replace existing workloads. Verify the running version and package status after deployment. A successful package installation isn’t sufficient evidence that every application has been updated.
5. Treat temporary mitigations as temporary
The PHP team has published additional hardening measures for situations where an immediate upgrade isn’t possible. These measures address particular vulnerable execution paths and may require changes to PHP configuration or request handling. Apply them according to the official advisory and test them against the application’s requirements. They shouldn’t be assumed to eliminate the underlying vulnerability. The PHP project states that updating is the only complete solution. If an exposed system can’t be patched or adequately mitigated, assess whether it needs to be isolated or taken offline until the risk can be addressed.
6. Check for signs of compromise
If a vulnerable system was exposed before remediation, review available logs and monitoring data for suspicious activity. Investigate unexpected processes, unfamiliar files, unauthorized accounts, unusual outbound connections, and changes to application or server configuration. Preserve relevant evidence if an incident is suspected. Depending on the findings, response actions may include isolating the affected system, rotating exposed credentials, restoring trusted software, and rebuilding compromised infrastructure. A clean-looking log doesn’t guarantee that a system has never been compromised. If internal teams lack the required expertise, seek assistance from a qualified incident response provider.
Not Sure Which PHP Runtime Is Serving Your Site?
Elsner’s team can help you inventory PHP across your environments, confirm what’s actually running in production, and plan a tested update without disrupting your store or application.
Talk to Elsner About PHP Security
Responsibility for PHP security is often divided between application developers, hosting providers, and infrastructure teams.
A website owner may manage WordPress content and plugins while the hosting provider controls the PHP runtime. In a custom deployment, developers may maintain application code while another team manages servers, containers, and updates. This separation can leave gaps unless responsibilities are clear. Organizations should establish who will:
Identify affected PHP installations and prioritize exposed systems.
Apply the update and confirm that the correct runtime is active.
Test application functionality after deployment.
Monitor for suspicious activity and investigate possible compromise.
Businesses using managed hosting should request confirmation of the relevant patch status rather than assume that updates have been applied automatically. Teams without in-house capacity often hand this routine to a partner offering ecommerce maintenance, so runtime updates don’t depend on someone remembering to check.
Can updating WordPress fix these PHP vulnerabilities?
Not necessarily. Updating WordPress core and plugins doesn’t automatically update the PHP runtime. The underlying PHP installation must also be patched or covered by a verified vendor security update.
Which PHP versions contain the official fixes?
The PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 with fixes for these vulnerabilities. Vendor-maintained packages should be checked separately.
Can these vulnerabilities be exploited without logging in?
Yes. The PHP advisory identifies potential unauthenticated remote code execution under certain conditions. The exact exposure depends on the deployment and the vulnerable request-processing paths.
Are these vulnerabilities being exploited?
NCSC New Zealand says it is aware of reports of active exploitation. Treat exposed systems as a priority and check current guidance from your national cyber agency and the PHP project.
Are temporary security measures a complete fix?
No. Temporary mitigations may reduce exposure to specific attack paths, but the PHP team identifies updating to a fixed version as the complete remediation.
What if I run PHP 8.1 or older?
Those branches no longer receive regular upstream security updates. Ask your operating-system or long-term support vendor to confirm a backported fix, or plan an upgrade to a supported release.
What should a business do if its website may already be compromised?
The business should investigate the affected environment, preserve relevant evidence, and follow an incident response process. Depending on the findings, containment, credential rotation, and system recovery may be necessary.
CVE-2026-109618 and CVE-2026-109619 highlight the security risks that can arise from defects in a widely used application runtime. Because PHP supports many websites and business applications, organizations should identify affected installations, apply the appropriate security updates, and verify that patched runtimes are actively serving requests.
Patching should be accompanied by careful deployment checks, appropriate access controls, monitoring, and investigation of potentially exposed systems. For businesses operating PHP-based ecommerce platforms and websites, a clear process for handling critical vulnerabilities can reduce the likelihood of avoidable security incidents.
Need Help Patching or Auditing Your PHP Environment?
If you’d like a second pair of eyes on your PHP versions, hosting setup and deployment pipeline, Elsner can help you verify exposure and plan a safe fix.
Contact Elsner
The post Critical PHP Vulnerabilities: Risks, Affected Versions, and Security Fixes first appeared on Elsner Technologies Pvt. Ltd..
On October 21, 2026, the UK National Cyber Security Centre (NCSC) urged organizations to identify systems running PHP and apply the appropriate security updates. The PHP development team has released patched versions, making immediate remediation a priority for businesses operating PHP-based websites and applications. Both vulnerabilities carry a critical CVSS v4.0 score of 9.2, according to the PHP security advisory.
The risks extend beyond individual websites. PHP supports content management systems, ecommerce platforms, customer portals, and custom web applications. A successful attack against a vulnerable runtime could affect application data, server operations, and connected services, depending on the permissions available to the compromised process.
This guide explains what the vulnerabilities mean, how they differ, which systems require attention, and how businesses can respond without overlooking important security gaps.
9.2
CVSS v4.0 score for both vulnerabilities
0
logins an attacker may need under certain conditions
4
supported PHP branches with official fixes
Quick Answer
CVE-2026-109618 and CVE-2026-109619 are critical flaws in the PHP runtime itself that can allow unauthenticated remote code execution. Updating WordPress, plugins or application code won’t fix them. Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a verified vendor package with the fix), restart the services that serve requests, then confirm the running version. Temporary mitigations reduce exposure but are not a complete fix.
Update: October 22, 2026
NCSC New Zealand says it is aware of reports of active exploitation, so treat this as an in-progress threat, not a routine patch cycle. The PHP project says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php considered the highest risk. Firewalls, edge devices and other embedded platforms that bundle PHP may need separate assessment. See the NCSC New Zealand alert for details.
What Are CVE-2026-109618 and CVE-2026-109619?
PHP, short for PHP: Hypertext Preprocessor, is a server-side scripting language used to build dynamic websites and web applications. It processes requests, interacts with databases, manages application logic, and generates responses for users.
The newly disclosed vulnerabilities affect PHP’s internal memory handling and request-processing behavior. They are not limited to a particular WordPress plugin, ecommerce extension, or application framework.
The two flaws have different technical causes:
| Problem type | Out-of-memory handling problem | Stale internal state problem |
| What goes wrong | Memory corruption when internal request data is only partially initialized | Request-owned data may be referenced after its backing memory has been released |
| Possible outcome | Unauthenticated remote code execution under certain conditions | Unauthenticated remote code execution under certain conditions |
| CVSS v4.0 | 9.2 (Critical) | 9.2 (Critical) |
[th]
CVE-2026-109618
[/th][th]
CVE-2026-109619
[/th]Under certain conditions, these weaknesses can lead to unauthenticated remote code execution (RCE). This means an attacker may be able to trigger vulnerable behavior without first logging in to the affected application.
The PHP team has released security fixes for supported branches. Organizations should identify every relevant PHP installation, verify its patch status, and ensure that the updated runtime is actually serving application requests.
How CVE-2026-109618 Creates a Security Risk
Understanding out-of-memory conditions
PHP processes need memory to handle incoming requests, execute application code, and manage temporary data. When a process can’t allocate the memory it needs, it must handle the failure without leaving internal structures in an invalid state.
An out-of-memory (OOM) condition doesn’t automatically indicate a security breach. Ordinarily, a failed request may simply terminate with an error. The problem arises when the runtime’s error-handling and cleanup mechanisms don’t correctly account for the state of internal data.
What happens inside the runtime?
CVE-2026-109618 involves an interruption during PHP’s request initialization. Internal request data may be only partially initialized when an out-of-memory condition occurs. Here’s the sequence:
1
A request begins and PHP starts setting up internal request data.2
An out-of-memory condition interrupts initialization partway through.3
That internal data is left only partially initialized.4
PHP runs cleanup for the failed request.5
Cleanup logic treats the incomplete structure as valid and processes invalid data.6
Memory corruption occurs, which an attacker may be able to influence.Under exploitable conditions, this corruption may allow an attacker to influence the program’s behavior and potentially execute code remotely.
The important distinction is that the vulnerability isn’t simply about consuming too much memory. It concerns how PHP handles a resource failure while its internal request state is incomplete.
Why application-level security may not be enough
Consider an ecommerce website that validates form submissions, checks customer permissions, and restricts administrative access. These protections are important, but they operate within the application’s security model.
A vulnerability in the PHP runtime may be triggered at a lower level, potentially before normal application safeguards can protect the affected operation. Consequently, developers can’t rely on input validation or plugin updates alone to resolve this issue. The underlying runtime must receive the appropriate security fix.
How CVE-2026-109619 Exploits Stale Internal State
The second vulnerability concerns the relationship between memory allocation, memory release, and the lifecycle of a request.
What is a use-after-free vulnerability?
Software allocates memory when it needs to store data and releases that memory when the data is no longer required. A use-after-free condition occurs when software continues to access memory through a reference that is no longer valid.
If the released memory has been reused, the program may encounter unexpected data or behave incorrectly. Depending on the circumstances, this can lead to crashes, memory corruption, or other security consequences.
Why PHP request handling matters
According to the PHP advisory, request-owned internal state can survive after the memory backing that state has been freed. A later request handled by the same worker may encounter the stale state before normal initialization resets it. If the runtime incorrectly uses that state, the result may create an exploitable condition.
This matters in environments where PHP workers handle multiple requests during their lifetime. Each request must begin with the correct internal state, without retaining invalid references from an earlier operation.
The issue isn’t simply that a developer has failed to clear an ordinary application variable. It involves internal runtime state and memory management.
What developers should do
Application teams should review their PHP deployment and ensure that the runtime has been patched. They should also examine relevant request-processing workflows and error-handling behavior where appropriate.
However, ordinary application code changes can’t reliably repair a flaw in the PHP interpreter itself. Runtime remediation remains essential.
Why Remote Code Execution Is a Serious Business Risk
Remote code execution is a security condition in which an attacker can cause a remote system to execute code. When it affects a web server, the potential impact depends on the compromised process’s permissions, the server configuration, and the surrounding infrastructure. Possible consequences include:
| Unauthorized access | An attacker may be able to run commands with the privileges of the affected PHP process. |
| Data exposure | Accessible customer records, application configuration, database credentials, or other sensitive information may be at risk. |
| Website manipulation | Malicious changes to website content or application files may affect customers and business operations. |
| Persistent unauthorized access | Attackers may attempt to install backdoors or other mechanisms that allow continued access. |
| Service disruption | Malicious activity may affect website availability, performance, or normal request processing. |
| Further infrastructure exposure | Compromised credentials or excessive permissions may provide access to connected systems. |
[th]
Risk
[/th][th]
What it could mean
[/th]Keep It in Perspective
These are potential consequences of successful exploitation, not evidence that every vulnerable website has been compromised. The practical impact depends on the environment. A PHP process running with limited permissions and strict network restrictions generally has fewer opportunities to affect other systems than one with broad access to application files, databases, and internal services.
Which PHP Versions Are Affected?
The PHP project has published fixes for four supported release branches.
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
[th]
PHP branch
[/th][th]
Fixed version
[/th]These are the official upstream fixed releases. If an organization uses packages maintained by a Linux distribution, cloud provider, or hosting vendor, it should also consult that vendor’s security advisory to confirm whether the necessary patch has been applied.
What about PHP 8.1 and older versions?
PHP 8.1 and earlier branches no longer receive regular security updates from the PHP project. Some operating-system vendors and long-term support providers may supply backported security fixes for particular deployments. NCSC-NL’s operational notes also report that PHP has published limited source backports for PHP 7.4, 8.0 and 8.1 for this incident.
Organizations shouldn’t assume that an older version is secure simply because a vendor maintains the package. They should obtain confirmation that the relevant vulnerabilities have been addressed.
Where a legacy application can’t run on a supported PHP release, businesses should assess compatibility and plan a controlled upgrade or migration. That’s often a legacy software modernization decision, not just a patching task.
Are WordPress, Drupal, Joomla, and Ecommerce Websites at Risk?
PHP is used by many popular content management systems and custom applications. The relevant question is whether the underlying PHP runtime is affected, not simply which platform a website uses.
| WordPress | WordPress relies on PHP for application logic, database interactions, themes, and plugins. Updating WordPress core doesn’t automatically patch the PHP runtime provided by the hosting environment. Our notes on WordPress security challenges and solutions cover the application side of the picture. |
| Drupal and Joomla | These platforms also depend on PHP. Administrators should verify the runtime version and check the status of any vendor-managed security updates. |
| Ecommerce applications | PHP-based stores and custom commerce systems may process customer information, orders, inventory, and application credentials. A compromised runtime could put these assets at risk, depending on the access available to the affected process. |
| Custom web applications | Applications built on PHP frameworks should be assessed alongside their underlying server configuration, runtime packages, containers, and deployment pipelines. |
[th]
Platform
[/th][th]
Why it matters
[/th]Using an affected version doesn’t prove that a website has been compromised. Nevertheless, organizations should treat the issue as urgent and verify the status of exposed systems.
How to Protect a PHP Website From These Vulnerabilities
1. Inventory all PHP installations
Start by identifying PHP across production, staging, development, and other relevant environments. Include internet-facing websites, PHP-FPM services, Apache deployments using
mod_php, CGI-based deployments, container images, and third-party products that bundle PHP. Don’t limit the search to obviously outdated websites. The NCSC specifically recommends identifying systems running PHP generally because the issue affects multiple versions.2. Verify the active PHP runtime
Administrators can use the command below to inspect the command-line PHP installation. It doesn’t necessarily identify the PHP version serving a website, though. A server may have different PHP installations for the command line, PHP-FPM, Apache, or individual containers. Check the actual web-serving configuration, installed packages, and vendor security notices before deciding that a system is patched.
php -v
3. Install the appropriate security update
Upgrade to the relevant fixed release or install a verified vendor package containing the security fix. Before making production changes, test application compatibility where feasible. Check framework requirements, extensions, and dependencies, and maintain a tested recovery plan. The update must reach the runtime that actually processes requests. Depending on the deployment, this may involve updating PHP-FPM, replacing an Apache PHP module, updating a container image, or redeploying a cloud application.
4. Restart services and verify deployment
After patching, follow the PHP and hosting vendor’s instructions for restarting or redeploying affected services. Long-running workers may continue using an older runtime until they are restarted or replaced. Containerized applications may also continue running vulnerable images if the deployment pipeline doesn’t replace existing workloads. Verify the running version and package status after deployment. A successful package installation isn’t sufficient evidence that every application has been updated.
5. Treat temporary mitigations as temporary
The PHP team has published additional hardening measures for situations where an immediate upgrade isn’t possible. These measures address particular vulnerable execution paths and may require changes to PHP configuration or request handling. Apply them according to the official advisory and test them against the application’s requirements. They shouldn’t be assumed to eliminate the underlying vulnerability. The PHP project states that updating is the only complete solution. If an exposed system can’t be patched or adequately mitigated, assess whether it needs to be isolated or taken offline until the risk can be addressed.
6. Check for signs of compromise
If a vulnerable system was exposed before remediation, review available logs and monitoring data for suspicious activity. Investigate unexpected processes, unfamiliar files, unauthorized accounts, unusual outbound connections, and changes to application or server configuration. Preserve relevant evidence if an incident is suspected. Depending on the findings, response actions may include isolating the affected system, rotating exposed credentials, restoring trusted software, and rebuilding compromised infrastructure. A clean-looking log doesn’t guarantee that a system has never been compromised. If internal teams lack the required expertise, seek assistance from a qualified incident response provider.
Not Sure Which PHP Runtime Is Serving Your Site?
Elsner’s team can help you inventory PHP across your environments, confirm what’s actually running in production, and plan a tested update without disrupting your store or application.
Talk to Elsner About PHP Security
How Hosting Providers and Development Teams Should Coordinate
Responsibility for PHP security is often divided between application developers, hosting providers, and infrastructure teams.
A website owner may manage WordPress content and plugins while the hosting provider controls the PHP runtime. In a custom deployment, developers may maintain application code while another team manages servers, containers, and updates. This separation can leave gaps unless responsibilities are clear. Organizations should establish who will:
Identify affected PHP installations and prioritize exposed systems.
Apply the update and confirm that the correct runtime is active.
Test application functionality after deployment.
Monitor for suspicious activity and investigate possible compromise.
Businesses using managed hosting should request confirmation of the relevant patch status rather than assume that updates have been applied automatically. Teams without in-house capacity often hand this routine to a partner offering ecommerce maintenance, so runtime updates don’t depend on someone remembering to check.
Frequently Asked Questions
Can updating WordPress fix these PHP vulnerabilities?
Not necessarily. Updating WordPress core and plugins doesn’t automatically update the PHP runtime. The underlying PHP installation must also be patched or covered by a verified vendor security update.
Which PHP versions contain the official fixes?
The PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 with fixes for these vulnerabilities. Vendor-maintained packages should be checked separately.
Can these vulnerabilities be exploited without logging in?
Yes. The PHP advisory identifies potential unauthenticated remote code execution under certain conditions. The exact exposure depends on the deployment and the vulnerable request-processing paths.
Are these vulnerabilities being exploited?
NCSC New Zealand says it is aware of reports of active exploitation. Treat exposed systems as a priority and check current guidance from your national cyber agency and the PHP project.
Are temporary security measures a complete fix?
No. Temporary mitigations may reduce exposure to specific attack paths, but the PHP team identifies updating to a fixed version as the complete remediation.
What if I run PHP 8.1 or older?
Those branches no longer receive regular upstream security updates. Ask your operating-system or long-term support vendor to confirm a backported fix, or plan an upgrade to a supported release.
What should a business do if its website may already be compromised?
The business should investigate the affected environment, preserve relevant evidence, and follow an incident response process. Depending on the findings, containment, credential rotation, and system recovery may be necessary.
Conclusion
CVE-2026-109618 and CVE-2026-109619 highlight the security risks that can arise from defects in a widely used application runtime. Because PHP supports many websites and business applications, organizations should identify affected installations, apply the appropriate security updates, and verify that patched runtimes are actively serving requests.
Patching should be accompanied by careful deployment checks, appropriate access controls, monitoring, and investigation of potentially exposed systems. For businesses operating PHP-based ecommerce platforms and websites, a clear process for handling critical vulnerabilities can reduce the likelihood of avoidable security incidents.
Need Help Patching or Auditing Your PHP Environment?
If you’d like a second pair of eyes on your PHP versions, hosting setup and deployment pipeline, Elsner can help you verify exposure and plan a safe fix.
Contact Elsner
The post Critical PHP Vulnerabilities: Risks, Affected Versions, and Security Fixes first appeared on Elsner Technologies Pvt. Ltd..