CVE-2026-7259

What it actually does

This vulnerability is a denial-of-service flaw in PHP’s multibyte regular expression handling. A mismatch between encoding lists maintained by Oniguruma and PHP mbfl can cause mb_regex_encoding() to dereference a NULL pointer when it is given certain encoding values. If an application allows user-controlled input to influence the encoding passed to mb_regex_encoding(), a remote attacker may be able to trigger a PHP process crash through a segmentation fault. The impact is availability-focused: request-handling workers, CLI jobs, or PHP-FPM/Apache worker processes may terminate unexpectedly, potentially reducing service capacity or causing intermittent outages depending on process supervision and traffic volume.

Why it matters to the business

Successful exploitation can cause PHP-backed applications or services to crash or become intermittently unavailable. The practical consequence is degraded customer-facing availability, failed transactions, interrupted background jobs, increased error rates, and operational noise from repeated process restarts. The CVSS score indicates moderate severity, EPSS is currently low, it is not listed in CISA KEV, and no mature exploitation is reported, but internet-exposed applications that accept user-controlled encoding parameters should still be prioritized because exploitation can be performed remotely where the vulnerable code path is reachable.

How an attack unfolds

An attacker first identifies a PHP application endpoint or workflow that accepts an encoding name, locale, character set, or similar parameter and uses that value directly or indirectly in mb_regex_encoding(). The attacker then supplies a crafted or edge-case encoding value that is valid or handled differently across PHP’s mbfl layer and the linked Oniguruma regular expression engine. Because the two components do not agree on the encoding list, PHP may reach an unexpected NULL value and dereference it. The resulting segmentation fault terminates the active PHP process. Repeated requests can cause recurring PHP-FPM, Apache module, or CLI worker crashes, producing a denial of service if enough workers are exhausted or if a critical job repeatedly fails.

How to fix it

Upgrade PHP to a fixed release: PHP 8.2.31 or later, PHP 8.3.31 or later, PHP 8.4.21 or later, or PHP 8.5.6 or later. Where distribution packages are used, apply the vendor-provided PHP security update rather than relying only on upstream version numbers, because Linux distributions may backport fixes. As a defense-in-depth measure, do not allow untrusted users to directly control values passed to mb_regex_encoding(); validate encoding choices against a small allowlist of required encodings, reject unknown values, and avoid dynamically changing global regex encoding based on request parameters. Ensure PHP-FPM, web server, and worker supervisors are configured to restart crashed workers, but treat supervision as a resilience control, not a fix.

How to confirm the fix worked

Confirm the running PHP version is no longer affected by checking `php -v`, package manager metadata, container image manifests, and runtime images used by web and worker services. Verify the deployed version is PHP 8.2.31+, 8.3.31+, 8.4.21+, or 8.5.6+, or that the operating system vendor has backported the patch. Review application code for uses of mb_regex_encoding() and confirm user-controlled input cannot reach that function without strict allowlist validation. In staging, exercise endpoints that accept charset or encoding parameters and confirm malformed or unsupported values are rejected cleanly and do not crash PHP workers. Monitor PHP-FPM, web server, and system logs after deployment for absence of recurring segmentation faults.

Typical attack path

1. Identify a PHP application running an affected PHP version: 8.2.x before 8.2.31, 8.3.x before 8.3.31, 8.4.x before 8.4.21, or 8.5.x before 8.5.6.
2. Find an application path where user input can control an encoding, charset, locale, or multibyte regex setting.
3. Submit crafted encoding values that are passed to mb_regex_encoding().
4. Trigger the NULL pointer dereference in the PHP multibyte regex implementation.
5. Cause a segmentation fault in the PHP process handling the request or job.
6. Repeat the request to degrade availability, exhaust PHP worker capacity, or interrupt application processing.

How to detect it

To determine whether exploitation has already occurred, review logs for unexplained PHP process crashes that correlate with requests containing encoding, charset, locale, or regex-related parameters. Relevant sources include web access logs, PHP-FPM logs, Apache or Nginx error logs, systemd journal entries, kernel logs, container runtime logs, application exception logs, and crash dump directories. Look for segmentation faults in PHP processes, repeated worker exits, spikes in HTTP 500/502/503/504 responses, and repeated requests to the same endpoint with unusual or unsupported encoding names. If core dumps are enabled, inspect PHP core files and backtraces for mb_regex_encoding, mbfl, Oniguruma, or multibyte regex frames. There are no public threat actors or ransomware campaigns reported for this issue in the provided intelligence, so detection should focus on behavioral evidence of crashing and suspicious input patterns rather than actor-specific infrastructure.

• mb_regex_encoding(
• mb_regex_encoding
• Segmentation fault
• segfault
• php-fpm
• PHP Fatal error
• child exited on signal 11
• exited on signal 11
• signal 11 (SIGSEGV)
• SIGSEGV
• core dumped
• kernel: php-fpm
• kernel: php
• Primary script unknown
• recv() failed (104: Connection reset by peer) while reading response header from upstream
• upstream prematurely closed connection while reading response header from upstream
• HTTP/1.1" 500
• HTTP/1.1" 502
• HTTP/1.1" 503
• HTTP/1.1" 504
• charset=
• encoding=
• mb_regex
• oniguruma
• mbfl

What your security team should do

• Inventory PHP runtimes across servers, containers, CI images, serverless layers, and background worker environments.
• Prioritize patching internet-facing PHP applications and services where users can submit encoding, charset, locale, or regex-related parameters.
• Upgrade affected PHP branches to fixed versions: 8.2.31+, 8.3.31+, 8.4.21+, or 8.5.6+, or install equivalent vendor backports.
• Search code for mb_regex_encoding() and require strict allowlist validation before any user-influenced value reaches it.
• Add monitoring for PHP segmentation faults, PHP-FPM worker crashes, abnormal 5xx spikes, and repeated requests containing unusual encoding or charset values.
• If immediate patching is not possible, block or normalize untrusted encoding parameters at the application, WAF, or reverse proxy layer.
• Rebuild and redeploy container images that include vulnerable PHP versions; restarting old images without rebuilding will not remediate the issue.
• Because the issue is not currently in KEV and EPSS is low, handle as a prioritized availability fix rather than an emergency ransomware-driven response unless local exposure is confirmed.