Critical PHP vulnerabilities: update now

If your website, store or platform uses PHP to serve web requests, this update should not wait for the next maintenance window. On October 21, 2026, the PHP project released fixes for two critical flaws that can allow unauthenticated remote code execution.

The critical PHP vulnerabilities are identified as CVE-2026-109618 and CVE-2026-109619. The PHP security team recommends updating immediately and warns that available mitigations do not replace installing a patched version.

What happened?

The two vulnerabilities affect how PHP manages memory and internal state while processing requests:

• CVE-2026-109618: an out-of-memory condition can leave internal request data in an invalid state and open a path to remote code execution.
• CVE-2026-109619: internal state may remain after its backing memory has been released and be consumed by a later request, producing a use-after-free condition.

Both vulnerabilities received a CVSS v4.0 score of 9.2 out of 10. An attacker does not need an account, and no user interaction is required.

Who should take precautions?

The official advisory considers PHP installations serving web requests at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The demonstrated risk is highest for Apache with mod_php because the attack can be triggered before application code begins to run.

This does not mean every website has already been compromised. It means the flaw sits in the request-processing layer, and waiting for visible evidence before patching creates unnecessary exposure.

Patched versions

Update to the appropriate fixed release for your current branch:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older no longer receive updates from the PHP project. Some Linux distributions and extended-support vendors may provide backported patches, but this must be confirmed with the vendor. PHP 8.2 reaches the end of security support on December 31, 2026, so organizations should also plan a move to a branch with a longer support horizon.

Action checklist for today

1. Identify the real production version. Check servers, containers, images and processes handling traffic instead of relying only on documentation.
2. Confirm the execution mode. Determine whether the environment uses PHP-FPM, mod_php, CGI, FrankenPHP or LiteSpeed.
3. Use the correct update channel. On Linux, check the official distribution or LTS vendor repository first. For other environments, use official downloads and binaries.
4. Test the update. Validate authentication, forms, file uploads, sessions, scheduled jobs, integrations and checkout flows.
5. Deploy and restart every worker. Updating files without restarting processes may leave older workers serving requests.
6. Verify after deployment. Confirm the active runtime version and review logs, errors, availability and critical business functions.
7. Record the evidence. Document which systems were updated, who validated the change and which assets remain pending.

If you cannot update immediately

The following measures only reduce certain attack paths; they do not make a vulnerable installation safe. Apply them with qualified technical oversight and an immediate update plan.

• Enforce conservative request-size limits at the web server or proxy and review post_max_size and upload_max_filesize.
• Disable session.upload_progress.enabled and restart every worker.
• On PHP 8.5, disable fatal_error_backtraces and restart all workers.
• Remove invalid or deprecated settings that generate diagnostics before normal initialization.
• Fix attacker-reachable fatal errors and execution timeouts.

The official advisory provides additional environment-specific guidance. Do not copy configuration changes without checking whether the application relies on uploads, memory limits or related capabilities.

Additional precautions after updating

• Review unexpected access and changes to files, accounts, scheduled tasks and credentials.
• Rotate secrets if there are reasonable signs of compromise.
• Avoid exposing detailed PHP versions in headers or diagnostic pages.
• Remove temporary tools such as public phpinfo() pages.
• Include server components, extensions and dependencies in the update inventory.

This is not only a developer task

An infrastructure vulnerability can affect availability, customer information, forms, sales and integrations. A responsible response therefore needs owners, priorities and evidence—not only a package installation.

Ainoa builds custom administrators and solutions connected to real operational processes. We also explain why technology must be tied to verifiable indicators in Your Company Does Not Need More AI: It Needs a Measurable Process.

Not sure which PHP version your platform uses or which components depend on it? Contact Ainoa. We can help map the environment, prioritize risk and design a modernization plan without losing operational control.

Frequently asked questions

Does a firewall replace the update?

No. It may reduce exposure to some patterns, but PHP states that updating to a patched release is the only complete solution.

Is PHP-FPM included?

Yes. The advisory considers PHP installations serving web requests—including PHP-FPM—at risk, although the strongest demonstrated scenario involves mod_php.

Should I assume my website was attacked?

Not automatically. Update, review logs and indicators of compromise, and escalate the investigation if you find abnormal activity.

More security alerts worth reviewing

A single update does not replace a continuous risk inventory. If you manage applications, AI agents or integrations, review these related alerts:

• Critical Langflow vulnerability: what to review.
• GitLab, Node.js, Java and HTTP/3 alerts: what to update.
• GitHub Copilot CLI: how a file could hide commands.