When running ModSecurity with complex rule sets like OWASP CRS, you might encounter the frustrating error: Rule execution error - PCRE limits exceeded (-8): (null). This occurs when regular expression processing exceeds the default PCRE (Perl Compatible Regular Expressions) limits in Apache's ModSecurity module.

The conventional approaches of increasing PCRE limits often don't work because:

• The values might still be too low for complex rule matching
• There could be conflicts between Apache and PHP PCRE settings
• Some rules might need optimization rather than just limit increases

Here's a more complete solution that addresses multiple aspects:

<IfModule security2_module>
    # Standard ModSecurity settings
    SecRuleEngine On
    SecAuditEngine RelevantOnly
    
    # Advanced PCRE configuration
    SecPcreMatchLimit 250000
    SecPcreMatchLimitRecursion 250000
    
    # Performance optimization
    SecResponseBodyAccess Off
    SecRequestBodyAccess On
    SecRequestBodyLimit 13107200
    SecRequestBodyNoFilesLimit 131072
    
    # Rule processing optimization
    SecRuleInheritance On
    SecRuleRemoveById 981173  # Example: disable a problematic rule
</IfModule>

<IfModule mod_php5.c>
    php_value pcre.backtrack_limit 1000000
    php_value pcre.recursion_limit 1000000
</IfModule>

For CRS 2.2.3, consider these specific adjustments:

# In your activated_rules configuration:
SecRuleUpdateTargetById 981231 !REQUEST_HEADERS
SecRuleUpdateTargetById 960015 !ARGS:password

If configuration changes don't suffice, you might need to consider recompiling with:

./configure --disable-pcre-match-limit --with-pcre=/usr/local/pcre
make
make install

After implementing changes, monitor your logs with:

tail -f /var/log/apache2/error.log | grep -i pcre

And verify your settings with:

apachectl -M | grep security
php -i | grep pcre

The error message Rule execution error - PCRE limits exceeded (-8): (null) typically occurs when ModSecurity's complex regular expressions exceed the default PCRE processing limits. This is particularly common with OWASP CRS rules which use intensive pattern matching.

Many solutions suggest adjusting these parameters:

SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000

Or in PHP:

pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000

However, as you've discovered, these may not always resolve the issue completely.

Before increasing limits further, consider optimizing your rule set:

# Example of how to disable specific problematic rules
SecRuleRemoveById 950109
SecRuleRemoveById 950901

For Apache configurations, try these additional settings:

<IfModule mod_security2.c>
    SecPcreMatchLimit 250000
    SecPcreMatchLimitRecursion 250000
    SecComponentSignature "ModSecurity-2.5.12"
    SecRequestBodyLimit 13107200
    SecRequestBodyNoFilesLimit 131072
</IfModule>

For PHP configurations (especially with Suhosin):

; In php.ini or .htaccess
pcre.recursion_limit=1000000
pcre.backtrack_limit=1000000
suhosin.pcre.recursion_limit=1000000
suhosin.pcre.backtrack_limit=1000000

Be aware that increasing these values significantly may impact server performance. Monitor your server's resource usage after making changes:

# Sample monitoring command
watch -n 1 "ps aux | grep httpd | awk '{print \$3,\$4,\$11}' | sort -n"

If all else fails, recompiling with --disable-pcre-match-limit might be necessary:

./configure --disable-pcre-match-limit
make
make install

Remember to test configuration changes in a staging environment before applying to production.