How to Fix the phpMyAdmin 403 ‘Error in Processing Request’

If phpMyAdmin throws Error in processing request, Error code: 403 when you run a query or edit a row, a web application firewall is most likely blocking the request, not phpMyAdmin itself. This DevAnswers guide explains why ModSecurity does it and how to whitelist the offending rule safely, without switching off your firewall.

Why phpMyAdmin Throws a 403 ‘Error in Processing Request’ #

phpMyAdmin sends the SQL you type to the server as a background (AJAX) request. If that server runs ModSecurity, a web application firewall common on VPS and cPanel hosting, the SQL keywords in your query can look like an attack. ModSecurity is a web application firewall, and in blocking mode it returns a 403 error when a request matches one of its rules.

The usual culprit is the OWASP Core Rule Set: its REQUEST-942-APPLICATION-ATTACK-SQLI.conf file contains rules that detect classic SQL-injection attacks, and your perfectly valid query trips one of them. phpMyAdmin then surfaces the rejection as error (rejected): it seems that the connection to server has been lost. That message is misleading: the connection is fine, the firewall simply refused the request before phpMyAdmin’s JavaScript got a normal reply, so it assumes the server dropped. Your SQL is fine too; this is a false positive, not a real injection attempt.

You tend to hit it on queries that contain tokens ModSecurity treats as risky, such as UNION, comment markers, or stacked statements, and on bulk edits where several rows post at once. A quick way to confirm the database itself is healthy is to run the same query from the command line with the mysql client: if it succeeds there but fails in phpMyAdmin, the block is happening at the web layer, not in MySQL.

Confirm It and Find the Blocking Rule #

Reproduce the 403, then look at the ModSecurity audit log (usually /var/log/modsec_audit.log) or the web server error log right afterwards:

sudo tail -n 50 /var/log/modsec_audit.log
# or, if there is no separate audit log, the web server error log:
sudo tail -n 50 /var/log/apache2/error.log

Look for the line naming the matched rule, for example [id "942100"]. That ID is what you will whitelist. If you are not sure where your server keeps these files, see our guide on where Apache logs are located (on RHEL/CentOS the error log is /var/log/httpd/error_log, and on nginx it is /var/log/nginx/error.log). On managed or cPanel hosting, the ModSecurity panel lists recent hits with their rule IDs instead.

A matching entry shows the rule that fired along with a short message, for example [id "942100"] [msg "SQL Injection Attack Detected"]. Note the number in the id field; that is the single rule you need to switch off. On cPanel specifically, the equivalent view is Security › ModSecurity Tools › Hits List, which shows the same rule IDs without touching the command line.

Whitelist the Rule #

Once you have the rule ID, disable just that one rule. Put the override in a separate file rather than editing the Core Rule Set itself, so a future rules update will not wipe your change:

# /etc/modsecurity/whitelist.conf - loaded after the Core Rule Set
SecRuleRemoveById 942100

The SecRuleRemoveById directive disables a rule by its ID. Make sure this override file is loaded after the Core Rule Set (most installs include a conf.d or crs-setup directory in order); if you are unsure of the load order, wrap the directive in an Apache <LocationMatch> block for your phpMyAdmin path instead (on nginx, use a location block in your ModSecurity config), which applies no matter when the file loads. Then reload the web server (sudo systemctl reload apache2 on Debian/Ubuntu, sudo systemctl reload httpd on RHEL/CentOS, or sudo systemctl reload nginx for nginx) and the 403 should be gone.

If the 403 has locked you out and you need access this minute, you can stop ModSecurity blocking temporarily with detection-only mode:

SecRuleEngine DetectionOnly

In this mode SecRuleEngine (which accepts On, Off, or DetectionOnly) still logs matches but lets every request through, so it removes all protection, not just the one false-positive rule. Treat it as a stopgap: use it to get in, apply the SecRuleRemoveById whitelist above, then set the engine back to On. On nginx the same SecRuleRemoveById line goes in your ModSecurity rules file; if you are still wiring phpMyAdmin into nginx, see our nginx phpMyAdmin configuration template. On cPanel or Plesk, use the ModSecurity UI to disable the rule ID.

If you would rather not relax the rule across the whole server, scope the exception to phpMyAdmin’s address. Wrap the removal in an Apache <LocationMatch> block for your phpMyAdmin path, or use a SecRule with a ctl:ruleRemoveById action that only drops the rule when REQUEST_URI matches that path. Every other site on the server then keeps the full Core Rule Set, and only phpMyAdmin gets the exception.

Summary #

The phpMyAdmin 403 error in processing request is almost always a ModSecurity false positive on the SQL in your query. Find the rule ID in /var/log/modsec_audit.log, then whitelist just that rule with SecRuleRemoveById in a separate override file. If the server has no WAF at all, check instead for a Require all denied or deny rule in your Apache or nginx config. Once your firewall is tuned, you can further secure phpMyAdmin access by setting up IP restrictions and Fail2ban.