Column 1
Skip to content
Column 1

cPanel EasyApache 4 25.71-25.74 Security Update Checklist

cPanel WHM EasyApache security update checklist for ModSecurity, OWASP CRS, Nginx, and customer-site verification

cPanel's EasyApache 4 releases 25.71 through 25.74 include security and reliability work for ModSecurity, OWASP Core Rule Set, Nginx, and related web-server components. For a hosting server that uses any of those components, treat this as priority maintenance: use the supported WHM update path, allow the expected service restart, and verify the customer-facing paths that matter after the update.

What is in the current EasyApache update range?

  • 25.71 updates ModSecurity v3 and repairs an OWASP CRS state issue. cPanel identifies security fixes in this release, so servers using ModSecurity v3 should prioritize the update.
  • 25.72 repairs ModSecurity audit logging across mod_ruid2 user IDs, ensures the updated library is loaded with a full Apache restart, and moves OWASP CRS to 3.3.10 so anomaly scoring works correctly.
  • 25.73 refreshes Tomcat, Memcached, ModSecurity v2, OWASP CRS, ionCube, Node.js, and Passenger packages. cPanel records an OWASP CRS XML attribute-injection hardening fix in the 3.3.10 package update.
  • 25.74 updates EasyApache Nginx to 1.31.3 and rebuilds related Nginx modules. cPanel lists a critical Nginx heap-buffer-overflow fix and two medium-severity Nginx fixes in this release, so servers using the EasyApache Nginx stack should prioritize the maintenance window.

Security details validated for 25.73 and 25.74

  • EasyApache 4 25.74: cPanel updates the EasyApache Nginx package to 1.31.3 and lists CVE-2026-42533 as critical. The release also includes fixes for CVE-2026-60005 and CVE-2026-56434. Apply this update promptly on servers using the EasyApache Nginx stack, then verify representative HTTPS paths and application behavior.
  • EasyApache 4 25.73: cPanel updates ModSecurity v2 and OWASP CRS to 3.3.10, including the published XML attribute-injection hardening work. Keep WAF policy changes separate from this package update so any unexpected behavior has a clear support path.

This is defensive maintenance guidance only. Use the supported WHM update path, confirm the installed packages before and after the change, and test the hosted paths your customers rely on. Do not disable protective controls merely to make an unrelated application symptom disappear.

Not every server uses every component. Start by checking the currently installed EasyApache packages in WHM so the change window and verification focus on the services your customers actually use.

Plan the maintenance window

  1. Confirm ownership and timing. Assign a person to make the maintenance decision, choose a window appropriate for the sites on the server, and identify any customer-critical logins, forms, storefronts, or application services.
  2. Review the active web path in WHM. In WHM » Home » Software » EasyApache 4, review Currently Installed Packages. Pay particular attention to Apache, ModSecurity, Nginx, PHP, Passenger, Node.js, and application-server components in use.
  3. Keep the change focused. Do not combine this package maintenance with unrelated profile, web-server, or custom WAF-policy changes. A smaller change makes the result much easier to validate.
  4. Tell the right people. Let the support or account team know what customer paths to check and where to record a customer-specific exception.

Apply the supported WHM update

cPanel documents Run System Update from the EasyApache 4 interface as the supported way to update the installed RPMs. Review the server's release tier and update settings in WHM » Home » Server Configuration » Update Preferences, then use WHM » Home » Software » EasyApache 4 to run the system update.

Let the update finish before starting any other web-stack work. EasyApache 4 25.72 specifically requires a full Apache restart for the updated ModSecurity library to load, so a short service transition is an expected part of this maintenance. Avoid treating a completed download alone as proof that the serving path is ready.

Verify the server and hosted sites afterward

  1. Confirm WHM and cPanel remain reachable. Check the admin surfaces first so the team can assist affected accounts promptly.
  2. Test representative visitor paths. Load a normal HTTPS page for each major hosted application type, then test the important logged-in, form, checkout, or API-backed path chosen before maintenance.
  3. Check the intended web stack. Confirm that PHP-backed pages, Node.js or Passenger apps, and Nginx-served sites behave normally wherever those components are installed.
  4. Review monitoring and security signals. Use the approved WHM and monitoring views to check for unexpected service or WAF issues. Keep ModSecurity enabled unless a documented, time-bounded support case requires a narrower exception.
  5. Record the outcome. Note the update range applied, validation paths checked, and any account that needs follow-up. This gives support a clear handoff if a customer reports a change later.

When a WordPress site is the only affected application

First establish whether the issue appears across unrelated sites or only inside one application. A server-wide symptom belongs with the hosting maintenance record. When the web server is healthy and the problem is isolated to one WordPress installation, use the WordPress Support hub for an application-level recovery path. The WHM Security Advisor post-update checklist is also useful when confirming a broader cPanel security-maintenance cycle.

Related hosting maintenance

For Nginx-specific context, see the Nginx hosting security checklist. If the maintenance window exposes a capacity concern, the Help4 Disk Usage guide explains how hosting teams can review disk and inode reporting across cPanel, WHM, and WHMCS.

Official sources