☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 9.1 🐛 CWE-440
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2024-32971

CVE-2024-32971 Security Advisory in Apollo
📅 PUBLISHED: 2024-05-02 06:43 UTC 🔄 UPDATED: 2026-10-09 05:42 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.73%
👁️
0.73% probability
18.2× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
9.1
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-32971 is a critical vulnerability in the Apollo Router, a Rust-based graph router for federated supergraphs using Apollo Federation 2. The flaw resides in the distributed query plan caching mechanism, specifically in the cache retrieval logic. Under specific conditions, the router may execute a modified version of a previously cached operation instead of the intended one. This can lead to unauthorized data access (e.g., fetching incorrect user types) or unintended mutations (e.g., deleting the wrong user record). The vulnerability has a CVSS score of 9.1, indicating a critical severity. No public exploit code or proof-of-concept is currently available, but the attack vector is network-based with low complexity and no authentication required. The recommended action is to upgrade to version 1.45.1 or downgrade to 1.43.2, or disable distributed query plan caching as a workaround.

⚡ 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

Supply Chain & Package Security

This vulnerability affects the Apollo Router, which is distributed as a Rust binary and container image. While not a direct package manager dependency (like NPM or PyPI), the router is a critical component in the GraphQL ecosystem. Organizations using Apollo Federation 2 should verify their deployment version and ensure they are not using versions 1.44.0 or 1.45.0. The supply chain risk is moderate, as the vulnerability is in the caching logic and not in a third-party library, but the impact on data integrity and confidentiality is severe.

CVSS Breakdown & Threat Level

  • CVSS Score: 9.1 (Critical)
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
  • Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely over the network.
  • Attack Complexity: Low (AC:L) – No special conditions or complex attack sequences are required.
  • Privileges Required: None (PR:N) – No authentication is needed to trigger the flaw.
  • User Interaction: None (UI:N) – The victim does not need to perform any action.
  • Scope: Unchanged (S:U) – The impact is confined to the vulnerable component.
  • Confidentiality Impact: High (C:H) – Unauthorized data access is possible.
  • Integrity Impact: High (I:H) – Incorrect mutations can be executed.
  • Availability Impact: High (A:H) – Unexpected errors can disrupt service.

Threat Level: Critical. The vulnerability allows an attacker to manipulate query plans cached in Redis, leading to data leakage, unauthorized modifications, and potential denial of service.

Deep Dive & Mechanics

The Apollo Router uses distributed query plan caching to improve performance by storing compiled query plans in Redis. When a client sends an operation (query, mutation, or subscription), the router checks the cache for a matching plan. The bug is in the cache retrieval logic: under certain conditions, the router may retrieve a plan that does not exactly match the requested operation. This can happen due to a race condition or improper cache key generation, causing the router to execute a plan intended for a different operation.

For example, if a client sends fetchUsers(type: ENTERPRISE), the router might retrieve a cached plan for fetchUsers(type: TRIAL) and execute it, returning incorrect data. Similarly, for mutations, a request to deleteUser(id: 10) could result in deleteUser(id: 12) being executed. The root cause is a defect in how the router constructs or validates cache keys, leading to cache collisions or stale plan reuse.

The vulnerability only affects routers configured with distributed query plan caching enabled. The caching mechanism is typically used in high-traffic environments to reduce latency. The impact is amplified because the router acts as a gateway to multiple subgraph servers, so a single incorrect plan can affect multiple backend services.

Vulnerable vs. Patched Code

The exact code change is not publicly available, but the patch addresses the cache retrieval logic. In vulnerable versions (1.44.0, 1.45.0), the router may incorrectly match a cached plan to a different operation. In patched versions (1.45.1+), the cache key generation is fixed to ensure uniqueness and proper validation.

Vulnerable Code (Conceptual):

// Simplified cache retrieval logic in vulnerable version
fn get_cached_plan(operation: &Operation) -> Option<QueryPlan> {
    let key = generate_cache_key(&operation); // Bug: key may be ambiguous
    redis.get(&key).map(|plan| deserialize_plan(plan))
}

Patched Code (Conceptual):

// Fixed cache retrieval logic in patched version
fn get_cached_plan(operation: &Operation) -> Option<QueryPlan> {
    let key = generate_cache_key(&operation); // Now includes full operation hash
    if let Some(plan) = redis.get(&key) {
        let plan = deserialize_plan(plan);
        // Additional validation to ensure plan matches operation
        if plan.matches(&operation) {
            return Some(plan);
        }
    }
    None
}

The patch likely includes a more robust cache key that incorporates the entire operation string, including variables, and adds a validation step before executing the cached plan.

Exploitation & Lab Setup

Red Team (Exploitation)

No public exploit code is available. However, an attacker could exploit this vulnerability by sending crafted GraphQL operations that trigger cache collisions. The attack requires knowledge of the cache key generation algorithm and the ability to send operations that produce the same cache key as a different operation.

Lab Setup:

  1. Deploy Apollo Router version 1.44.0 with distributed query plan caching enabled (Redis backend).
  2. Configure a simple supergraph with two subgraphs (e.g., users and orders).
  3. Send a query: query { fetchUsers(type: ENTERPRISE) { id name } }
  4. Observe that the router caches the plan.
  5. Send a different query: query { fetchUsers(type: TRIAL) { id name } }
  6. If the cache key collision occurs, the router may execute the plan for ENTERPRISE instead of TRIAL, returning incorrect data.

Exploitation Steps:

  • Identify the cache key pattern (e.g., based on operation name and arguments).
  • Craft operations that share the same cache key but have different semantics.
  • Send the malicious operation to trigger the incorrect plan execution.

Blue Team (Detection & Defense)

Detection:

  • Monitor Redis cache for unexpected key collisions or high cache hit rates for different operations.
  • Log all executed query plans and compare them to the requested operations.
  • Use anomaly detection to flag operations that return data not matching the request.

Defense:

  • Disable distributed query plan caching immediately if upgrading is not possible.
  • Implement strict input validation and operation whitelisting.
  • Use network segmentation to limit exposure of the Apollo Router.

Indicators of Compromise (IOCs)

  • Network: Unusual GraphQL operations that return data inconsistent with the request (e.g., requesting type: ENTERPRISE but receiving type: TRIAL data).
  • Logs: Router logs showing execution of query plans that do not match the incoming operation.
  • Redis: Cache entries with identical keys for different operations, or unexpected cache hits.
  • System: Unexpected mutations or data modifications in subgraph databases.

Detection Engineering

YARA Rule

rule CVE_2024_32971_Apollo_Router_Cache_Poisoning {
    meta:
        description = "Detects Apollo Router logs indicating cache key collision or incorrect plan execution"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-32971"
    strings:
        $log1 = "executing cached plan for operation" nocase
        $log2 = "cache key collision detected" nocase
        $log3 = "plan mismatch" nocase
    condition:
        any of them
}

Sigma Rule

title: Apollo Router Cache Key Collision
id: 8a9b3c2d-1e4f-5a6b-7c8d-9e0f1a2b3c4d
status: experimental
description: Detects potential exploitation of CVE-2024-32971 via cache key collisions in Apollo Router logs
author: Valters IT
logsource:
    product: apollo_router
    service: router
detection:
    selection:
        - "executing cached plan for operation"
        - "cache key collision detected"
        - "plan mismatch"
    condition: selection
falsepositives:
    - Legitimate cache hits under normal operation (rare)
level: high

Suricata Rule

alert tcp any any -> any 4000 (msg:"CVE-2024-32971 Apollo Router Cache Poisoning Attempt"; flow:to_server,established; content:"query"; http_uri; content:"fetchUsers"; http_uri; content:"type"; http_uri; pcre:"/type\s*:\s*\w+/i"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade to Apollo Router version 1.45.1 or later.
  2. If upgrade is not possible, downgrade to version 1.43.2.
  3. As a workaround, disable distributed query plan caching by setting supergraph.query_planning.caching.enabled = false in the configuration.

Long-term Measures:

  • Implement strict cache key validation and include operation hashes.
  • Regularly audit cache behavior and monitor for anomalies.
  • Apply the principle of least privilege to GraphQL operations.

Patch Details:

  • Fixed in version 1.45.1.
  • Withdrawn versions: 1.44.0, 1.45.0.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-32971/ · 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.