# cPanel EasyApache 4 v25.91: PHP2Shell CVE Fixes, libcurl & Podman 503 Fix

*Originally published at [Servermo](https://www.servermo.com/howto/update-easyapache-4-php2shell-503-fix/)*

---

EasyApache 4 v25.91 introduces critical security fixes for two PHP vulnerabilities, **CVE-2026-109618** and **CVE-2026-109619**, affecting EasyApache 4 PHP packages from `ea-php74` through `ea-php85`. The release also updates `ea-libcurl` and ModSecurity components and addresses an `ea-podman` issue that could leave restored cPanel applications returning HTTP 503 errors after container port reassignment.

These updates are critical for multi-tenant hosting providers running multiple PHP versions, PHP-FPM pools, and containerized applications. Updating the website PHP packages alone is not sufficient: administrators must also verify cPanel's internal PHP environment, restart affected workers, and confirm that patched packages are active.

---

## 1. PHP2Shell CVE-2026-109618 and CVE-2026-109619

Both PHP2Shell vulnerabilities carry a **CVSS v4.0 score of 9.2 (Critical)**. Because the flaws reside in the core PHP engine's request handling, traditional CMS updates (such as WordPress or Joomla) offer zero protection.

* **PHP Package Coverage:** EasyApache 4 v25.91 patches `ea-php74` through `ea-php85`. The fixes are backported to the older PHP 7.4, 8.0, and 8.1 package branches, while newer branches receive updated upstream PHP releases. Administrators should continue planning migrations away from upstream-EOL PHP versions.
* **Legacy PHP (CloudLinux Exception):** Standard cPanel EasyApache 4 packages listed in v25.91 cover `ea-php74` through `ea-php85`. CloudLinux maintains a separate package matrix that includes older PHP branches (down to PHP 5.2). For PHP versions older than 7.4, administrators should verify the exact patched package with their vendor or ELS provider rather than assuming that standard cPanel EA4 coverage applies.

### 14 Vulnerabilities Fixed in libcurl (Including CVE-2026-92392)
EasyApache 4 v25.91 also updates `ea-libcurl` to address 14 security vulnerabilities, including CVE-2026-92392. This issue involves a use-after-free condition in HTTP/2 upload handling. While disabling HTTP/2 or using HTTP/1.1 may reduce exposure across specific paths, neither approach replaces deploying the patched package.

---

## 2. Updating ModSecurity and Reviewing WAF Rules

EasyApache 4 updates `ea-modsec30` from 3.0.16 to 3.0.17, incorporating seven CVE fixes and one additional GHSA security fix.

> ⚠️ **Alert: Package Distinctions**  
> `ea-modsec30` and `ea-apache24-mod_security2` are separate packages. Verify which ModSecurity engine your server actually uses and ensure that the relevant installed package is updated. Verify that your OWASP Core Rule Set (CRS) deployment is maintained and active.

---

## 3. Fixing cPanel 503 Errors After Account Restore

The **EA4-338** fix addresses an `ea-podman` restore scenario where reassigned container ports leave web application proxies pointing to outdated internal destinations. 

The updated package automatically re-points web application reverse proxies at the conclusion of a user-run restore, allowing accounts whose container ports were reassigned to resume serving traffic instead of returning HTTP 503 Bad Gateway errors.

---

## 4. Troubleshooting ea-podman with CloudLinux CageFS

If you run CloudLinux and encounter namespace initialization failures for caged users, CageFS is likely masking the rootless `user@.service`.

> ⚠️ **Warning: Security Consideration**  
> These steps modify the isolation boundaries provided by CageFS and LVE. CloudLinux warns that rootless containers may execute outside CageFS, access host files through bind mounts, and operate without standard LVE resource controls. Apply these changes only after reviewing multi-tenant risk requirements.

### Applying the Workaround via SSH:
```bash
# Define target user variables (replace with actual values)
USERNAME="cpaneluser"
USER_UID="1001"

# 1. Update ea-podman first
dnf update ea-podman

# 2. Unmask the user service persistently
touch /opt/cloudlinux/flags/enabled-flags.d/disable-systemd-user-mask.flag

# 3. Reinstall CageFS hooks
cagefsctl --hook-install

# 4. Verify unmasking (Output should return 'static', not 'masked')
systemctl is-enabled user@.service

# 5. Enable unprivileged user namespaces
echo "user.max_user_namespaces = 15076" > /etc/sysctl.d/99-ea-podman.conf
sysctl --system

# 6. Enable lingering and stop existing user service
loginctl enable-linger "$USERNAME"
systemctl stop "user@${USER_UID}.service"
```

### Rollback Procedure to Restore Default CageFS Isolation:
```bash
# 1. Uninstall affected containers
ea-podman uninstall CONTAINER_NAME --verify

# 2. Restore default systemd user-service masking
rm -f /opt/cloudlinux/flags/enabled-flags.d/disable-systemd-user-mask.flag
cagefsctl --hook-install

# 3. Restore user namespace limit
rm -f /etc/sysctl.d/99-ea-podman.conf
sysctl -w user.max_user_namespaces=0

# 4. Disable lingering and stop the user service
loginctl disable-linger "$USERNAME"
systemctl stop "user@${USER_UID}.service"
```

---

## 5. Updating EasyApache PHP and cPanel Internal PHP

cPanel operates two independent PHP environments that must be patched separately:

### Minimum Fixed Builds for cPanel Internal PHP:
The cPanel management components (WHM, Roundcube) are patched in the following minimum builds:
* **Build 138:** 138.0.18
* **Build 136:** 136.0.50
* **Build 134:** 134.0.66
* **Build 110:** 110.0.153

### Command-Line Update Procedure:
```bash
# 1. Refresh repository metadata
yum clean all && yum makecache

# 2. Update EasyApache 4 and cPanel-managed system packages
/scripts/update-packages

# 3. Explicitly update cPanel's internal PHP
/scripts/autorepair update_cpanel_php8

# 4. Execute full cPanel & WHM core update workflow
/scripts/upcp

# 5. Restart services to cycle active workers
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
```
*(LiteSpeed users must execute the supported LiteSpeed graceful-restart procedure to ensure legacy PHP workers cycle completely).*

---

## 6. Package-Level Verification and Runtime Validation

Running `php -v` is insufficient. Because cPanel and upstream OS vendors backport security fixes into legacy releases, the version number will not change.

### Verify Installed CLI Packages via RPM Changelog:
```bash
for v in 74 80 81 82 83 84 85; do
    pkg="ea-php${v}-php-cli"
    if rpm -q "$pkg" >/dev/null 2>&1; then
        echo "===== PHP ${v} ====="
        rpm -q --changelog "$pkg" | \
            grep -E -m 5 'CVE-2026-109618|CVE-2026-109619' \
            || echo "No matching CVE entry found - investigate package version."
    fi
done
```

### SRE Runtime Validation Checklist:
1. Verify the installed CLI package changelog for each enabled PHP branch.
2. Confirm the corresponding PHP-FPM package versions and vendor changelogs.
3. Validate domain assignments in MultiPHP Manager.
4. Restart all PHP-FPM pools and web services.
5. Inspect application logs and confirm patched worker execution.

---

## 7. Temporary PHP2Shell Mitigation Strategies

If immediate patching cannot be scheduled, apply temporary mitigations. 

> ⚠️ **Warning:** These directives reduce exposure to specific execution paths but do not eliminate the vulnerability. Full patching is required.

* **For CVE-2026-109619 (Stale State):** Set `session.upload_progress.enabled = 0` globally in your primary `php.ini` or PHP-FPM pool configuration. *(Do not use `.user.ini` or `ini_set()`, as these execute too late during request parsing).* For PHP 8.5, also add `fatal_error_backtraces = 0`.
* **For CVE-2026-109618 (Out-of-Memory):** Upstream advisories reference `memory_limit = -1` as a temporary mitigation against controllable memory-limit exhaustion. However, applying unlimited memory across multi-tenant servers presents severe availability risks. Rely on CloudLinux LVE, cgroups, or container memory limits to maintain resource containment. Restrict `post_max_size` and ensure `upload_max_filesize` remains strictly below `post_max_size`.
* **RLIMIT Warning:** Do not use `RLIMIT_AS` or `RLIMIT_DATA` as substitutes for software patching.

---

## 8. Bare Metal Security Infrastructure Comparison

| Security Dimension | Virtual Shared Hosting | Dedicated Bare Metal Servers ★ |
| :--- | :--- | :--- |
| **Kernel Isolation** | Shared kernel across multiple tenant VMs | 100% physical hardware isolation |
| **Namespace Exploitation** | Container escapes threaten neighboring tenants | Physical hypervisor boundary elimination |
| **Resource Contention** | Noisy neighbors during OOM exhaustion attacks | Dedicated RAM, CPU cores, and NVMe I/O |
| **Network Attack Surface** | Shared virtual bridge routing | Dedicated IP routing and hardware DDoS scrubbing |

---

## cPanel Security and EasyApache 4 FAQ

### How do I safely fix CVE vulnerabilities in cPanel for legacy websites?
EasyApache 4 addresses this via security backporting. Fixes for PHP2Shell are backported to legacy branches (`ea-php74`, `ea-php80`, and `ea-php81`). This patches the underlying vulnerability while keeping the PHP version number and syntax unchanged, preventing legacy website code from breaking.

### What is CVE patching in the context of cPanel internal PHP?
cPanel operates two independent PHP runtimes. EasyApache 4 updates patch the PHP environment rendering hosted websites. The internal cPanel PHP environment (running WHM, Webmail, and Roundcube) requires an independent update via `/scripts/autorepair update_cpanel_php8` or `/scripts/upcp`. Both runtimes must be patched.

### Is it safe to use .user.ini for PHP2Shell mitigation in cPanel?
No. The PHP2Shell vulnerability triggers during the initial request parsing phase. Because `.user.ini` files are evaluated per-request after initialization begins, placing `session.upload_progress.enabled = 0` inside a `.user.ini` file will not protect the server. The directive must be enforced globally in the primary `php.ini` or PHP-FPM pool configurations.