NR26-10: PHP Runtime Vulnerabilities (CVE-2026-109618, CVE-2026-109619)

Vulnerability Identifier: NR26-10

Priority: Critical

Summary:

Two critical vulnerabilities (CVSS 9.2) were disclosed in the PHP runtime. They affect PHP versions 5.4.0 and later that serve web requests. The PHP project released fixes on October 21, 2026.

New Relic services are not impacted, and New Relic has not identified any evidence of exploitation of these vulnerabilities in its environment. New Relic's PHP agent runs inside the customer's own PHP environment and is not itself the vulnerable component.

Customers who run PHP applications, with or without New Relic instrumentation, should still assess their PHP versions.

Action Recommended:

No action is required with respect to your New Relic services. Nonetheless, New Relic strongly encourages customers who run PHP to upgrade to a fixed PHP release (to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35). If you cannot upgrade immediately, apply a WAF rule set that covers these CVEs and limit internet exposure of affected applications until you can.

Recommendations:

Distribution packages:
- Linux distributions and LTS vendors received the patches in advance. Check with your vendor for updated packages.
End-of-life versions (PHP 8.1 and older):
- Some distributions and LTS vendors provide backported fixes, so contact your vendor or upgrade to a supported version. Because of the severity, the PHP security team has also published minimal source backports for PHP 7.4, 8.0 and 8.1 for organisations that build from source or have no LTS vendor.
rpms.remirepo.net users:
- This volunteer-maintained repository will not have updates on release day. The PHP team urges users to switch to distribution packages or build from source.

Where immediate patching is not feasible, organizations should consider isolating internet-facing resources from public networks until the fix is applied and verified.

Temporary Mitigation:

Only an update fully fixes these vulnerabilities. The measures below reduce exposure to specific attack paths but do not make an installation safe.

CVE-2026-109618 (OOM corruption):

Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration. Check that no pool, directory or application setting puts a finite limit back. This removes the controllable memory limit failure, but an underlying allocation failure can still reach the vulnerable code path.

Set a low post_max_size: 8M for applications that do not need file uploads, 32M if uploads are required. Keep upload_max_filesize below post_max_size.

Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count and nesting depth. These limits must also cover requests without a usable Content-Length.

Use a container or cgroup memory limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA instead, because they can trigger the vulnerable allocation failure.

CVE-2026-109619 (stale global state):

Set session.upload_progress.enabled=0 and restart every worker. Apply this in php.ini, an FPM pool or a server configuration that takes effect before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.

On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.

Remove invalid or deprecated per-request settings that emit diagnostics before initialisation. Hiding diagnostics with error_reporting, display_errors or @ does not help.

Fix fatal errors and execution timeouts that attackers can reach, including failures in callbacks, upload or import processing, and cleanup.

FAQs:

How can I find out which PHP version I'm using?
Run php -v on the host or in the container. For the PHP version New Relic sees, check the host or application details in the New Relic UI.

Does the New Relic PHP agent need to be updated?
The vulnerabilities are in the PHP runtime, not the agent. Updating PHP is the required fix.

I'm running an end-of-life PHP version. What should I do?
PHP 8.1, 8.0, and all 7.x and 5.x branches will not receive official fixes. Check whether your Linux distribution (such as Ubuntu or AlmaLinux) has released a backported patch, and plan an upgrade to a supported branch.

How can I tell if my systems have been targeted?
Review web and WAF logs from October 21, 2026 onward. Publicly reported indicators include the User-Agent php2shell-verify/1.0 and requests to /vuln.php. Also look for web server or PHP processes spawning shell commands, and for new or modified PHP files in web directories.

Can a WAF protect me until I patch?
A WAF can reduce risk. Cloudflare has published emergency WAF rules for these vulnerabilities, and other vendors may offer similar protection. A WAF is a temporary mitigation, not a substitute for upgrading PHP.
I have questions or concerns about these vulnerabilities. Who should I contact?
If you have any questions about these vulnerabilities as they relate to your New Relic services, please open a support case via In-app support or reach out to your New Relic account representative.

Supporting Documents:

Technical Vulnerability Information:

For any support needs related to this communication, please open a support case via In-app support.