Fix EasyApache 4 PHP Install Failures Caused by Imunify360 Hardened PHP

When EasyApache Won’t Install PHP and You Don’t Know Why

You’re in WHM, trying to install PHP 7.4 (yes, I know – outdated!) through EasyApache 4, and it spits this back at you:

Problem 1: package ea-php74-php-cli-7.4.33-16.20.3.cpanel.x86_64 from EA4-c8 
requires libargon2.so.0()(64bit), but none of the providers can be installed
  - cannot install both ea-libargon2-20161029-3.3.111.cpanel.x86_64 from EA4-c8 
    and ea-libargon2-1:20161029-3.el8.cloudlinux.2.x86_64 from @System

If you’re staring at this wondering what the hell libargon2 has to do with anything, you’re not alone. I hit this exact wall on a production Rocky Linux 8 server running cPanel, and the fix wasn’t obvious.

The short version: Imunify360’s Hardened PHP feature installs its own versions of core libraries that conflict with cPanel’s EasyApache packages. You can’t mix them. You either run Imunify’s PHP stack or cPanel’s – not both.

The Production Server Disclaimer

I had to do this on a live production server with zero downtime tolerance. If you’re in the same boat, have someone on standby who can help if things go sideways. The fix I’m about to show you worked cleanly for me, but swapping out PHP libraries on a running server is not something you want to wing alone at 1am if you’re unsure.

Diagnosing the Problem

First, confirm you’re actually dealing with Imunify360’s hardened packages and not some other repo conflict.

Check what’s installed:

rpm -qa | grep -E "ea-libargon2|ea-libxml2"

If you see output like this, you’ve got Imunify’s versions:

ea-libargon2-20161029-3.el8.cloudlinux.2.x86_64
ea-libxml2-2.13.8-1.el8.cloudlinux.x86_64

The .cloudlinux suffix is the giveaway. These came from Imunify360’s imunify360-ea-php-hardened repo, not cPanel’s EA4 repo.

Now check what depends on these libraries:

rpm -q --whatrequires ea-libargon2 ea-libxml2

On my server, this showed PHP 8.4 packages – also from the Imunify repo:

ea-php84-php-common-8.4.12-2.el8.cloudlinux.1.x86_64
ea-php84-php-cli-8.4.12-2.el8.cloudlinux.1.x86_64
ea-php84-php-xml-8.4.12-2.el8.cloudlinux.1.x86_64

Confirm your PHP packages are all from Imunify:

rpm -qa | grep ea-php | head -20

If everything shows .cloudlinux in the release string, your entire PHP stack is running on Imunify’s hardened builds. That’s why EasyApache can’t install anything, it’s trying to pull in cPanel’s libraries, which conflict with the Imunify versions already on the system.

Why This Happens

When you install Imunify360 and enable Hardened PHP, it replaces cPanel’s standard PHP packages with its own security-hardened versions. These come from a separate repository (imunify360-ea-php-hardened) and include patched versions of supporting libraries like ea-libargon2 and ea-libxml2.

The problem is these packages use the same names as cPanel’s but have different version strings and come from a different repo. When EasyApache tries to install a new PHP version, it pulls cPanel’s library versions, which directly conflict with Imunify’s installed versions. YUM/DNF won’t let you have both.

The Fix: Disable Imunify360 Hardened PHP

If you want to manage PHP through EasyApache like normal, you need to turn off Imunify’s Hardened PHP feature. This will uninstall Imunify’s PHP packages and let cPanel’s EA4 repo take over.

In WHM:

1. Go to Imunify360 in the left sidebar
2. Click Settings
3. Find Hardened PHP
4. Disable it

Imunify will uninstall its hardened packages. This takes a minute or two and you’ll see it processing in the UI.

The Moment of Truth

Here’s where I panicked. I disabled Hardened PHP before fully thinking through what would happen to the running PHP 8.4 that all my client sites were using. Don’t be me! Read ahead first.

Once Imunify finishes, immediately verify your server is still alive:

curl -I http://<your server url> 2>/dev/null | head -5

You want to see:

HTTP/1.1 200 OK

Apache is up. Now check PHP:

php -v

On my server, this came back with PHP 8.4.16, cPanel’s version had automatically replaced Imunify’s. Good sign.

Check that PHP-FPM is running:

systemctl status ea-php84-php-fpm --no-pager

You should see active (running). If you do, your sites are probably fine. Hit a few of them in a browser to confirm.

Verify the system default PHP version is still set:

whmapi1 php_get_system_default_version

Expected output:

data:
  version: ea-php84
metadata:
  command: php_get_system_default_version
  reason: OK
  result: 1

Install Your PHP Version

Now try EasyApache again. Go to WHM → EasyApache 4 → Customize → PHP Versions, enable PHP 7.4 (or whatever you needed), and provision.

It should work now. The library conflicts are gone because you’re running a consistent package set from cPanel’s EA4 repo.

What You Lose

Imunify360’s Hardened PHP includes security patches that go beyond what cPanel ships. By disabling it, you’re back to standard PHP builds. Whether that matters depends on your threat model and how much you trust your other security layers.

If you want hardened PHP and EasyApache compatibility, you’re stuck waiting for Imunify to support the PHP version you need, or running everything through their stack without mixing repos.

Gotchas

• The Imunify packages use .cloudlinux suffixes even if you’re not running CloudLinux. Rocky Linux 8 with Imunify360 gets the same packages.
• You can’t just force-install cPanel’s libraries over Imunify’s. The dependency chain will break your running PHP.
• Disabling Hardened PHP triggers an automatic replacement of PHP packages. On my server this was seamless, but have a backup plan.
• If you’re running CloudLinux with CageFS or other LVE features, test thoroughly after the switch.

Once you’re back on cPanel’s standard EA4 packages, EasyApache works like it should. The whole fix takes about 10 minutes if nothing goes wrong, just make sure you’ve got a backup plan if this is a production box.