Critical PHP Vulnerabilities October 2026

On 21 October 2026, the PHP Security Team released emergency security updates addressing two critical vulnerabilities:

• CVE-2026-109618: A memory corruption vulnerability that could allow attackers to execute malicious code remotely.
• CVE-2026-109619: A vulnerability involving leftover internal memory state that could allow remote code execution.

Both vulnerabilities carry a CVSS 9.2 (Critical) severity rating and may allow attackers to compromise vulnerable web servers without requiring a login.

These vulnerabilities affect websites running PHP, including those powered by WordPress, Joomla, Drupal and other PHP-based applications.

Here are our recommendations for website owners and administrators.

1. Upgrade to PHP 8.2 or Above — With the Latest Security Patches

The most effective protection is to upgrade your website to a supported, security-patched PHP release.

The PHP Security Team has released fixes in the following versions:

PHP Branch	Minimum Patched Version
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

If your website is already running PHP 8.2 or newer, verify that the latest security updates have been installed. Simply using PHP 8.2, 8.3, 8.4 or 8.5 without the relevant patches is insufficient.

We recommend PHP 8.4 or 8.5 where your website supports it. PHP 8.2 will reach end of security support on 31 December 2026.

Before upgrading, back up your website and database, and check that your themes, plugins and applications are compatible with the newer PHP version.

Important: Restart all PHP processes after updating.

Updating PHP packages or changing the PHP version does not necessarily terminate existing PHP worker processes.

Administrators should ensure that old PHP processes are stopped and the relevant PHP services, such as PHP-FPM, LSAPI, Apache or LiteSpeed, are properly restarted. This ensures that requests are handled by the updated PHP runtime rather than potentially vulnerable processes still running in memory.

After upgrading, carry out visual and functional testing of your website, including contact forms, login functions, payment gateways and other important features.

2. How to Reduce Security Risks If You Are Still Running PHP 8.1, 7.x or 5.x

Many older websites depend on legacy PHP versions because their applications, plugins or custom code are incompatible with newer releases.

Unfortunately, PHP 8.1 and earlier have reached end of life and no longer receive official security releases from the PHP project.

If upgrading immediately is not possible, we recommend implementing the following security measures.

A. Consider commercial Hardened PHP support

Solutions such as CloudLinux Hardened PHP and TuxCare Extended Lifecycle Support can provide security patches for older PHP versions.

CloudLinux has released backported fixes addressing these two CVEs for its supported legacy PHP packages, including PHP 5.x, 7.x and 8.1.

However, administrators must update the relevant packages and verify that the fixes have been installed. A legacy PHP version number alone does not indicate whether the vendor’s security backport is present.

Enable Web Application Firewall (WAF) protection

Use a properly configured WAF, such as Cloudflare WAF or Imunify360, with current security rules to reduce exposure to known attack patterns.

Imunify360 has already released rules targeting exploit attempts associated with these vulnerabilities, including protections for LiteSpeed environments.

A WAF provides an additional security layer but does not eliminate vulnerabilities within PHP itself.

B. Strengthen server security and monitoring

Keep your CMS, themes, plugins and operating system updated. Restrict unnecessary network access, minimise PHP process privileges, monitor suspicious activities and maintain tested offsite backups.

Where possible, isolate legacy applications from other websites and critical systems.

C. Disable PHP Session Upload Progress

One confirmed exploitation path involves PHP’s session upload progress functionality.

Administrators should consider disabling it in the server-level PHP configuration:

session.upload_progress.enabled = 0

Apply the setting in a configuration effective before request parsing, and restart all PHP worker processes after making the change.

Potential disadvantages and application impact:

• Applications that depend on PHP’s session-based upload progress tracking may stop displaying accurate upload progress.
• Upload progress bars may remain at 0%, freeze or disappear, even when uploads are proceeding normally.
• Applications using PHP session-based upload cancellation may lose that functionality.
• Custom-built file managers, document management systems or older applications that rely on this PHP feature may require modifications.

Important: Disabling this feature does not normally prevent files from being uploaded. Modern applications using browser-based upload progress tracking may remain unaffected.

Recommendation: This is generally a relatively low-impact mitigation for websites that do not explicitly rely on PHP’s session upload progress feature. Nevertheless, test all important file upload and document management functions after implementation.

D. Restrict HTTP POST Requests and File Uploads

Limiting HTTP POST request sizes can reduce exposure to certain attack techniques involving excessively large or complex requests.

The PHP Security Team suggests considering:

• post_max_size = 8M for applications that do not require file uploads.
• post_max_size = 32M for applications requiring uploads, where appropriate.
• Keeping upload_max_filesize below post_max_size.

Additional limits can be enforced at the web server or reverse proxy, including request body sizes and multipart form complexity.

Potential disadvantages and application impact:

• File uploads may fail: Users might be unable to upload large images, videos, documents or email attachments through web applications.
• Website administration may be affected: WordPress plugin uploads, theme installations, backup restorations and other administrative activities may fail if their request sizes exceed the configured limits.
• Online forms and e-commerce functions: Applications submitting large POST requests may fail validation or reject legitimate submissions, potentially affecting checkout processes or other transactions.
• API integrations: Third-party integrations, import tools and webhook endpoints may encounter errors if request size limits are too restrictive.
• Unexpected application errors: When PHP’s post_max_size is exceeded, PHP may leave $_POST and $_FILES empty. Depending on the application, users may receive misleading messages such as missing form fields or failed uploads. A web server or proxy may instead return HTTP 413.

Recommendation: Avoid applying excessively restrictive limits without understanding the application’s requirements.

For websites that support document uploads, backups, imports or e-commerce, review actual request sizes before changing these settings.

Test contact forms, file uploads, payment workflows, administrative functions and integrations after implementation.

E. Review PHP Memory Limits Carefully

For CVE-2026-109618, the PHP Security Team identifies the following setting as a possible temporary mitigation against a specific out-of-memory exploitation path:

memory_limit = -1

This removes PHP’s per-script memory limit, preventing the particular PHP memory-limit failure involved in the confirmed attack path.

However, it does not prevent all memory allocation failures and therefore does not completely eliminate the vulnerability.

Potential disadvantages and application impact:

• Excessive memory consumption: Without a PHP memory limit, poorly written applications, infinite loops or malicious requests may consume substantially more server memory.
• Server instability: Heavy memory consumption can cause severe performance degradation, excessive swapping, process termination or even server-wide outages.
• Impact on other websites: On shared hosting servers, one application consuming excessive memory may affect other customers if effective operating-system-level isolation is not in place.
• Unexpected application failures: PHP workers may be terminated by the operating system when memory is exhausted. Users may experience HTTP 500, 502 or 503 errors, failed transactions or interrupted operations.
• Denial-of-service risk: Attackers may exploit unrestricted memory consumption to exhaust server resources and disrupt legitimate traffic.

Recommendation: Do not apply memory_limit = -1 across an entire shared hosting server without first assessing the risks.

If this mitigation is necessary, use suitable process isolation and operating-system-level resource controls, such as cgroups, configured to contain failures to the affected worker wherever possible.

CloudLinux administrators should review LVE isolation and resource limits carefully rather than assuming that removing PHP’s memory limit is harmless.

This is a temporary risk-reduction measure for experienced administrators, not a substitute for installing security patches.

Our Recommendation

If your website can support PHP 8.4 or 8.5, upgrading to a fully patched release should be your priority.

If your website must remain on PHP 8.1, PHP 7.x or PHP 5.x, use a reputable vendor that provides verified security backports, together with additional security controls.

These temporary measures reduce risk but do not guarantee complete protection. Long-term migration to a supported PHP version remains the recommended approach.