Table of contents

  1. What vulnerabilities were discovered?
    1. CVE-2026-109618: Memory corruption when resources are exhausted
    2. CVE-2026-109619: Reuse of stale internal state
  2. Why is this dangerous for Joomla?
  3. Which PHP versions should you install?
  4. What should website owners do right now?
    1. Step 1: Find out which PHP version your website actually uses
    2. Step 2: Install a patched release
    3. Step 3: Fully restart PHP
    4. Step 4: Test your website after updating
    5. Step 5: Check for signs of a possible compromise
  5. What should you do with an outdated Joomla website and an unsupported PHP version?
  6. Our Joomla upgrade service
  7. Additional security measures

On October 21, 2026, the PHP developers released emergency security updates addressing two critical remote code execution (RCE) vulnerabilities: CVE-2026-109618 and CVE-2026-109619.

Both vulnerabilities have a CVSS 4.0 score of 9.2 and could allow an unauthenticated attacker to execute arbitrary code on a server. An attacker does not necessarily need an administrator password or an account on the website.

Fixes are available in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The PHP developers specifically warn that there is no comprehensive mitigation without updating: temporary restrictions may reduce the attack surface, but they do not fully address both vulnerabilities.

Critical warning!
If your website runs on PHP 8.2–8.5, check not only the PHP version branch but also the exact patch release. For example, PHP 8.3.35 remains vulnerable; the fix is included only in PHP 8.3.36 and later.

What vulnerabilities were discovered?

These issues are not in Joomla or an individual extension: they exist in the PHP interpreter itself. PHP processes virtually every request to a PHP-powered website, so the vulnerability exists below the content management system and its security plugins.

CVE-2026-109618: Memory corruption when resources are exhausted

The first vulnerability involves how PHP handles running out of available memory while parsing an incoming HTTP request.

Under certain conditions, an attacker can send a specially crafted request, including one involving multipart form data and file uploads. PHP aborts processing because of memory exhaustion while internal request structures have not yet been fully initialized. During cleanup, PHP may mistakenly treat corrupted data as valid.

Potential consequences include:

  • Corruption of the PHP process's memory;
  • Execution of arbitrary code with the web server user's privileges;
  • Reading and modifying website files;
  • Access to configuration files and databases;
  • Installation of backdoors and further compromise of the server.

Exploitation of CVE-2026-109618 over HTTP has been confirmed for Apache with mod_php under default resource limits. Other configurations, including PHP-FPM, are also within the scope of the risk.

CVE-2026-109619: Reuse of stale internal state

The second vulnerability involves PHP's global state, which may persist after a request ends even though the memory it referenced has already been freed.

Exploitation involves two stages:

  1. The first request leaves behind an invalid internal state.
  2. A subsequent request reaches the same PHP worker process and uses stale data before normal initialization has a chance to reset it.

This is a type of use-after-free flaw that can lead to code execution. Confirmed exploitation paths include PHP session upload progress handling and certain diagnostic messages generated before a request has been fully initialized.

The session.upload_progress attack path has been confirmed for both mod_php and PHP-FPM. However, disabling this feature blocks only one known scenario and is not a complete fix.

Why is this dangerous for Joomla?

A typical vulnerability in an extension exists within the CMS: to exploit it, a request must reach Joomla and pass through part of its application logic. In this case, the attack targets PHP itself, which starts processing the request before the website's code runs.

This means the following measures may not protect against these vulnerabilities:

  • A strong administrator password;
  • Multi-factor authentication;
  • A hidden administrator login URL;
  • A security plugin installed in Joomla;
  • Disabling user registration;
  • Restricting the permissions of ordinary user accounts.

The PHP developers consider the risk particularly high for servers running Apache with mod_php: a confirmed attack scenario allows an unauthenticated request to trigger the vulnerability before application code executes.

What about Cloudflare and WAFs?
A web application firewall can block some known malicious requests, but it is only a temporary additional barrier. If the server can be accessed directly by IP address, or a new attack variant emerges, WAF rules may be bypassed. The proper solution is to install a patched PHP version.

Which PHP versions should you install?

The secure patch release depends on the PHP branch your website uses:

  • PHP 8.5: Update to 8.5.12 or later.
  • PHP 8.4: Update to 8.4.27 or later.
  • PHP 8.3: Update to 8.3.36 or later.
  • PHP 8.2: Update to 8.2.35 or later, and plan a move to a newer supported branch.
  • PHP 8.1 and earlier: No ready-to-install official fixed release is available from the PHP project.

The last vulnerable patch releases in the supported branches are PHP 8.2.34, 8.3.35, 8.4.26, and 8.5.11.

For PHP 8.1, 8.0, and 7.4
The PHP project has published minimal fixes in separate source-code branches, but it has not released ready-to-install official packages or binary builds. These fixes are intended primarily for distribution maintainers, long-term support (LTS) providers, and administrators who compile PHP themselves. Website owners using shared hosting should ask their provider whether these fixes have been applied or migrate to a supported PHP version.

PHP 8.2 receives security updates only and will reach end of support on December 31, 2026. Therefore, updating to PHP 8.2.35 addresses the immediate problem but is not a long-term strategy.

What should website owners do right now?

Step 1: Find out which PHP version your website actually uses

Check the version in your hosting control panel or in Joomla under System → System Information. Be sure to check the PHP interpreter that serves web requests: the command-line version shown by php -v on a VPS may differ from the PHP-FPM or Apache version used by the website.

Step 2: Install a patched release

If your website already runs on PHP 8.2, 8.3, 8.4, or 8.5, select the corresponding patched version in your hosting panel. Updating within the same branch—for example, from PHP 8.3.35 to 8.3.36—is a patch-level update and usually does not require changes to website code.

If the patched version is not available in your hosting panel, contact your hosting provider's support team and ask when a secure build will be installed.

A note on Linux distributions
Ubuntu, Debian, Red Hat, and some LTS vendors may backport security fixes into their own packages without changing the upstream PHP version number to the release listed on php.net. In that case, ask your hosting provider to confirm that CVE-2026-109618 and CVE-2026-109619 have been addressed, citing the package changelog or a security advisory.

Step 3: Fully restart PHP

After installing the updated packages, restart all PHP worker processes. For PHP-FPM, this usually means restarting the appropriate service. If you use mod_php, you may need to stop and start Apache completely, because a graceful reload can leave the old library loaded in memory.

Step 4: Test your website after updating

  1. Open the home page and several internal pages.
  2. Check that you can log in to the administration panel.
  3. Submit test forms and send test emails.
  4. Test image and document uploads.
  5. Verify that your online store, search, and other essential components work.
  6. Review the PHP error log after switching versions.

Step 5: Check for signs of a possible compromise

At the time of writing, reports of active exploitation are conflicting, so it is not possible to state with confidence that widespread attacks have been confirmed. However, once fixes are published, attackers may quickly analyze the changes and develop working exploits.

Check for:

  • Unknown PHP files in /images, /media, /tmp, /cache, and upload directories;
  • Recently modified Joomla or WordPress system files;
  • Unknown administrator accounts;
  • Suspicious cron jobs and running processes;
  • Unusual outbound connections and spikes in server load;
  • Requests containing unusually large or malformed multipart data in web server logs.

What should you do with an outdated Joomla website and an unsupported PHP version?

The main problem with older websites goes beyond these two CVEs. Joomla 3, outdated extensions, and unsupported PHP versions no longer receive a full range of official security fixes. Even if a hosting provider temporarily backports a particular fix to PHP 7.4 or 8.1, the next critical vulnerability may remain unpatched.

When a website remains exposed to the internet for years, attacks do not stop: automated scanners look for known vulnerabilities in Joomla, extensions, templates, and PHP every day. The longer a system remains unsupported, the more unpatched entry points can accumulate.

Delaying updates is dangerous
No one can predict the exact day a particular website will be hacked. But if a public website continues to run an outdated Joomla version and unsupported PHP without an upgrade plan, the risk increases over time. Sooner or later, a single unpatched vulnerability, stolen password, or vulnerable extension may be enough to compromise it. It is better to address upgrades before an incident than after losing data and damaging your reputation.

Simply switching an old Joomla installation to a newer PHP version can cause errors. A safe migration usually requires:

  • Creating a complete backup;
  • Auditing components, modules, plugins, and the template;
  • Replacing abandoned extensions;
  • Updating Joomla in the appropriate sequence;
  • Testing the website on a staging copy;
  • Switching to a supported PHP version;
  • Performing final checks after the migration.

Our Joomla upgrade service

If your website runs an outdated Joomla version or is incompatible with a modern PHP release, we can carry out a comprehensive upgrade. We will review your extensions and template, prepare backup and staging copies, plan the migration steps, and help move your website to an up-to-date Joomla release and a supported PHP version.

Learn more about our service: Joomla website upgrades and migration.

It is especially important to plan an upgrade in advance if your website uses Joomla 3, PHP 7.4, PHP 8.0, or PHP 8.1. Waiting for the next critical vulnerability leaves too little time for careful compatibility testing and migration.

Additional security measures

  • Update Joomla and all extensions to current releases.
  • Remove unused components, plugins, and templates rather than simply disabling them.
  • Enable multi-factor authentication for administrators.
  • Restrict direct access to the origin server if the website is protected by a CDN or WAF.
  • Keep backups separate from the website and test your ability to restore them.
  • Monitor file changes and configure alerts for newly created administrator accounts.
  • Check your PHP version regularly: the major/minor branch alone is not enough; the exact patch release matters.

Submit a request List of services

Postscript
Forewarned is forearmed! Cyberattacks and website compromises will undoubtedly continue, but taking these security measures now can significantly reduce your risks.

Terms used:

Package, Apache, CMS, PHP, Authentication, Backup