CVE-2026-7568

What it actually does

The flaw is an integer overflow in PHP's built-in metaphone() implementation. A signed 32-bit integer is used to track position in the input buffer; when metaphone() receives an input string larger than 2,147,483,647 bytes, the position counter can overflow and produce undefined behavior. The likely outcomes are an out-of-bounds read, PHP process crash, segmentation fault, or limited exposure of unrelated process memory depending on build, platform, memory layout, and how the function is invoked. Exploitation requires an application path that passes attacker-controlled, extremely large input to metaphone(), so practical exploitation is high-complexity, but the impact can include denial of service for PHP worker processes.

Why it matters to the business

Applications that expose functionality using metaphone() on untrusted input may be susceptible to process crashes or instability when handling exceptionally large requests. In production web environments this could translate into intermittent outages, degraded service, PHP-FPM worker exhaustion, increased memory pressure, and operational disruption. The vulnerability is not currently listed in CISA KEV, has no reported ransomware association, and has low EPSS, but PHP is widely deployed and the affected versions span multiple active branches, so organizations should still patch during normal vulnerability management cycles, prioritizing internet-facing applications that process large user-supplied text.

How an attack unfolds

An attacker first identifies a PHP application feature that accepts user-controlled text and routes that value into metaphone(), directly or through application logic such as search, name matching, phonetic comparison, deduplication, or validation. The attacker then sends an extremely large payload exceeding the 2GB signed integer boundary. If the application, web server, PHP configuration, reverse proxy, request body limits, and memory limits allow the payload to reach metaphone(), PHP's internal index variable can overflow. This may cause the function to read outside the expected input buffer and crash the PHP process, typically producing a segmentation fault or worker termination. Repeated requests could be used to degrade availability by killing workers or forcing restarts. Because the attack requires unusually large input and permissive request/memory limits, real-world exploitation is expected to be constrained to applications with specific code paths and weak input-size controls.

How to fix it

Upgrade PHP to a fixed release for the affected branch: 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. If immediate upgrade is not possible, reduce exploitability by enforcing strict input-size limits before any call to metaphone(), rejecting or truncating untrusted strings to a small application-appropriate maximum, and ensuring large request bodies are blocked at the reverse proxy, web server, application framework, and PHP layers. Review use of metaphone() in application code, especially on user-controlled fields. Keep PHP memory_limit, post_max_size, upload_max_filesize, max_input_vars, web server client body limits, and load balancer request limits appropriately restrictive. Treat mitigations as temporary; the durable fix is upgrading PHP.

How to confirm the fix worked

Confirm the runtime PHP version reports a fixed version with `php -v` and, where applicable, verify all PHP-FPM pools, CLI runtimes, containers, base images, and package-managed installations have been updated. Validate that no production runtime remains on PHP 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. Review application source and dependencies for calls to metaphone() and confirm untrusted inputs are size-limited before reaching the function. Test request-size controls by submitting oversized but safe test payloads and confirming they are rejected by the edge, web server, or application before PHP performs expensive processing. Monitor PHP-FPM and system logs after patching to confirm segmentation faults or worker crashes associated with large requests are no longer observed.

Typical attack path

1. Reconnoiter PHP-backed application features that accept large text input, such as search, matching, import, profile, or form-submission workflows.
2. Identify or infer a code path where attacker-controlled input is passed to PHP's metaphone() function.
3. Craft a request or uploaded payload containing a string larger than 2,147,483,647 bytes, or as close as possible to that boundary depending on transport limits.
4. Bypass or take advantage of missing request-size, upload-size, application-level, and PHP memory/input limits.
5. Trigger metaphone() processing on the oversized input.
6. Cause integer overflow in PHP's metaphone implementation, resulting in undefined behavior such as out-of-bounds read or segmentation fault.
7. Repeat requests to crash PHP workers and degrade application availability if infrastructure automatically respawns failed processes.

How to detect it

Investigate whether applications expose features that pass user-controlled input to metaphone(), then correlate access logs, reverse proxy logs, WAF events, PHP-FPM logs, web server error logs, system journals, kernel logs, and crash dumps. Look for unusually large HTTP request bodies, uploads, or repeated rejected requests followed by PHP worker crashes or segmentation faults. Useful evidence includes HTTP 413 responses, request body limit violations, PHP-FPM children exiting on signal 11, kernel messages showing php or php-fpm segfaults, core dumps for PHP processes, and spikes in worker restarts or 502/503 errors. If source-level logging exists around phonetic matching, search for requests invoking workflows that use metaphone() immediately before crashes. Since no public exploit maturity or named threat actors are provided, detections should focus on behavioral artifacts rather than known attacker infrastructure.

• metaphone(
• metaphone()
• segmentation fault
• segfault at
• php-fpm: pool
• child exited on signal 11
• exited on signal 11 (SIGSEGV)
• server reached pm.max_children
• upstream prematurely closed connection
• recv() failed (104: Connection reset by peer) while reading response header from upstream
• client intended to send too large body
• Request Entity Too Large
• HTTP/1.1" 413
• Allowed memory size of
• core dumped
• php-fpm.*segfault
• php.*segfault

What your security team should do

• Inventory all PHP runtimes across servers, containers, CI images, and application platforms, and identify versions in the affected ranges.
• Prioritize upgrades for internet-facing PHP applications and services that accept large request bodies, uploads, imports, or free-form text input.
• Upgrade to PHP 8.2.31+, 8.3.31+, 8.4.21+, or 8.5.6+ depending on the deployed branch.
• Search application code for metaphone() usage and add explicit maximum-length validation for any untrusted input reaching it.
• Enforce layered request-size limits at CDN/WAF, reverse proxy, web server, PHP, and application levels.
• Add monitoring for PHP-FPM worker crashes, segmentation faults, abnormal memory use, and repeated oversized request attempts.
• Because EPSS is low and there is no KEV listing, handle as normal-priority patching unless exposed code paths using metaphone() on untrusted input are confirmed, in which case expedite remediation.