In Progress ZC-11209 - ModSec custom rules lost after Leapp upgrade

Operating System & Version
Rocky Linux 8
cPanel & WHM Version


Active Member
Dec 4, 2017
cPanel Access Level
Root Administrator
After upgrade from CentOS 7 to RockyLinux 8 I am getting this hit in modsec blocking some applications from submitting login request to my backend.

Message: Warning. Match of "rx ^%{tx.allowed_request_content_type}$" against "TX:0" required. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "440"] [id "920420"] [rev "2"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"]

However, I have checked for occurances of "allowed_request_content_type" in modsec conf, and it appears to me there should be no problem here:

SecRule &TX:allowed_request_content_type "@eq 0" "id:901162, phase:1, pass, nolog, setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'"

SecRule TX:0 "!^%{tx.allowed_request_content_type}$" "t:none, ctl:forceRequestBodyVariable=On, setvar:'tx.msg=%{rule.msg}', setvar:tx.anomaly_score=+%{tx.critical_anomaly_score}, setvar:tx.%{}-OWASP_CRS/POLICY/CONTENT_TYPE_NOT_ALLOWED-%{matched_var_name}=%{matched_var}"

All configurations are enabled in ModSec Vendor Rule Sets.


Active Member
Dec 4, 2017
cPanel Access Level
Root Administrator
I found the problem. Rule 901162 was disabled.
I have replaced it with a custom rule at some point, but the upgrade disabled all my custom rules, as the modsec2.user.conf file is empty now.

This was the file prior to the upgrade:

SecUploadDir /tmp
SecTmpDir /tmp
SecDataDir /tmp
SecRequestBodyAccess On
# Limit client hits by user agent

<LocationMatch "/">
SecRule REQUEST_HEADERS:User-Agent "@pm facebookexternalhit" "id:400009,phase:2,nolog,pass,setvar:global.ratelimit_facebookexternalhit=+1,expirevar:global.ratelimit_facebookexternalhit=5"

SecRule GLOBAL:RATELIMIT_FACEBOOKEXTERNALHIT "@gt 1" "chain,id:4000011,phase:2,deny,status:429,setenv:RATELIMITED,nolog,msg:'RATELIMITED BOT'"
SecRule REQUEST_HEADERS:User-Agent "@pm facebookexternalhit"

Header always set Retry-After "5" env=RATELIMITED
ErrorDocument 429 "Too Many Requests"
# Fix wp elementor access denied (this is unsafe)

<LocationMatch "/wp-admin/admin-ajax.php">
SecRuleRemoveById 949110

SecRuleRemoveById 980130

SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134

<Locationmatch "/wp-login.php">
# Setup brute force detection.
# React if block flag has been set.
SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 10 minutes, more than 10 login attempts in 3 minutes.'"

# Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"

SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=600,setvar:ip.bf_counter=0"

ErrorDocument 401 default
# Default HTTP policy: allowed_request_content_type (rule 900220)
SecRule &TX:allowed_request_content_type "@eq 0" "id:1901162, phase:1, pass, nolog, setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain|text/x-gwt-rpc'"
After restoring the custom rules everything works fine.
Last edited:


Jurassic Moderator
Staff member
Oct 19, 2014
cPanel Access Level
Root Administrator
The good news - this isn't specifically related to ELevate, as the removal of the customization happens when the ea-apache24 packages get removed.
The bad news - I don't have a workaround available just yet, besides manually restoring the file as you did.

I've created case ZC-11209 to have our developers take a look at this, and I'll be sure to post an update once I get one.