CVE-2025-14178: PHP array_merge Heap Overflow Fixed in Latest Patches

A newly assigned CVE (CVE-2025-14178) discloses a heap buffer overflow in PHP’s array_merge that can be triggered when a sequence of packed arrays causes integer overflow while precomputing element counts — a defect patched in PHP 8.1.34, 8.2.30, 8.3.29, 8.4.16 and 8.5.1 and now tracked across standard vulnerability databases.

Background​

PHP’s array handling includes an optimization for packed arrays (numerically indexed arrays) that attempts to precompute the total number of elements before allocating output containers. That precomputation uses zend_hash_num_elements to accumulate counts from each input array. In certain pathological cases the intermediate sum can overflow 32-bit limits (or exceed HT_MAX_SIZE), producing an incorrect allocation size and allowing subsequent writes to escape the allocated heap buffer. This is the root cause identified for CVE-2025-14178. The vulnerability was reported and published via the PHP project’s security advisory flow and has been added to canonical trackers such as NVD. Upstream commits and the official PHP changelog confirm the patched releases that remediate the defect.

---

What the bug looks like (technical overview)​

Where the overflow happens​

• The vulnerable code path is inside the logic that merges multiple arrays (array_merge and related optimizations).
• When arrays are packed, the engine can precompute the total number of elements to reserve a result buffer.
• The precomputation uses integer arithmetic (zend_hash_num_elements) and the running sum can overflow a 32-bit accumulator or exceed internal size limits (HT_MAX_SIZE).
• An overflowed count leads to an undersized allocation for the merged result; subsequent writes then produce a heap out-of-bounds write, which can corrupt heap metadata or adjacent heap objects.

Reproducer pattern (paraphrased)​

The upstream advisory supplies a compact proof-of-concept pattern: building a large array (for example with range and merging many copies of it causes the summed element count to exceed safe limits. While the GitHub advisory’s demonstration is intentionally extreme (it uses exponential repetition to push totals over the threshold), realistic exploitation paths can arise from untrusted inputs — for example large JSON payloads decoded into arrays and then forwarded into array_merge(....

---

Affected versions and patch status​

• Patched upstream releases: 8.1.34, 8.2.30, 8.3.29, 8.4.16, 8.5.1. These versions include the fixes that address the arithmetic/size precomputation and guard against overflow. Administrators should update to the appropriate patched series for their deployment.
• Vulnerable ranges reported: PHP 8.1. before 8.1.34; 8.2. before 8.2.30; 8.3. before 8.3.29; 8.4. before 8.4.16; 8.5.* before 8.5.1. The PHP Group provided the advisory and the changelog entries tied to those patched tags.
• CVE databases (NVD, cve mirrors) have already indexed the record and summarize the defect as a heap buffer overflow in array_merge; public trackers assign a medium severity baseline (CVSS v3.1 ~ 6.5 in multiple feeds) reflecting the combination of network reachability potential and non-trivial exploit complexity.

---

Impact: what can happen if code is not patched​

• Immediate and reliable outcome: Denial-of-Service (DoS) — crafted inputs will crash processes that call the vulnerable code path, causing worker failures and service outages.
• Memory corruption: the heap overflow can corrupt heap metadata or adjacent objects; depending on allocator behavior and runtime hardening (ASLR, hardened allocators, full RELRO/DEP/CFG), that corruption may be limited to crashes or could be leveraged by skilled attackers to escalate to remote code execution (RCE) in favorable conditions.
• Exposure scenarios: web apps and APIs that accept large or nested array inputs (for example, JSON upload endpoints, webhooks, internal RPCs) and feed them to array_merge or to application code paths that implicitly call array_merge are the highest-risk targets. The advisory explicitly warns that JSON-decoded structures that create arrays-of-arrays can be turned into an array_merge(...$decoded) call and thus become a remote attack surface.

Important nuance: while heap overflows are a powerful primitive, turning this specific overflow into a reproducible RCE requires favorable heap layouts, accessory primitives (such as memory disclosure), and the absence of standard mitigations. Public advisories and trackers treat RCE as possible but not trivial and emphasize DoS and memory corruption as the primary, proven impacts.

---

Exploitability and real-world feasibility​

• Attack vector: Network (in practice), when an application receives attacker-controlled structured inputs that the app decodes and then merges.
• Attack complexity: High — reliably pushing element counts beyond 32-bit limits and turning heap corruption into code execution is non-trivial in hardened environments.
• Privileges required: None — a typical web-facing endpoint could be sufficient if it decodes and merges untrusted arrays without safeguards.
• User interaction: None — attacker supplies crafted payloads programmatically.

In short: attackers with the ability to supply large array datagrams (for example via large JSON inputs) can cause crashes and potentially create a memory-corruption foothold. The presence of a public PoC pattern makes exploit development easier for motivated actors, which raises urgency despite the non-trivial exploitation path to RCE.

---

Actionable remediation checklist​

1. Upgrade PHP to a patched release:
   • PHP 8.1.x → update to 8.1.34 or later.
   • PHP 8.2.x → update to 8.2.30 or later.
   • PHP 8.3.x → update to 8.3.29 or later.
   • PHP 8.4.x → update to 8.4.16 or later.
   • PHP 8.5.x → update to 8.5.1 or later.
2. For package-managed deployments:
   • Use your OS vendor’s security updates (apt/yum/zypper/homebrew/chocolatey repositories) and confirm the package changelog includes the upstream fix commit or the target upstream version tag.
   • If your vendor has not yet shipped updates, plan a rebuild of PHP from upstream tarballs with the patched PHP tag or apply vendor backports if provided.
3. Short-term mitigations when immediate patching is impossible:
   • Block or strictly validate large array inputs: enforce maximum request body sizes and array depth and element count checks at the application or API gateway level.
   • Reject or sandbox JSON inputs that decode to arrays-of-arrays before any merging operations.
   • Run PHP workers that process untrusted inputs inside isolated sandboxes (containers with strict seccomp/AppArmor, reduced privileges, and limited resource quotas) to reduce blast radius.
   • Add web-application firewall (WAF) rules to block or throttle unusually large structured payloads and to raise alerts for repeated attempts.
4. Detection and verification:
   • Check installed PHP version: run php -v or inspect phpinfo pages to confirm the running minor/patch version.
   • Search your codebase for uses of array_merge that operate on external/untrusted inputs and insert size checks or replace with safer merging logic.
   • Monitor logs and crash traces for segmentation faults, worker restarts, or heap corruption reports tied to array-handling code paths.
5. Inventory and supply-chain hygiene:
   • Audit all containers, language bindings (e.g., PHP inside Docker images), vendor appliances, CI images, and language runtimes that bundle PHP to ensure the underlying PHP binary is updated.
   • Rebuild and redeploy images that statically include vulnerable PHP builds; do not rely only on the host package being updated.

---

Hardening recommendations for developers and maintainers​

• Avoid blind use of array_merge on untrusted inputs. Replace unguarded array merging with explicit, bounded merging logic that enforces per-array and total element count limits.
• Sanitize and validate decoded JSON input shapes before transforming them into native arrays — for example:
  • Limit array depth and element counts.
  • Cap numeric ranges and string lengths.
  • Reject inputs that produce an unexpectedly large count of child arrays.
• Implement defense-in-depth:
  • Use PHP runtime flags and compilation hardening (stack canaries, full RELRO, PIE).
  • Run FPM workers with limited privileges and use supervisor tooling to detect and contain repeated crashes.
  • Inspect code paths that use variadic unpacking (array_merge(...$arr_of_arrays) because they are a common vector for merging decoded array-of-arrays content.

---

Practical detection: hunting for vulnerable code paths​

• Grep your repository for:
  • array_merge(
  • array_merge(...array_fill
  • array_merge(...$decoded) patterns
• Review places that call json_decode($input, true) and then immediately call array_merge on the returned structure.
• Add unit tests that simulate large-but-valid inputs and assert that the application rejects or safely handles them rather than calling array_merge blindly.
• In CI, run fuzzing or large-scale structured-input tests against these merge points to detect potential crashes during integration tests.

---

Why this matters: broader risk context​

• Long-lived bug: The upstream advisory notes this class of optimization bug has existed since older PHP series (dating back to PHP 7.1 in reporting chatter), meaning many codebases may have latent exposure where developers assumed array merging was safe. The newly published advisory centralizes the risk and provides concrete mitigations.
• Wide attack surface: PHP is ubiquitous in web hosting environments, container images, and vendor appliances. A vulnerability that can be triggered by structured inputs (JSON, form data) arguably has a broad practical reach on internet-facing services.
• Supply-chain challenge: Many projects vendor or statically link PHP, and container images often lag upstream releases. Even if an OS package is updated quickly, the presence of stale images, CI artifacts, or embedded runtimes can prolong exposure. Inventory and rebuild steps are therefore essential.

---

Risk assessment and prioritization​

• Priority: High for public-facing web services that parse untrusted JSON and perform merging operations; Medium for internal systems with limited exposure.
• CVSS: Several trackers have converged on a medium numerical severity (CVSS v3.1 ~ 6.5) reflecting network reachability but higher attack complexity. Operationally, treat any internet-facing PHP service that decodes arbitrary arrays and merges them as a high-priority remediation target.

---

Example mitigation code patterns​

• Replace direct merge of untrusted arrays with guarded code:

1. Validate and bound input before any merge.
2. Reject inputs that would cause the total element count to approach dangerous limits.
3. Use explicit loops that abort when thresholds are exceeded.

Example (conceptual):

1. Iterate each candidate array and:
   • if (!is_array($candidate) continue;
   • if (count($candidate) > PER_ARRAY_LIMIT) reject;
   • total += count($candidate); if (total > TOTAL_LIMIT) reject;
2. Only then allocate and merge with controlled logic.

This pattern ensures that counts are validated with safe integer types and prevents precomputation from overflowing target sizes.

---

Conclusion​

CVE-2025-14178 is a real-world, heap buffer overflow in PHP’s array_merge optimization that arises when precomputed element counts overflow 32-bit accumulators or exceed HT_MAX_SIZE. The defect is fixed in the December 2025 PHP patch releases (8.1.34, 8.2.30, 8.3.29, 8.4.16 and 8.5.1); the official advisory and PHP changelog entries document the problem, proof-of-concept patterns, and the patched versions. Administrators and developers must prioritize upgrades where PHP merges untrusted arrays, apply short-term input validation and sandboxing mitigations if immediate patching is not feasible, and audit container images and vendor artifacts to ensure no stale vulnerable runtime persists.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center