SecurityOct 21, 2026 5 min read

Critical PHP Vulnerabilities (CVE-2026-109618, CVE-2026-109619)

The PHP security team has announced two critical vulnerabilities. As rConfig runs on PHP, we’re urging customers to contact their IT teams now and prepare to apply the security update as soon as it becomes available. As a precaution, we’ve locked down our own system while we await the patch. Keeping software up to date is a shared responsibility. Internal installations should also be reviewed, even where public internet access is restricted.

rConfigAll at rConfig

Critical PHP Vulnerabilities (CVE-2026-109618, CVE-2026-109619): What rConfig Users Need to Know

Two critical PHP vulnerabilities were disclosed this week, and the PHP project released the fixed versions on 21 October. The fix may still take longer to reach your package repository. Here is where things stand.

This is a live document. We are updating it as the situation develops, so please come back

This is a live document. We are updating it as the situation develops, so please come back to this page for the latest. Last updated: 21 October 2026, 15:26 IST (14:26 UTC).

What happened

On 20 October 2026, CERT-EU published Security Advisory 2026-018, "Critical Vulnerabilities in PHP". It covers two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both scored 9.2 on the CVSS scale. CERT-EU does not report any exploitation.

On 21 October 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and published its own advisories for both issues. They confirm that either can allow unauthenticated remote code execution:

CVE-2026-109618: a memory-handling flaw, where out-of-memory handling can interrupt PHP while request data is only partly initialised.
CVE-2026-109619: request state that survives after its memory has been freed, and is then used by a later request on the same worker.

What the PHP project says

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs.

Updating PHP is the only complete solution. Configuration changes reduce exposure to specific attack paths, but do not make an installation safe.

Older PHP. PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, and the PHP security team provided minimal source backports for 7.4, 8.0 and 8.1. Otherwise, upgrade to a supported version. PHP 8.2 itself reaches end of life on 31 December 2026.

Package availability. Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. The project says the volunteer-maintained Remi repository will not have updates today, and urges people who rely on it to switch to distribution packages or build from source.

What is still unconfirmed

rConfig. rConfig runs on PHP, and we have not yet confirmed whether, or how, it is affected. We are working out which PHP version each rConfig release runs on, and we will test each one against the fixed PHP releases. Until we publish a status, treat every version as potentially exposed.

PHP 5 and the oldest branches. CERT-EU reports, citing posts on social media, that all versions from PHP 5 onwards could be affected. The PHP project has not confirmed that scope.

What it means for rConfig

The patch comes from PHP. PHP is the runtime rConfig runs on, installed on your own server. The fix is applied there, by updating PHP, and we are testing every rConfig version against it.

As a precaution, we have already taken some of our own systems out of public reach: our public demo hostnames (enterprise-demo, msp-demo, isp-demo, edu-demo and sme-demo on rconfig.com) and crm.rconfig.com now redirect to www.rconfig.com.

What we would do today

1. Find the PHP on your rConfig server. Identify the PHP-based applications in your environment, starting with the host that runs rConfig, and check which PHP version it uses.

2. Update PHP as soon as your vendor's package is available. Use your operating system's package manager (or your container image, if you run rConfig in one), restart the web service, and check that rConfig still works.

3. Until then, keep rConfig off the public internet. If you cannot patch immediately, isolate internet-facing PHP applications from public networks. rConfig should not need to be reachable from the internet, so restrict access to your management network.

If you cannot update yet, the PHP project suggests these measures, which reduce exposure but are not a fix:

For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, and set a low post_max_size (8M if you do not need file uploads, 32M if you do), keeping upload_max_filesize below it.

For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every PHP worker. On PHP 8.5, also set fatal_error_backtraces=0.

Expect a gap between the release and your package. Most servers do not install PHP from the PHP project directly. They get it from a distribution or a third-party repository, and those can take longer to ship the update. The PHP project said the Remi repository would not have updates today, and the availability of the Ubuntu PPA is not yet confirmed. We will update this post when each source is confirmed. Your distribution's own packages may be available sooner, so check your vendor first. Until your server has the fixed version, keep rConfig restricted as described in step 3.

The last step is worth doing whatever the outcome of this advisory. A configuration management server holds credentials and device configurations, and it belongs behind your management network.

Follow the advisory

This is a developing situation, so this post is a live document that we keep updating, and the advisory is the source of truth. Come back to either page for updates. We will update rCFG-SA-2026-01 https://www.rconfig.com/security-advisories/php-2026-10 as each rConfig version is tested, and every change is recorded in its update log.

To report a finding or ask about your deployment, email security@rconfig.com. Our security advisories and disclosure policy page has the details.https://www.rconfig.com/security-advisories

Sources

https://cert.europa.eu/publications/security-advisories/2026-018/

https://www.php.net/archive/2026.php

https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

This is a live document. It is based on the information available at the time shown above, which may be incomplete or change, and it will be updated as we confirm more.

Request a demo