This article has been updated from the original posted in 2010 for an older version of cPanel.
cPanel’s Undocumented Autofixer: The Hidden Repair System Every Admin Should Know
If you have been managing cPanel servers for any length of time, you have probably encountered situations where SSH is locked out, iptables rules have gone rogue, or a misconfiguration has left you staring at an inaccessible server. Most admins reach for the command line in these moments, but what if you cannot even get to a shell?
Buried inside WHM is a repair framework that cPanel has never properly documented: the Autofixer system. It has existed since cPanel 11.24, and despite being referenced in scattered knowledgebase articles and forum posts over the years, the official documentation for it remains essentially nonexistent. This article is a deep dive into how it works, which scripts are available, and the real-world scenarios where the Autofixer can save your day.
What Is the Autofixer?
The Autofixer is a collection of repair scripts hosted on cPanel’s update servers that can be executed remotely through WHM. The scripts are designed to fix common problems that may prevent access to critical parts of your system, particularly in scenarios where you cannot reach the server through SSH or other conventional means.
The key detail here is that these scripts are fetched from cPanel’s httpupdate servers at runtime and executed on your machine. They are not stored locally on the server. When you trigger an Autofixer script, WHM downloads the script from http://httpupdate.cpanel.net/autofixer/ and runs it with root-level privileges.
This is both the system’s greatest strength and its most important security consideration. You get access to repair tools even when large parts of your server are broken, but you are also trusting remote code execution through WHM’s web interface.
How to Access the Autofixer
There are three ways to invoke the Autofixer, and understanding all three matters because different failure scenarios will dictate which method is available to you.
Method 1: Direct URL with Script Name
The most commonly used approach is the direct URL method. You construct a URL that specifies exactly which repair script to run:
https://your-server-ip:2087/scripts2/doautofixer?autofix=SCRIPT_NAME
For example, to run the SSH repair script:
https://203.0.113.50:2087/scripts2/doautofixer?autofix=safesshrestart
You can also use the non-SSL port if your SSL configuration is broken:
http://203.0.113.50:2086/scripts2/doautofixer?autofix=safesshrestart
This method requires WHM authentication. You will be prompted for your root username and password if you are not already logged in to a WHM session.
Method 2: The Interactive WHM Interface
If you can access WHM but are not sure which script you need, you can navigate to the interactive Autofixer interface:
https://your-server-ip:2087/scripts2/autofixer
This presents a simple form where you type the script name and click Submit. It is functionally identical to Method 1, but it is useful when you want to confirm the script name before executing it.
Method 3: Command Line via autorepair
If you do have SSH or console access, you can invoke the same scripts from the command line:
/scripts/autorepair SCRIPT_NAME
Or with the full path:
/usr/local/cpanel/scripts/autorepair SCRIPT_NAME
This calls the same underlying mechanism and fetches the same remote scripts, but it runs directly from the shell rather than through the WHM web interface.
The Available Autofixer Scripts
The full repository of available scripts is (or was, historically) browsable at http://httpupdate.cpanel.net/autofixer/. The following are the known Autofixer scripts, along with what they actually do and when you would use them.
test
What it does: Runs a no-op test of the Autofixer mechanism. Nothing on the server is changed.
When to use it: Always run this first on a server where you have never used the Autofixer before. It confirms that the Autofixer mechanism itself is functional, that your WHM instance can reach the httpupdate servers, and that the execution pipeline is working correctly. If this fails, none of the other scripts will work either, and you likely have a network or DNS resolution issue to address first.
https://your-server-ip:2087/scripts2/doautofixer?autofix=test
safesshrestart
What it does: Kills all running sshd processes and starts a bare-bones SSH server instance. If port 22 is already bound by another process, the script will attempt to start SSH on the next available port (port 23 and up).
When to use it: This is arguably the most valuable Autofixer script in the entire collection. Use it when SSH is completely unresponsive, when a configuration change to sshd_config has broken the daemon, or when a security hardening script has inadvertently locked you out. Because it starts a minimal SSH configuration, it bypasses whatever custom settings may have caused the problem.
Important: Pay close attention to the output when this script runs. If SSH starts on a non-standard port, the output will tell you which port it landed on. You will need that information to connect.
https://your-server-ip:2087/scripts2/doautofixer?autofix=safesshrestart
iptablesflush
What it does: Flushes all iptables rules on the server, effectively removing the firewall entirely.
When to use it: This is your emergency escape hatch when firewall rules have locked you out of every service, including SSH. If you have applied iptables rules (manually or through a tool like CSF or APF) that block your IP or all connections on critical ports, this script resets the firewall to a completely open state.
Warning: This removes all firewall protection. Once you regain access to your server, you need to immediately rebuild your firewall rules. Do not leave a production server running with a flushed iptables configuration.
https://your-server-ip:2087/scripts2/doautofixer?autofix=iptablesflush
bsdbindfix
What it does: Resolves a port conflict issue with BIND 9 (named).
When to use it: When BIND 9 fails to start because of a port binding conflict, typically on port 53. This can happen after OS-level updates that change how services claim ports during boot, or when another DNS-related service is holding the port.
https://your-server-ip:2087/scripts2/doautofixer?autofix=bsdbindfix
compresszlibfix
What it does: Fixes issues related to the Compress::Zlib Perl module.
When to use it: When cPanel or WHM throws errors related to Zlib compression, often visible during cPanel update attempts or when running Perl-dependent cPanel scripts. This was more common on older CentOS releases but can still surface after botched Perl module upgrades.
https://your-server-ip:2087/scripts2/doautofixer?autofix=compresszlibfix
dbdmysql
What it does: Fixes the DBD::mysql Perl module.
When to use it: When cPanel utilities that depend on Perl’s database interface for MySQL are failing. This was originally targeted at older Red Hat and CentOS versions (7.3 era), but the underlying issue of a broken DBD::mysql module can appear on newer systems after manual Perl upgrades or when the system Perl and cPanel’s Perl get out of sync.
https://your-server-ip:2087/scripts2/doautofixer?autofix=dbdmysql
diagnose_apache_conf
What it does: Analyzes the Apache configuration for syntax errors and common misconfigurations.
When to use it: When Apache refuses to start or restart and you suspect a configuration issue. This is particularly useful when a manual edit to httpd.conf or a custom VirtualHost entry has introduced a syntax error that prevents the web server from loading. Run this before diving into the configuration files manually, as it can quickly pinpoint the problem.
https://your-server-ip:2087/scripts2/doautofixer?autofix=diagnose_apache_conf
fpindexfile
What it does: Fixes FrontPage index file issues.
When to use it: This is a legacy script from the era when Microsoft FrontPage Extensions were a common feature on shared hosting servers. Unless you are maintaining a very old server that still has FrontPage support enabled, this script is unlikely to be relevant.
https://your-server-ip:2087/scripts2/doautofixer?autofix=fpindexfile
libxml64fix
What it does: Fixes libXML issues on 64-bit systems.
When to use it: When PHP or other applications that depend on libxml2 are failing on 64-bit servers. This typically surfaces as XML parsing errors in PHP applications or during cPanel’s own update process when it cannot build or link against the system’s libxml2 installation.
https://your-server-ip:2087/scripts2/doautofixer?autofix=libxml64fix
resellerresourceacctounts
What it does: Fixes issues with reseller resource account configurations.
When to use it: When reseller accounts are not properly linked to their resource allocations, or when the reseller overview in WHM shows incorrect account counts or resource usage. Note the typo in the script name (“acctounts” rather than “accounts”). This is the actual script name and it must be typed exactly as shown.
https://your-server-ip:2087/scripts2/doautofixer?autofix=resellerresourceacctounts
vfilterfix
What it does: Restores /etc/vfilters files.
When to use it: When email filtering is broken at the system level and individual account email filters are not being applied. The /etc/vfilters directory contains system-level virtual filter rules, and corruption in these files can cause email delivery to bypass filters entirely.
https://your-server-ip:2087/scripts2/doautofixer?autofix=vfilterfix
yumduprpmfix
What it does: Locates and resolves duplicate RPM packages in the yum database.
When to use it: When yum reports dependency conflicts caused by duplicate packages, or when cPanel updates fail because the RPM database has become inconsistent. Duplicate RPMs are a surprisingly common issue on long-running servers that have been through multiple major OS and cPanel version upgrades.
https://your-server-ip:2087/scripts2/doautofixer?autofix=yumduprpmfix
horde_sqmail_current_fix
What it does: Fixes issues with the Horde and SquirrelMail webmail clients.
When to use it: When Horde or SquirrelMail webmail is broken after an update or configuration change. Like the FrontPage script, this is becoming increasingly legacy as cPanel has moved toward Roundcube as the primary webmail client.
https://your-server-ip:2087/scripts2/doautofixer?autofix=horde_sqmail_current_fix
spamd_dbm_fix
What it does: Repairs the SpamAssassin daemon’s DBM database files.
When to use it: When SpamAssassin is failing to start or is throwing DBM-related errors in the logs. Corrupted DBM files are a known issue with spamd, especially on servers that experience unexpected shutdowns or filesystem issues.
https://your-server-ip:2087/scripts2/doautofixer?autofix=spamd_dbm_fix
autorepair
What it does: Runs a general-purpose repair routine.
When to use it: As a catch-all when you are not sure which specific Autofixer script is needed. This runs a broader set of checks and repairs than the individual targeted scripts.
https://your-server-ip:2087/scripts2/doautofixer?autofix=autorepair
Real-World Scenarios: When the Autofixer Saves You
Scenario 1: Locked Out by CSF
You have been tightening the CSF (ConfigServer Security & Firewall) rules and accidentally blocked your own IP range. SSH is down. You cannot even reach WHM on port 2087. But wait: if port 2086 (non-SSL WHM) or 2087 (SSL WHM) is still reachable from another IP or network, you can run the iptables flush:
https://your-server-ip:2087/scripts2/doautofixer?autofix=iptablesflush
Then immediately SSH back in and rebuild your CSF configuration properly.
Scenario 2: SSH Config Destroyed by Automation
A configuration management tool or a security hardening script has pushed a broken sshd_config to the server. SSH will not start. You have console access through WHM still because the web server is fine:
https://your-server-ip:2087/scripts2/doautofixer?autofix=safesshrestart
Check the output for the port number. SSH into the server on whatever port it reports. Fix the sshd_config. Restart SSH properly.
Scenario 3: Post-Migration DNS Failures
After migrating accounts to a new server, BIND refuses to start. The named service keeps crashing on startup. Before spending an hour reading through the named configuration:
https://your-server-ip:2087/scripts2/doautofixer?autofix=bsdbindfix
If the problem is a simple port conflict, this resolves it in seconds.
Security Considerations
The Autofixer system has some important security implications that are worth understanding.
First, the scripts are downloaded from cPanel’s httpupdate servers over HTTP (not HTTPS) and executed with root privileges. This means the integrity of the repair scripts depends on the security of cPanel’s update infrastructure and the network path between your server and their servers. On a compromised network, this could theoretically be a vector for malicious code injection.
Second, the iptablesflush script removes all firewall rules. While this is the intended behavior, it means that any admin with WHM root access can instantly strip the server of firewall protection. In environments where WHM access is shared among multiple administrators, this is worth considering in your access control policies.
Third, because these scripts are fetched remotely, they require outbound HTTP access to httpupdate.cpanel.net. If your server’s firewall or network configuration blocks outbound HTTP requests, the Autofixer will not function. This is another good reason to run the test script before you actually need the Autofixer in an emergency.
Why Is This Undocumented?
This is the question that deserves attention. The Autofixer system is not hidden. It is accessible through the standard WHM interface. The scripts are hosted on a publicly browsable URL. And yet, cPanel’s official documentation barely mentions it.
Part of the answer is likely that cPanel sees these as emergency break-glass tools rather than routine administration features. They do not want admins running iptablesflush as a first response to any connectivity issue. Another factor is that many of these scripts target issues with legacy software (FrontPage, SquirrelMail, old Perl modules) that are no longer central to the cPanel ecosystem.
But the practical reality is that safesshrestart and iptablesflush alone are worth knowing about. They can save you from requesting a datacenter-level console session or filing an emergency support ticket, and they can cut a 30-minute outage down to a 2-minute fix.
Best Practices for Using the Autofixer
Always run the test script first. Before you rely on the Autofixer in an emergency, verify that the mechanism works on your server. Run ?autofix=test and confirm you see successful output.
Bookmark the critical URLs. Have the safesshrestart and iptablesflush URLs bookmarked (with your server IP) somewhere accessible outside of the server itself. When you need them, you need them fast.
Document when you use them. The Autofixer scripts make changes to your server that may not be logged in the usual places. Keep a note of which scripts you ran and when, so you have a record if something unexpected happens later.
Rebuild after emergency fixes. The Autofixer scripts are designed to get you back in, not to provide permanent configurations. After using iptablesflush, rebuild your firewall. After using safesshrestart, fix your actual SSH configuration. Do not treat the Autofixer output as your production state.
Test from a different network. If your primary network is blocked, try accessing the Autofixer URL from a mobile hotspot, a VPN, or another location. The Autofixer only requires web access to WHM, which may be available even when SSH is blocked.