☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N 🐛 CWE-693
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2022-39958

CVE-2022-39958 — Response body bypass in OWASP ModSecurity Core Rule Set via repeated HTTP Range header submission with a small byte range
📅 PUBLISHED: 2022-09-20 00:00 UTC 🔄 UPDATED: 2026-10-02 19:30 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: CONFIRMED — 3+ independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 1.22%
👁️
1.22% probability
30.6× above the median CVE
Tier: HIGH
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1190
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
Patch available — upgrade to latest release
CVSS VECTOR BREAKDOWN 7.5
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: N Privileges Required None
UI: N User Interaction None
S: U Scope Unchanged
C: H Confidentiality High
I: N Integrity None
A: N Availability None
7.5
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2022-39958 is a response body bypass vulnerability in the OWASP ModSecurity Core Rule Set (CRS). An attacker can sequentially exfiltrate small, undetectable sections of a protected resource by repeatedly submitting HTTP requests that include a Range header field specifying a small byte range. This bypass defeats CRS pattern-matching inspection of response bodies, allowing a restricted resource to be accessed through a web application firewall. The vulnerability affects legacy CRS versions 3.0.x and 3.1.x, as well as the currently supported versions 3.2.1 and 3.3.2, with patches released in versions 3.2.2 and 3.3.3. The vulnerability carries a CVSS score of 7.5, indicating high severity due to confidentiality impact without requiring authentication.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

The vulnerability resides in how OWASP ModSecurity CRS inspects HTTP response bodies for malicious content or policy violations. Under normal operation, CRS applies a set of pattern-matching rules to the full response body, detecting restricted content, sensitive data leakage, or attack signatures. The CNA Title describes the flaw as a "response body bypass" that leverages the HTTP Range header.

Vulnerability Mechanism: The core issue is that the CRS rules inspect only the portion of the response body actually transmitted in a single response. When an attacker sends an HTTP request with a Range header specifying a small byte range (e.g., Range: bytes=0-100), the server sends only that small subsection of the resource in the response body. CRS pattern-matching rules are designed to flag responses when they match known attack patterns or restricted content signatures. However, when the response body is truncated to a small slice, a single slice may not contain enough contiguous bytes to trigger any detection rule, causing the slice to pass undetected.

Attack Mechanism: By repeatedly issuing requests, each with a different small byte range, the attacker can incrementally retrieve the entire restricted resource piece by piece. Each individual response may evade detection because:

  1. The slice is too small to match a full signature or pattern that requires a longer sequence.
  2. The pattern-matching engine evaluates each response in isolation, without stateful correlation across multiple requests.
  3. Rules that check for "forbidden content" or "sensitive data" may require the presence of keywords or combinations of tokens that do not appear within a single small slice.

Affected Rule Sets: The NVD description explicitly states that legacy CRS versions 3.0.x and 3.1.x are affected, as well as 3.2.1 and 3.3.2. The fix requires upgrading to 3.2.2 or 3.3.3. Notably, the vendor also recommends configuring a CRS paranoia level of 3 or higher as part of the mitigation. Paranoia levels in CRS control how aggressive the rule set is; higher levels enable additional rules that catch more anomaly patterns, including those that might be missed at lower levels. However, the NVD description does not provide specifics about which internal rule IDs are bypassed or how the patch changes rule inspection logic.

Technical Detail Limitation: The NVD description provides high-level details but does not enumerate specific rule identifiers, code paths, or configuration parameters beyond the "Range" header mechanism. The description mentions the Range header and paranoia levels at a conceptual level only. No specific function names, class names, or API endpoints are disclosed in the NVD data. The vulnerability class is best described as an "HTTP protocol manipulation leading to WAF inspection bypass."

Exploitation Scenarios

The following attack chain is inferred from the NVD description and vulnerability class. No public PoC is available; attack chain is inferred from vulnerability class.

Step 1: Reconnaissance / Target Identification The attacker identifies a web application that is protected by a ModSecurity WAF configured with a vulnerable version of CRS (3.0.x, 3.1.x, 3.2.1, or 3.3.2). The attacker may fingerprint the WAF by sending malformed requests and observing error pages, response headers, or behavior differences. The target resource is a restricted or sensitive file or endpoint that CRS is configured to block or log when accessed.

Step 2: Triggering the Vulnerability Class The attacker sends an HTTP GET request to the protected resource, adding a Range header with a small byte range (e.g., Range: bytes=0-99). The backend server responds with the first 100 bytes of the resource in the response body. Because the CRS inspects only the transmitted response body slice, the slice passes through pattern-matching rules without triggering detections for restricted content.

Step 3: Payload / Execution Method No specific payload is required beyond the Range header manipulation. The attacker iterates through the resource by adjusting the byte range in successive requests. For example:

  • Range: bytes=0-99
  • Range: bytes=100-199
  • Range: bytes=200-299
  • ... and so on, until the full resource is retrieved.

Each request is a legitimate HTTP request from the protocol's perspective, making the attack difficult to distinguish from normal partial-content requests (e.g., from media players or download managers).

Step 4: Post-Exploitation Impact The attacker accumulates all response slices and reconstructs the full restricted resource client-side. If the resource contains sensitive data (e.g., credentials, internal documents, source code, API keys), the attacker gains unauthorized access to that data. The WAF remains unaware that an exfiltration occurred because no single response matched a detection rule.

Impact Assessment

CVSS Analysis (Score: 7.5): Based on the CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N:

  • Attack Vector: Network (AV:N) — Exploitable remotely over the network.
  • Attack Complexity: Low (AC:L) — No special conditions required; attacker only needs to send HTTP requests.
  • Privileges Required: None (PR:N) — No authentication required.
  • User Interaction: None (UI:N) — No user action needed.
  • Scope: Unchanged (S:U) — The vulnerability affects only the WAF/CRS component, not other security boundaries.
  • Confidentiality Impact: High (C:H) — Full disclosure of a restricted resource is possible.
  • Integrity Impact: None (I:N) — Data is not modified.
  • Availability Impact: None (A:N) — Service availability is not affected.

Business Impact: Organizations using affected CRS versions may experience data exfiltration despite deploying a WAF, giving a false sense of security. The bypass undermines compliance requirements that rely on WAF detection (e.g., PCI DSS), and allows attackers to access restricted data that they would otherwise be blocked from retrieving.

Blast Radius: Any web application protected by ModSecurity with CRS 3.0.x, 3.1.x, 3.2.1, or 3.3.2 is exposed. The attack does not require prior access, making it remotely exploitable by unauthenticated attackers. The severity is elevated because the attacker can selectively extract any resource the backend serves, including those specifically flagged as restricted by CRS rules.

Detection Guidance

The following detection resources are provided for SOC teams to identify potential exploitation attempts.

Sigma Rule

title: Suspicious HTTP Range Header Stream - CVE-2022-39958
id: 3f6f6a2e-3d1f-4e6a-b31d-1f2a1c4e8b7d
status: experimental
description: Detects sequential HTTP requests with small byte Range headers to the same URL, indicating possible response body bypass exfiltration of a restricted resource.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2022-39958
tags:
    - attack.exfiltration
    - attack.t1041
    - cve.2022-39958
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-method: 'GET'
        http_user_agent|contains: null  # any UA
        cs-uri-query|contains: null     # any query
    condition: selection
    timeframe: 60s
    # Placeholder for additional correlation logic requiring a backend that can group by client and URL
    # Real-world rule should count Range header requests per client and URL within a short window
    # and alert when count > threshold (e.g., 10) and each Range value is a small byte range.
fields:
    - c-ip
    - cs-uri-stem
    - sc-status
    - cs(User-Agent)
falsepositives:
    - Legitimate partial content requests from media players, download managers, or range-requesting PDF viewers
    - Applications that legitimately use Range headers for server-side processing
level: medium

YARA Rule

rule CVE_2022_39958_ModSecurity_CRS_Response_Body_Bypass
{
    meta:
        author = "Valtersit Security Research"
        description = "Detects HTTP request patterns consistent with Range header byte-range enumeration targeting a single resource"
        date = "2023-10-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2022-39958"
        severity = "high"
        cve = "CVE-2022-39958"
    strings:
        $range_header = "Range: bytes=" ascii nocase
        $small_range1 = /Range: bytes=\d+-\d+/ ascii nocase
        $http_get = "GET " ascii
    condition:
        # This YARA rule is intended for network packet captures (PCAP) that include HTTP headers.
        // Basic pattern: contains a Range header with a single byte range
        $range_header and $small_range1
        // A more sophisticated rule would count Range headers from the same IP to the same URI,
        // which YARA alone cannot easily perform; this rule flags any presence of the pattern.
        // For full accuracy, pair with other correlation tools.
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2022-39958 - ModSecurity CRS Response Body Bypass via Range Header Enumeration"; flow:to_server,established; content:"Range: bytes="; http_header; pcre:/Range:\s*bytes=\d+-\d+/i; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-information-leak; reference:cve,2022-39958; sid:1002234; rev:1;)

Elastic Detection

// Elastic EQL query to detect multiple small Range requests to the same URI from the same source IP
sequence by source.ip, url.path with maxspan=60s
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]
  [http where request.method == "GET" and headers.range != null]

Note: Adjust threshold and time window based on baseline network behavior.

Splunk SPL Query

sourcetype=access_combined | where method="GET" | regex header_accept=".*" | 
eval range_present = if(match(headers,"(?i)Range: bytes=\d+-\d+"),1,0) | 
where range_present=1 | 
stats dc(_raw) as unique_requests count as req_count values(headers) as range_headers by src_ip, uri_path | 
where req_count > 10 | 
addinfo | 
search req_count > 10

Wazuh OSSEC Rule

<group name="web,modsecurity,cve-2022-39958,">
    <rule id="100234" level="8">
        <decoded>http</decoded>
        <field name="method">GET</field>
        <match>Range: bytes=</match>
        <regex>Range:\s*bytes=\d+-\d+</regex>
        <description>CVE-2022-39958: Repeated small Range header requests may indicate ModSecurity CRS response body bypass</description>
        <group>attack.exfiltration,</group>
        <info type="cve">CVE-2022-39958</info>
        <mitre>
            <id>T1041</id>
        </mitre>
    </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 — LIKELY — Two independent sources (CNA and Debian) confirm the fix.

1. Immediate Mitigations (if patch cannot be applied immediately):

  • Configure the CRS paranoia level to 3 or higher. This activates additional rules that increase anomaly detection sensitivity and may catch the small-range response fragments.
  • Monitor HTTP access logs for anomalous patterns of multiple Range header requests to the same URL from a single source IP within a short time window.
  • Apply an additional layer of external WAF rule to block or flag requests with Range headers pointing to sensitive endpoints.
  • If the backend supports it, disable Range header processing for sensitive resources or force full-response delivery.

2. Patch / Upgrade Steps:

  • For CRS 3.0.x or 3.1.x: Upgrade to a supported version (3.2.2 or 3.3.3). Note that 3.0.x and 3.1.x are legacy; moving to 3.2.x/3.3.x may require rule-set migration.
  • For CRS 3.2.1: Upgrade to 3.2.2.
  • For CRS 3.3.2: Upgrade to 3.3.3.
  • After upgrading, rerun existing rule-set integration tests to verify that custom exclusions or modifications remain compatible.

3. Long-Term Hardening:

  • Enable the highest reasonable CRS paranoia level that the application can tolerate without excessive false positives.
  • Implement stateful session-based detection in the WAF or SIEM to correlate multiple partial-content requests to the same resource.
  • Regularly review WAF logs specifically for partial-content (HTTP 206) responses and investigate clusters of same-IP requests.
  • Subscribe to OWASP CRS release announcements and harden deployment pipelines to auto-update upon stable releases.
  • Consider using CDN or reverse-proxy caching that normalizes or buffers responses, making byte-range enumeration less efficient.

References

  1. National Vulnerability Database — NVD Entry for CVE-2022-39958: https://nvd.nist.gov/vuln/detail/CVE-2022-39958
  2. OWASP ModSecurity Core Rule Set Project — Official Site and Release Notes: https://coreruleset.org/
  3. Debian Security Tracker — CVE-2022-39958: https://security-tracker.debian.org/tracker/CVE-2022-39958
  4. OWASP CRS GitHub Repository — For release history and commit details for versions 3.2.2 and 3.3.3: https://github.com/coreruleset/coreruleset

At the time of writing, no known exploit-in-the-wild campaigns have been reported for CVE-2022-39958, and it is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

http.title:"ModSecurity"
http.headers.server:"ModSecurity"
http.title:"test page for the ModSecurity"
http.header:"X-Powered-By: ModSecurity"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2022-39958/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.