Last reviewed: 22 October 2026. This guide explains the confirmed vulnerabilities and gives website owners a practical response plan. Hosting packages and advisories can change; verify your provider’s current guidance before applying server changes.

CVE-2026-109618 and CVE-2026-109619 are vulnerabilities in PHP, the server software behind many business websites. A successful attack can let someone run unauthorised code without signing in. PHP released security updates on 21 October 2026. If your website uses PHP, ask your host to confirm that both fixes are installed and active.

You do not need to understand programming to take the right first step. You need to identify who manages your server, obtain evidence of the fix, and test your website afterwards. Updating WordPress, changing a password or installing a security plugin does not replace updating the affected PHP runtime.

Source: ENISA’s joint statement on the PHP vulnerabilities.

What should a website owner do right now?

1. Contact the person responsible for hosting. Ask specifically about CVE-2026-109618 and CVE-2026-109619.
2. Request a patched PHP build. Ask for the exact version or vendor package revision, not simply “PHP 8 is enabled”.
3. Confirm deployment. Ask whether every relevant PHP worker has been restarted and every server serving your site has received the update.
4. If patching is delayed, agree on temporary protection. Set a deadline and decide whether public access must be restricted until the server is fixed.
5. Test business functions and retain the confirmation. Record the change time, package details and any remaining issues.

What is PHP, and what does a CVE mean?

PHP runs on the hosting server. When someone visits a dynamic website, PHP can retrieve information, process a form and assemble the page. WordPress is the application; PHP is part of the software that executes it. An up-to-date application can therefore still run on an unsafe underlying runtime.

A CVE is a public identifier for a disclosed vulnerability. The two numbers identify different defects, so a useful hosting response must address both. “Remote code execution”, often shortened to RCE, means an attacker can cause a system to execute code remotely. “Unauthenticated” means an account or administrator password is not required.

What do these two vulnerabilities actually do?

CVE-2026-109618: unsafe handling of memory exhaustion

PHP temporarily prepares internal information while processing a request. If memory allocation fails at a sensitive moment, its error handling can leave that information incomplete. Cleanup may then treat invalid memory as usable, allowing memory corruption and potentially code execution. Think of it as a process interrupted halfway through, followed by a cleanup routine that wrongly assumes preparation finished.

Red Hat’s CVE-2026-109618 explanation describes the memory-handling defect. PHP’s own advisory confirms a complete attack against Apache’s mod_php before application code runs; other environments have different conditions. This is why protecting only the WordPress login page does not address the underlying problem.

CVE-2026-109619: reusing information after its memory has been released

A PHP worker is a process that handles web requests. Some information kept by that worker can still refer to memory belonging to an earlier request. If a fatal error interrupts cleanup, a later operation may use that old reference after the memory has been released. This is called a “use-after-free”.

Red Hat’s CVE-2026-109619 explanation describes this stale-state problem. The practical concern is that a failure in one request can affect processing later in the same worker, rather than ending cleanly with a harmless error page.

How serious are they?

The PHP project rates both critical, with CVSS v4.0 scores of 9.2. This is a severity rating, not a prediction that 92% of websites will be hacked. Exploitability depends on the runtime, configuration and application. PHP identifies Apache mod_php as particularly exposed, but also includes PHP-FPM, php-cgi, FrankenPHP and LiteSpeed in its update guidance.

Source: PHP’s security announcement and update guidance.

Who needs to check their website?

Owners of WordPress and WooCommerce sites, other PHP-based content management systems, and custom PHP applications should ask their hosting provider to assess their runtime. Include smaller sites: a brochure site may still execute PHP even if it has no shop, customer accounts or visible upload form.

Inventory every deployment you control: the main domain, subdomains, staging copies, old installations, booking applications, customer portals and administrative tools. A redesigned homepage does not tell you what older software remains reachable on the same hosting account.

Agencies should create one tracking row per client environment. Record the hosting owner, runtime, patch evidence, restart status, testing result and unresolved action. Avoid treating one provider’s general announcement as confirmation for every account.

A genuinely static site with no PHP endpoint does not expose these PHP flaws through its static files. However, hidden administrative components may still use PHP. ENISA advises checking products that embed PHP even when that dependency is not obvious.

What could happen to an affected business?

The immediate security boundary is the PHP worker’s permissions. Successful exploitation can expose data accessible to that process, allow unauthorised code execution or disrupt service. It does not automatically mean an attacker obtains root access to the entire server. AWS’s security bulletin describes this application-level scope.

For a website owner, plausible consequences include altered pages, malicious redirects, stolen configuration secrets, misuse of database credentials, or unavailable forms and checkout. These are potential outcomes of compromise, not proof that they have happened to your website.

Consider the practical dependencies. If an application can read a customer database or an API credential, protecting that application matters even when payment processing happens elsewhere. A working homepage alone cannot establish that the system is uncompromised.

Which PHP versions contain the fixes?

The following are the first fixed upstream releases in the supported branches, as listed in AWS’s affected-version table:

PHP branch	Affected upstream releases	First fixed release
8.2	8.2.0–8.2.34	8.2.35
8.3	8.3.0–8.3.35	8.3.36
8.4	8.4.0–8.4.26	8.4.27
8.5	8.5.0–8.5.11	8.5.12

Use these releases or a later supported release containing the fixes. Vendor backports are an important exception to a simple version comparison. A provider can repair an older package without changing its upstream-looking version number.

For example, CloudLinux’s package notice explains that its patched packages can retain lower version numbers and should be checked against package changelogs. Plesk’s advisory also lists repaired Linux builds of PHP 7.4.33, 8.0.30 and 8.1.34 dated 21 October 2026 with unchanged version numbers.

PHP 8.1 and older no longer receive ordinary upstream releases. PHP has provided minimal source backports for 7.4, 8.0 and 8.1, and vendors may supply supported packages. These exceptions do not restore normal upstream support. Ask for explicit coverage of both CVEs and plan migration to a maintained branch.

How to check the PHP version your website actually uses

For WordPress owners

1. Sign in to your WordPress dashboard.
2. Open Tools → Site Health → Info.
3. Expand Server and record the PHP version and available server information.
4. Send those details to your hosting provider and ask whether a vendor backport applies.

The WordPress Site Health documentation explains where these server details are shown. Site Health displays information; it does not install the PHP security update.

For server administrators

Check the runtime serving the actual domain, not only the default command-line executable. A command such as php -v can report a different PHP installation from the one handling web traffic. Multi-version hosting requires checking each active handler and pool. CloudLinux specifically cautions that command-line configuration may differ from the web runtime.

Use an authenticated diagnostic route or the provider’s tools. Do not leave a publicly accessible PHP information page behind: detailed configuration output should not become a permanent public resource.

How to apply the permanent fix

Shared or managed hosting

Open an urgent support request with both CVE identifiers. If your hosting panel only offers “8.3” or “8.4”, ask which exact package revision backs that option. A branch selector is not sufficient patch evidence. The host may need to update centrally before your account can use the corrected build.

Request confirmation for the live domain, staging domains and any additional applications. Agree who will test the website and who will respond if compatibility issues appear.

VPS, dedicated server or container hosting

Have the administrator apply the appropriate vendor packages, or deploy a verified rebuilt image containing the fixes. Replace affected running instances and ensure old replicas do not continue receiving traffic. Update deployment templates too, so the next restart or scaling event does not recreate the vulnerable image.

For Plesk, review both the website PHP handlers and the control panel’s own PHP engine. Plesk’s advisory identifies separate updates for its sw-engine component; updating a single website’s handler is not a substitute for following the full vendor advisory.

Test without leaving the site exposed indefinitely

Make a recoverable backup and perform a focused compatibility check. Where feasible, a patched release within the existing supported branch can avoid combining emergency remediation with a larger migration.

Test the homepage, administrator login, contact forms, uploads, search, booking flow, account area and checkout where applicable. Use payment sandbox facilities or an agreed test procedure. Check outgoing notifications and scheduled jobs. If something fails, investigate the component or move to another patched compatible environment; do not silently restore public service on an unpatched runtime.

What if the update is not available on your server?

There is no configuration-only fix that makes every affected installation safe. Temporary controls reduce specific attack paths while you arrange a patched runtime. They need an owner, a deadline and a verification step.

1. Restrict exposure before requests reach PHP

ENISA’s joint guidance recommends considering isolation from public networks when immediate remediation is impossible. A host can restrict access at the reverse proxy, firewall or web server, or serve a genuinely static maintenance response without forwarding traffic to PHP.

A WordPress maintenance plugin still requires PHP to run. It is therefore not an equivalent containment measure. Blocking only /wp-admin/ also leaves public application routes reachable. Ask the administrator to include direct origin access, alternate hostnames and other entry points in the restriction.

2. Disable the confirmed session upload-progress path

PHP’s advisory recommends the following startup-level setting, followed by restarting every worker:

session.upload_progress.enabled=0

Apply it through php.ini, an FPM pool or server configuration effective before request parsing. Do not rely on application ini_set() calls or FPM .user.ini. It blocks confirmed session-related paths of CVE-2026-109619, not every variant. On PHP 8.5, disabling fatal_error_backtraces also blocks the confirmed backtrace path:

; PHP 8.5 only
fatal_error_backtraces=0

Source: PHP’s stale-state advisory. Have the administrator verify effective settings after restart and test any upload-progress functionality your application uses.

3. Treat the memory workaround as an administrator task

For CVE-2026-109618, PHP describes administratively enforcing memory_limit=-1 to remove the predictable PHP-level memory-limit failure. This is incomplete protection and removes PHP’s per-request memory cap. Underlying allocation failures remain possible. Do not apply it casually on shared hosting or without capacity controls.

The administrator should review container or cgroup boundaries and request limits together. PHP explicitly warns against substituting RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation-failure path. The official out-of-memory advisory explains these trade-offs.

4. Reduce request size and complexity at the server edge

CERT-EU’s mitigation guidance includes conservative POST limits: post_max_size=8M when uploads are unnecessary, or 32M when needed, with upload_max_filesize below that limit. These are interim starting points, not universal values for every application.

Limits should also address decoded body size, input counts, multipart parts, headers and nesting, including requests without a usable content length. Have the host implement the appropriate controls and test real submissions. A limit that interrupts legitimate orders or document uploads needs adjustment, not an unexplained failure left for customers to discover.

5. Use firewall rules as an additional layer

A web application firewall may block known exploit patterns, but its coverage depends on the provider and rule set. CloudLinux explicitly states that its discussed Imunify360 rules do not cover every path and are interim protection. Ask what is blocked, whether rules are in blocking mode, and whether the origin can be reached around the firewall. Do not accept “we have a WAF” as evidence that PHP is patched.

What does not fix these vulnerabilities?

• Updating only WordPress, themes or plugins: these changes do not replace the server’s PHP runtime.
• Changing administrator passwords: useful in the right context, but these vulnerabilities do not require an administrator login.
• Enabling HTTPS: encryption does not repair unsafe processing on the server.
• Hiding error messages: suppressing a message does not correct the underlying memory or lifecycle defect.
• Restarting without installing a fix: the vulnerable software starts again.
• Seeing no suspicious entries in logs: absence of a visible error is not proof that the installation is safe.

PHP’s technical guidance specifically warns that log review and configuration measures cannot establish complete protection.

What should you ask your hosting provider?

Copy this into a support ticket and add your domain:

Please confirm whether the PHP runtime serving my website is patched against both CVE-2026-109618 and CVE-2026-109619.

Please provide the installed PHP version and full package/build revision, the vendor advisory or changelog confirming both fixes, and confirmation that all relevant workers and servers have been restarted or replaced.

If a complete fix is not yet active, please explain the temporary controls, their limitations, whether public access should be restricted, and the expected deployment time. Please include my additional domains and staging environments in the review.

A useful answer names the installed build and completion time. “We are monitoring the issue” describes activity, not resolution. Keep the ticket until the deployment and your business-function checks are complete.

What if you suspect the website was already compromised?

Patching closes a vulnerability; it does not undo an earlier intrusion. Treat unexpected administrator accounts, changed files, unexplained redirects, unfamiliar scheduled tasks or abnormal outbound activity as reasons to investigate. These signs are not unique to these CVEs.

As a practical incident-response plan, isolate the affected environment, preserve available logs and snapshots, and involve the host or a qualified responder. Establish what changed before deleting evidence. Recover from a trusted state on patched infrastructure, and rotate exposed credentials from a clean environment after containment. Review connected services whose secrets the application could access.

A newly created backup can be useful evidence but may contain the compromise. Do not label it a clean recovery point merely because it completed successfully. Document the timeline and assess any customer-data exposure with the appropriate specialists.

Frequently asked questions

My WordPress dashboard says everything is updated. Am I protected?

That does not establish the server’s patch status. Get the PHP package/build confirmation from your host and compare it with the applicable vendor advisory.

My host uses PHP-FPM. Can I ignore this?

No. Exposure differs from mod_php, but PHP-FPM is included in PHP’s update guidance. The stale-state advisory reports validated session-lifecycle RCE against FPM under suitable application conditions.

Must I switch to PHP 8.5?

No. Fixed releases exist for supported branches 8.2 through 8.5. Choose a patched, compatible, maintained runtime with your host. A major branch change is not the only route to remediation.

Does an older displayed version mean the host is wrong?

Not necessarily. A documented vendor backport may contain both fixes. Ask for the package revision and supporting advisory rather than relying only on the short version number.

Should I take the website offline?

If the host cannot promptly patch or adequately restrict an exposed runtime, discuss temporary isolation. Choose a response that actually prevents public requests reaching PHP; displaying a maintenance page within the application is not the same thing.

Get help coordinating your website’s next steps

Moustaide COM can help review your website environment, coordinate technical work with your hosting provider and check important functions after a change. Server access, hosting responsibilities and the scope of any investigation should be agreed first.

Request a website maintenance and security review. Include your domain, hosting provider, current PHP version and any patch confirmation you have received. Never send passwords or API keys through a public form.

Official references and verification notes

This article distinguishes PHP’s upstream fixes from vendor-specific backports. Where an older notice conflicts with a newer package advisory, verify the latest statement for the exact platform you use. References were checked on 22 October 2026.

• PHP: security announcement and supported release fixes
• PHP: CVE-2026-109618 technical advisory
• PHP: CVE-2026-109619 technical advisory
• ENISA: joint statement and exposure-reduction guidance
• CERT-EU: critical vulnerabilities in PHP
• CloudLinux: package status and mitigation limitations
• Plesk: PHP builds and control-panel updates
• AWS: affected versions and runtime guidance
• Red Hat: CVE-2026-109618 and CVE-2026-109619
• WordPress: Site Health documentation