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

Originally published at Servermo

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:

# 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:

# 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:

# 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:

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

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.