IT Security 4 weeks ago

Coraza WAF Parameter Flooding Vulnerability – Detection & Mitigation Guide

A comprehensive advisory detailing the Coraza WAF parameter flooding vulnerability, its impact on ARGS collections, detection techniques, and step‑by‑step mitigation and long‑term hardening measures. A comprehensive advisory detailing the Coraza WAF parameter flooding vulnerability, its impact on ARGS collections, detection techniques, and step‑by‑step mitigation and long‑term hardening measures.

FacebookXReddit

IT Security

Article Type: Security Advisory | Category: IT Security | Menu: TECH OPS

Introduction

Security teams need immediate awareness of a critical bypass vulnerability in Coraza Web Application Firewall (WAF) that silently drops request arguments, allowing attackers to evade security rules through parameter flooding. This advisory provides actionable detection and remediation steps to protect your applications from exploitation.

Vulnerability Overview

What is Being Exploited

Coraza WAF contains a vulnerability in its argument processing mechanism that silently discards request parameters when argument limits are exceeded. This silent drop behavior creates a critical security gap: attackers can flood requests with extra parameters, increasing the probability that malicious payloads will be dropped while benign parameters pass through undetected by security rules.

The vulnerability affects security rules that inspect ARGS, ARGS_GET, ARGS_NAMES, ARGS_POST, and related collections. When these rules evaluate a request, they may not see the malicious payload because it was silently removed during argument processing—yet the request continues processing without any alert or flag.

Affected Versions and Products

  • Product: Coraza Web Application Firewall
  • Affected Versions: All releases since v3.0.0 that include the SecArgumentsLimit directive
  • Introduction Date: June 2023 (PR #812, commit 2fd87b89)
  • Default Configuration: Vulnerable out-of-the-box without compensating rules

If you are running Coraza v3.0.0 or later with SecArgumentsLimit configured, your installation is affected.

Why Silent Argument Dropping Creates Risk

Traditional security controls fail when they cannot observe attack payloads. This vulnerability creates exactly that scenario:

  1. No Error Signals: When arguments are dropped, no error is raised, no flag is set, and no transaction-visible indicator is created
  2. Rule Blindness: Security rules cannot detect what they cannot see; dropped arguments remain invisible to inspection logic
  3. Probabilistic Bypass: Attackers exploit randomness in the drop mechanism to increase odds that malicious payloads are discarded
  4. Default Exposure: The default Coraza configuration lacks compensating rules, making this exploitable immediately after installation

Technical Attack Mechanics

How Parameter Flooding Bypasses Security Rules

Parameter flooding works by exploiting the probabilistic nature of the silent drop mechanism:

Attack Flow:

  1. Attacker crafts a request containing both benign and malicious parameters
  2. Request arrives at Coraza WAF with argument count exceeding SecArgumentsLimit (default: 1000)
  3. Coraza’s argument processing functions (AddGetRequestArgument, AddPostRequestArgument) silently return without processing excess arguments
  4. The dropped arguments are randomly distributed—sometimes including the malicious payload
  5. Security rules inspect only the retained arguments, potentially missing the attack
  6. Request proceeds to the backend application

Example Scenario:

GET /search?q=test&category=books&[998 benign parameters]&sql_injection_payload&[more benign parameters]

When the argument limit is exceeded, the SQL injection payload has a high probability of being silently dropped. Security rules inspecting ARGS never see it, and the request is allowed through.

The Silent Drop Mechanism Explained

The vulnerability exists in three core functions within Coraza’s transaction processing:

  • AddGetRequestArgument() – Processes URL query string parameters
  • AddPostRequestArgument() – Processes POST body parameters
  • AddPathRequestArgument() – Processes path parameters

When WAF.ArgumentLimit is exceeded, these functions return silently without:

  • Raising an error condition
  • Setting a transaction flag
  • Logging the drop event
  • Notifying security rules

This creates an information asymmetry: the WAF knows arguments were dropped, but the security rule engine does not.

POST Urlencoded Processing Vulnerability

A secondary vulnerability compounds the risk: the POST urlencoded processor does not enforce the argument limit at all. This means:

  • ARGS_POST can grow unbounded regardless of SecArgumentsLimit
  • Attackers can send extremely large POST requests with thousands of parameters
  • Memory consumption increases linearly with parameter count
  • No compensating rules can prevent this expansion

Impact: An attacker sending a 100MB POST request with 50,000 parameters can exhaust server memory while bypassing argument limit protections.

Memory Denial-of-Service Risk

The combination of unbounded ARGS_POST growth and silent argument dropping creates a denial-of-service vector:

  1. Attacker sends POST request with extremely large parameter count
  2. POST processor adds all parameters to ARGS_POST without limit checking
  3. Memory consumption spikes as the WAF allocates space for thousands of parameters
  4. Repeated requests exhaust available memory
  5. WAF or application becomes unresponsive

Real-World Attack Scenarios

Malicious Payload Evasion Through Argument Flooding

Scenario: E-commerce application with Coraza WAF protecting against SQL injection

POST /api/search HTTP/1.1
Content-Type: application/x-www-form-urlencoded
product=laptop&category=electronics&[1000+ benign parameters]&
filter=1' OR '1'='1&[more benign parameters]

Attack Execution:

  1. Request contains 1,050 parameters total
  2. Coraza processes first 1,000 parameters (all benign)
  3. SQL injection payload in filter parameter is silently dropped
  4. Security rule inspecting ARGS for SQL patterns sees only benign values
  5. Request is allowed through to backend
  6. Backend receives request with only benign parameters
  7. Attack fails, but no security alert was generated

Outcome: Attacker learns that parameter flooding can evade detection and refines attack strategy.

Resource Exhaustion via Oversized POST Requests

Scenario: SaaS platform with Coraza WAF protecting API endpoints

POST /api/upload HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 157286400
param1=value1&param2=value2&[50,000 parameters totaling 150MB]

Attack Execution:

  1. Attacker sends 150MB POST request with 50,000 parameters
  2. POST urlencoded processor adds all parameters to ARGS_POST without limit
  3. WAF memory usage spikes to 2GB+ as it allocates space for all parameters
  4. Legitimate requests begin timing out
  5. WAF becomes unresponsive
  6. Application availability degrades

Outcome: Denial of service achieved without triggering any security rules.

Injection Attack Exploitation

Scenario: Web application with Coraza WAF protecting against command injection

GET /admin/users?action=list&sort=name&[1000+ benign parameters]&
cmd=; rm -rf /&[more benign parameters]

Attack Execution:

  1. Attacker floods request with 1,050 parameters
  2. Command injection payload is silently dropped
  3. Security rules inspecting ARGS for shell metacharacters see only benign values
  4. Request passes through WAF
  5. Backend application processes request safely (payload was dropped)
  6. Attack fails, but security team has no visibility into the attempt

Outcome: Attack attempt goes undetected; attacker refines technique for next attempt.

Immediate Detection Steps

Log Analysis Techniques

Begin with your existing WAF logs to identify exploitation attempts:

1. Identify Requests with High Argument Counts

Search your WAF logs for requests with argument counts approaching or exceeding the limit:

# For access logs, look for patterns indicating high parameter counts
# Example: Apache/Nginx combined log analysis
awk -F' ' '{print $7}' access.log | grep -o '\?' | wc -l | sort -rn | head -20

2. Analyze Query String and POST Body Sizes

Requests with disproportionately large query strings or POST bodies relative to their argument count may indicate flooding:

# Identify requests with large query strings
grep -E '\?.*&.*&.*&.*&.*&.*&.*&.*&.*&' access.log | \
  awk -F'?' '{print length($2)}' | sort -rn | head -20

3. Search for Repeated Parameter Names

Attackers often use repeated parameter names to inflate argument counts:

# Look for patterns like param=value&param=value&param=value
grep -oE '[a-zA-Z_][a-zA-Z0-9_]*=' access.log | sort | uniq -c | sort -rn | head -20

Identifying Abnormal Argument Counts

Establish baseline metrics for your application:

Baseline Calculation:

  1. Analyze 30 days of normal traffic
  2. Calculate 95th percentile of argument counts per endpoint
  3. Set alert threshold at 110% of 95th percentile
  4. Document baseline by endpoint and HTTP method

Example Baseline Data:

Endpoint                    95th Percentile    Alert Threshold
/search                     45 arguments       50 arguments
/api/users                  12 arguments       14 arguments
/checkout                   28 arguments       31 arguments
/admin/reports              156 arguments      172 arguments

Traffic Pattern Anomalies to Monitor

Pattern 1: Sudden Spike in Argument Counts

  • Normal: 20-30 arguments per request
  • Anomaly: 500+ arguments in single request
  • Indicator: Possible parameter flooding attack

Pattern 2: Requests Exceeding SecArgumentsLimit

  • Normal: No requests exceed limit
  • Anomaly: Multiple requests at or near 1000 argument limit
  • Indicator: Deliberate limit testing or exploitation

Pattern 3: Repeated Parameter Names

  • Normal: Each parameter name appears once per request
  • Anomaly: Same parameter name appears 50+ times
  • Indicator: Argument count inflation technique

Pattern 4: Large POST Body with Few Visible Parameters

  • Normal: POST body size correlates with parameter count
  • Anomaly: 50MB POST body with only 10 visible parameters
  • Indicator: Possible DoS or encoding bypass attempt

Tools and Methods for Detection

1. WAF Log Analysis Tools

# Using grep and awk for quick analysis
grep "POST\|GET" waf.log | \
  awk -F'&' '{print NF}' | \
  awk '$1 > 1000 {print "High argument count: " $1}' | \
  sort | uniq -c | sort -rn

2. ELK Stack (Elasticsearch, Logstash, Kibana)

Create a Kibana dashboard with:

  • Argument count distribution by endpoint
  • Request size vs. argument count correlation
  • Top 20 endpoints by average argument count
  • Alert on requests exceeding baseline + 50%

3. Splunk Queries

index=waf_logs 
| rex field=_raw "(?<arg_count>\d+)\s+arguments"
| stats avg(arg_count) as avg_args, max(arg_count) as max_args by endpoint
| where max_args > 1000

4. Custom Python Script for Log Analysis

import re
from collections import defaultdict
def analyze_waf_logs(log_file):
    arg_counts = defaultdict(list)
    with open(log_file, 'r') as f:
        for line in f:
            # Extract endpoint and query string
            match = re.search(r'GET|POST\s+([^\s?]+)\?([^\s]*)', line)
            if match:
                endpoint = match.group(1)
                query = match.group(2)
                arg_count = len(query.split('&')) if query else 0
                arg_counts[endpoint].append(arg_count)
    # Report anomalies
    for endpoint, counts in arg_counts.items():
        p95 = sorted(counts)[int(len(counts) * 0.95)]
        max_count = max(counts)
        if max_count > p95 * 1.5:
            print(f"ANOMALY: {endpoint}")
            print(f"  95th percentile: {p95}")
            print(f"  Maximum observed: {max_count}")

Mitigation and Remediation

Implementing Compensating Rules

Compensating rules provide immediate protection while permanent fixes are developed. Add these rules to your coraza.conf-recommended:

Rule 1: Log and Deny Requests Exceeding Argument Limit

# Detect requests with excessive arguments
SecRule ARGS_NAMES "@gt 1000" \
    "id:1000001,\
    phase:2,\
    deny,\
    status:429,\
    log,\
    msg:'Excessive arguments detected - possible parameter flooding attack',\
    tag:'parameter-flooding',\
    tag:'attack-attempt'"

Rule 2: Monitor POST Argument Expansion

# Track POST argument count growth
SecRule ARGS_POST_NAMES "@gt 500" \
    "id:1000002,\
    phase:2,\
    log,\
    msg:'High POST argument count detected',\
    tag:'parameter-flooding',\
    setvar:'tx.post_arg_count=%{ARGS_POST_NAMES}'"

Rule 3: Detect Repeated Parameter Names

# Identify parameter name repetition (common flooding technique)
SecRule ARGS_NAMES "@rx ^([a-zA-Z_][a-zA-Z0-9_]*)\1{5,}$" \
    "id:1000003,\
    phase:2,\
    log,\
    msg:'Repeated parameter names detected',\
    tag:'parameter-flooding',\
    tag:'suspicious-pattern'"

Rule 4: Enforce POST Body Size Limits

# Prevent memory exhaustion via large POST bodies
SecRule REQUEST_METHOD "@eq POST" \
    "id:1000004,\
    phase:1,\
    chain,\
    msg:'POST body exceeds safe size limit'"
SecRule CONTENT_LENGTH "@gt 10485760" \
    "log,\
    deny,\
    status:413,\
    tag:'dos-prevention'"

Enforcing Argument Limits on POST Requests

Modify your Coraza configuration to enforce limits on POST-processed arguments:

Configuration Update for coraza.conf:

# Set argument limit (default: 1000)
SecArgumentsLimit 1000
# Set POST body limit (prevents unbounded ARGS_POST growth)
SecRequestBodyLimit 10485760
# Set individual argument size limit
SecArgumentSeparator "&"
# Enable argument processing
SecRequestBodyProcessor "application/x-www-form-urlencoded" "urlencoded"

Implementation Steps:

  1. Backup current configuration:
   cp coraza.conf coraza.conf.backup
  1. Add POST limit enforcement:
   # In coraza.conf, add or modify:
   SecRequestBodyLimit 10485760
   SecRequestBodyNoAction Off
  1. Test configuration:
   coraza -c coraza.conf -t
  1. Reload Coraza:
   systemctl reload coraza

Creating Transaction-Visible Flags

Implement flags that allow security rules to detect when argument limits have been reached:

Custom Rule with Flag Setting:

# Set flag when argument limit is approached
SecRule ARGS_NAMES "@ge 900" \
    "id:1000005,\
    phase:2,\
    nolog,\
    setvar:'tx.arg_limit_warning=1'"
# Set flag when argument limit is exceeded
SecRule ARGS_NAMES "@gt 1000" \
    "id:1000006,\
    phase:2,\
    nolog,\
    setvar:'tx.arg_limit_exceeded=1',\
    setvar:'tx.anomaly_score=+10'"
# Block requests with exceeded limits
SecRule TX:arg_limit_exceeded "@eq 1" \
    "id:1000007,\
    phase:2,\
    deny,\
    status:429,\
    log,\
    msg:'Argument limit exceeded - request blocked'"

Testing Mitigation Effectiveness

Test 1: Verify Argument Limit Enforcement

# Create test request with 1,050 parameters
python3 << 'EOF'
import requests
params = {f'param{i}': f'value{i}' for i in range(1050)}
response = requests.get('http://localhost/test', params=params)
print(f"Status: {response.status_code}")
print(f"Expected: 429 (Too Many Requests)")
EOF

Test 2: Verify POST Body Limit Enforcement

# Create large POST request
python3 << 'EOF'
import requests
# Create 15MB POST body
large_data = '&'.join([f'param{i}={"x"*1000}' for i in range(15000)])
response = requests.post('http://localhost/test', data=large_data)
print(f"Status: {response.status_code}")
print(f"Expected: 413 (Payload Too Large)")
EOF

Test 3: Verify Rule Triggering

# Monitor logs during test
tail -f /var/log/coraza/audit.log | grep "parameter-flooding"

Test 4: Validate Legitimate Traffic

# Ensure normal requests still work
curl -X GET "http://localhost/search?q=test&category=books&sort=price"
# Expected: 200 OK
Mitigation testing workflow showing how to validate compensating rules and configuration changes.
Mitigation testing workflow showing how to validate compensating rules and configuration changes.

Long-Term Security Hardening

Deterministic Argument Processing Implementation

The current implementation uses probabilistic argument dropping. Long-term, Coraza should implement deterministic processing:

Recommended Approach:

Current (Probabilistic):
- Arguments 1-1000: Processed
- Arguments 1001+: Randomly dropped
- Result: Unpredictable which arguments are dropped
Recommended (Deterministic):
- Arguments 1-1000: Processed
- Arguments 1001+: Consistently dropped (e.g., always last N arguments)
- Result: Predictable, auditable behavior

Benefits:

  • Security rules can reliably inspect arguments
  • Attackers cannot exploit randomness
  • Behavior is consistent and testable
  • Audit trails are meaningful

Rule Development for Argument Limit Violations

Develop comprehensive rules that address the vulnerability:

Rule Set 1: Detection Rules

# Detect parameter flooding attempts
SecRule ARGS_NAMES "@gt 800" \
    "id:2000001,\
    phase:2,\
    log,\
    msg:'Parameter flooding attempt detected',\
    tag:'parameter-flooding',\
    setvar:'tx.flooding_score=+5'"
# Detect repeated parameter names
SecRule ARGS_NAMES "@rx ^([a-zA-Z_][a-zA-Z0-9_]*)\1{3,}$" \
    "id:2000002,\
    phase:2,\
    log,\
    msg:'Repeated parameter names detected',\
    tag:'parameter-flooding',\
    setvar:'tx.flooding_score=+3'"

Rule Set 2: Blocking Rules

# Block high-confidence parameter flooding
SecRule TX:flooding_score "@ge 10" \
    "id:2000003,\
    phase:2,\
    deny,\
    status:429,\
    log,\
    msg:'Parameter flooding attack blocked'"

Monitoring and Alerting Strategy

Implement Multi-Layer Monitoring:

Layer 1: Real-Time Alerts

  • Alert on any request exceeding 800 arguments
  • Alert on POST bodies exceeding 5MB
  • Alert on repeated parameter names

Layer 2: Trend Analysis

  • Daily report of top 20 endpoints by argument count
  • Weekly report of argument count distribution changes
  • Monthly report of attack attempt trends

Layer 3: Anomaly Detection

  • Machine learning model trained on normal traffic patterns
  • Alert on statistical anomalies (e.g., 3-sigma deviation)
  • Correlation with other security events

Alert Configuration Example:

# Splunk alert for parameter flooding
index=waf_logs 
| rex field=_raw "(?<arg_count>\d+)\s+arguments"
| stats count by arg_count, src_ip, endpoint
| where arg_count > 1000
| alert

Version Update Planning

Immediate Actions (Week 1):

  • Inventory all Coraza installations
  • Document current versions and configurations
  • Identify test environments for updates

Short-Term Actions (Month 1):

  • Apply compensating rules to all production systems
  • Monitor for exploitation attempts
  • Plan update schedule

Medium-Term Actions (Month 2-3):

  • Test Coraza updates in staging environment
  • Validate that permanent fixes address the vulnerability
  • Schedule production updates during maintenance windows

Long-Term Actions (Month 3+):

  • Upgrade all systems to patched versions
  • Remove compensating rules once permanent fix is deployed
  • Document lessons learned

Assessment Checklist

Determining Your Exposure Level

Critical Exposure (Immediate Action Required):

  • [ ] Running Coraza v3.0.0 or later
  • [ ] SecArgumentsLimit is configured
  • [ ] No compensating rules are in place
  • [ ] Application handles sensitive data (payments, PII, credentials)
  • [ ] Application is internet-facing

High Exposure (Action Required This Week):

  • [ ] Running Coraza v3.0.0 or later
  • [ ] SecArgumentsLimit is configured
  • [ ] Compensating rules exist but are not comprehensive
  • [ ] Application is internal but processes sensitive data

Medium Exposure (Action Required This Month):

  • [ ] Running Coraza v3.0.0 or later
  • [ ] SecArgumentsLimit is configured
  • [ ] Compensating rules are in place and tested
  • [ ] Application processes non-sensitive data

Low Exposure (Monitor and Plan):

  • [ ] Running Coraza version prior to v3.0.0
  • [ ] SecArgumentsLimit is not configured
  • [ ] Application is not internet-facing

Priority Actions by Environment

Production Environment:

Priority 1 (Today):

  • [ ] Implement compensating rules from “Implementing Compensating Rules” section
  • [ ] Reload Coraza configuration
  • [ ] Verify rules are triggering correctly
  • [ ] Enable detailed logging for parameter flooding attempts

Priority 2 (This Week):

  • [ ] Analyze historical logs for exploitation attempts
  • [ ] Establish baseline metrics for argument counts
  • [ ] Configure alerting for anomalies
  • [ ] Brief security team on vulnerability and mitigations

Priority 3 (This Month):

  • [ ] Plan Coraza version update
  • [ ] Test update in staging environment
  • [ ] Schedule production update
  • [ ] Document update procedure

Staging Environment:

Priority 1 (This Week):

  • [ ] Deploy latest Coraza version
  • [ ] Test compensating rules
  • [ ] Validate that legitimate traffic is not blocked
  • [ ] Perform parameter flooding attack simulations

Priority 2 (This Month):

  • [ ] Test permanent fixes (when available)
  • [ ] Validate rule effectiveness
  • [ ] Document any configuration changes needed
  • [ ] Prepare production update plan

Development Environment:

Priority 1 (This Month):

  • [ ] Update development Coraza installations
  • [ ] Test application with compensating rules
  • [ ] Identify any false positives
  • [ ] Document parameter usage patterns

Validation Steps Post-Remediation

Step 1: Verify Compensating Rules Are Active

# Check that rules are loaded
coraza -c coraza.conf -t | grep "1000001\|1000002\|1000003\|1000004"
# Expected output: Rules should be listed as loaded

Step 2: Test Rule Triggering

# Test with excessive arguments
curl -X GET "http://localhost/test?$(python3 -c 'print("&".join([f"p{i}=v{i}" for i in range(1050)]))')"
# Expected: HTTP 429 response

Step 3: Verify Legitimate Traffic Passes

# Test normal request
curl -X GET "http://localhost/search?q=test&category=books&sort=price"
# Expected: HTTP 200 response

Step 4: Review Audit Logs

# Check that parameter flooding attempts are logged
grep "parameter-flooding" /var/log/coraza/audit.log | head -10
# Expected: Multiple entries for test requests

Step 5: Validate Alerting

# Verify alerts are being generated
grep "parameter-flooding" /var/log/alerts.log
# Expected: Alerts for test requests with excessive parameters

Step 6: Performance Baseline

# Measure WAF performance before and after mitigation
# Run load test and compare:
# - Response time
# - CPU usage
# - Memory usage
# - Throughput
# Expected: Minimal performance impact (<5% increase in latency)

Frequently Asked Questions

Q: What is the SecArgumentsLimit directive?

A: SecArgumentsLimit is a configuration setting in Coraza WAF that specifies the maximum number of arguments (parameters) that can be processed in a single request. The default value is 1000. It was introduced in version v3.0.0 via PR #812 to prevent resource exhaustion from requests with excessive parameters.

Q: How do I check if my Coraza installation is affected?

A: You are affected if you meet all of these conditions:

  1. Running Coraza version v3.0.0 or later
  2. The SecArgumentsLimit directive is configured in your coraza.conf
  3. No compensating rules are in place

Check your version:

coraza --version

Check your configuration:

grep "SecArgumentsLimit" /etc/coraza/coraza.conf

If both return results, you are affected.

Q: What makes this vulnerability critical?

A: This vulnerability is critical because:

  1. Silent Exploitation: Attacks succeed without triggering any alerts or flags
  2. Default Vulnerability: The default Coraza configuration is exploitable without additional rules
  3. Wide Applicability: Any security rule inspecting request arguments can be bypassed
  4. Dual Impact: Enables both rule evasion and denial-of-service attacks
  5. Difficult Detection: Exploitation is difficult to distinguish from legitimate traffic

Q: Can this vulnerability cause denial of service?

A: Yes. The vulnerability enables two types of denial-of-service attacks:

  1. Memory Exhaustion: Sending large POST requests with thousands of parameters causes unbounded ARGS_POST growth, exhausting server memory
  2. Resource Starvation: Repeated parameter flooding requests consume CPU and memory, degrading performance for legitimate users

Mitigation: Implement POST body size limits and argument count limits as described in the “Mitigation and Remediation” section.

Q: What immediate actions should I take?

A: Immediate actions (today):

  1. Implement compensating rules from the “Implementing Compensating Rules” section
  2. Reload Coraza configuration
  3. Verify rules are triggering correctly
  4. Enable detailed logging

Short-term actions (this week):

  1. Analyze historical logs for exploitation attempts
  2. Establish baseline metrics for argument counts
  3. Configure alerting for anomalies
  4. Brief security team on vulnerability

Q: Are there default protections against this vulnerability?

A: No. The default Coraza configuration lacks compensating rules, making this vulnerability exploitable out-of-the-box. You must manually implement the rules provided in this advisory to protect your systems.

Q: How does parameter flooding work in this attack?

A: Parameter flooding works through these steps:

  1. Craft Request: Attacker creates a request with both benign and malicious parameters, totaling more than the argument limit (default: 1000)
  2. Send Request: Request is sent to the WAF
  3. Silent Drop: When processing exceeds the limit, Coraza silently drops excess arguments without raising any error or flag
  4. Probabilistic Bypass: Due to randomness in which arguments are dropped, the malicious payload has a high probability of being discarded
  5. Rule Evasion: Security rules inspecting ARGS never see the malicious payload because it was dropped
  6. Request Allowed: Request passes through the WAF and reaches the backend application

Q: What collections are affected by this vulnerability?

A: Security rules inspecting these collections are vulnerable to bypass:

  • ARGS – All request arguments (GET and POST)
  • ARGS_GET – URL query string parameters
  • ARGS_POST – POST body parameters
  • ARGS_NAMES – Names of all arguments
  • ARGS_GET_NAMES – Names of GET arguments
  • ARGS_POST_NAMES – Names of POST arguments

Any rule using these collections can be bypassed through parameter flooding.

References

Official Documentation:

Related Security Resources:

Source Code References:

  • internal/corazawaf/transaction.go – Argument processing functions
  • internal/corazawaf/waf.go – WAF configuration and limits
  • internal/bodyprocessors/urlencoded.go – POST body processing

Document Information

Advisory ID: CORAZA-2024-001
Severity: Critical
Publication Date: 2024
Last Updated: 2024
Status: Active

Disclaimer: This advisory is provided for informational purposes. Organizations should conduct their own risk assessment and testing before implementing any recommendations. Consult with your security team and Coraza maintainers for environment-specific guidance.

← Back to IT Security