Cloudflare Containers Cross-Tenant Data Exposure: What Defenders Must Audit and Remediate Now

Cloudflare has remediated a serious multi-tenant isolation failure in its Containers and Sandboxes products that allowed any customer holding a Workers Paid account to recover residual data left behind by other customers' containers running on the same physical host. In plain terms: tenant A's container could read leftovers from tenant B's workload because container state was not being fully sanitized between executions on shared infrastructure.

This class of flaw — a cross-tenant isolation break — is among the most damaging categories of vulnerability in cloud computing. It doesn't require the victim to do anything wrong. If your organization deployed containers or sandboxed workloads on Cloudflare's platform, your data could have been exposed to a co-tenant you have never heard of, through no misconfiguration of your own. No CVE identifier has been published for this issue at the time of writing, and Cloudflare has stated the vulnerability is fixed at the platform level — but "fixed by the vendor" does not mean "zero residual risk for your data."

Defenders need to act on three fronts: (1) determine whether your organization ran sensitive workloads on affected Cloudflare services during the exposure window, (2) assume any secrets, tokens, or data processed in those containers may have been observed and rotate accordingly, and (3) build detection coverage for the general pattern of cross-tenant data scavenging, because this bug class will appear again — on this platform or another.

Technical Analysis

Affected Products and Platforms

• Cloudflare Containers — Cloudflare's container runtime offering, which runs customer container workloads on shared physical hosts within Cloudflare's network.
• Cloudflare Sandboxes — the ephemeral execution environment used for isolated code execution on the Workers platform.
• The exploitation prerequisite was low: any Workers Paid account. This is not a privileged-enterprise-only attack path; a paid Workers subscription is inexpensive and available to anyone, which dramatically widens the threat actor pool.

How the Vulnerability Worked (Defender's View)

The flaw is a residual data exposure / incomplete tenant sanitization issue. On shared container infrastructure, the platform is responsible for ensuring that when tenant B's container terminates, no memory pages, disk artifacts, temporary files, caches, or environment data remain accessible to the next container scheduled on that host. In this case, that sanitization boundary failed:

1. Co-tenancy requirement: The attacker's container had to be scheduled on the same physical host as a victim's container — something the attacker could not directly control, but could influence probabilistically by repeatedly launching containers (a well-known "instance spraying" technique in cloud attacks).
2. Residual data recovery: Once co-located, the attacker's container could recover leftover artifacts from prior tenant workloads — which in containerized environments typically means filesystem remnants, cached layers, environment variables, or in-memory data not properly zeroed between tenants.
3. Extraction: Recovered data could be exfiltrated through the attacker's own container's normal egress, which looks indistinguishable from legitimate workload traffic from the platform's perspective.

This maps to MITRE ATT&CK T1530 (Data from Cloud Storage) conceptually, and more precisely to the failure mode described by CWE-459 (Incomplete Cleanup) and CWE-668 (Exposure of Resource to Wrong Sphere). The defining characteristic defenders must internalize: the attack leaves no footprint in the victim's environment. The victim tenant's logs show nothing abnormal. Detection must therefore happen either at the platform level (Cloudflare's responsibility, now patched) or via behavioral analytics on the attacker's side — which, for your organization, means detecting if someone else's tenant on shared infrastructure behaves like a data scavenger is not something you can directly observe.

Exploitation Status

• In-the-wild exploitation: Not publicly confirmed. Cloudflare fixed the issue following disclosure and has not (as of publication) reported evidence of malicious exploitation at scale.
• CISA KEV: Not listed — no CVE has been assigned.
• PoC availability: No public proof-of-concept at time of writing. However, the technique class (co-tenant residual data scavenging) is well documented in cloud security research, and the low barrier to entry (a paid Workers account) means defenders should treat the pre-patch exposure window as potentially exploited, particularly for high-value data.

The correct risk posture: assume exposure, verify impact. You cannot prove a negative here — you cannot prove nobody scraped your container's residual data. Treat secrets and sensitive data processed on the platform during the affected period as compromised until rotation is complete.

Detection & Response

A candid note from the trenches: there is no high-fidelity endpoint rule that detects "another tenant read my container's leftovers on Cloudflare's host" — that telemetry lives on Cloudflare's side, and they have remediated the flaw. What a mature SOC can do is (a) detect the general behavioral pattern of cross-tenant scavenging on container infrastructure you operate yourself (the same bug class affects Kubernetes, ECS, and self-managed multi-tenant hosts), and (b) hunt for the downstream consequences — leaked credentials being used, anomalous access to data that only existed in container memory. The rules below target those observable layers. Deploy them against your own container estates and identity telemetry, and use them as a template for evaluating any multi-tenant platform risk.

Sigma Rules

The following rules target the attacker-side behaviors of residual-data scavenging on shared container hosts — applicable to any container infrastructure you monitor (EKS, GKE, AKS, on-prem Kubernetes, Docker hosts). They detect containers probing for other tenants' artifacts and accessing host-level paths that should be invisible inside a properly isolated container.

---
title: Container Process Accessing Host or Co-Tenant Filesystem Artifacts
id: 3f8a2c41-9d6e-4b7a-a1c2-5e8f9d0b3a44
status: experimental
description: Detects processes inside container workloads accessing host-level container storage paths, shared memory segments, or other container layer directories, consistent with cross-tenant residual data scavenging.
references:
  - https://www.bleepingcomputer.com/news/security/cloudflare-fixes-containers-cross-tenant-flaw-exposing-customer-data/
  - https://attack.mitre.org/techniques/T1530/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1530
  - attack.t1611
logsource:
  category: process_creation
  product: linux
detection:
  selection_paths:
    CommandLine|contains:
      - '/var/lib/docker/overlay2/'
      - '/var/lib/containerd/'
      - '/run/containerd/'
      - '/dev/shm/'
      - '/proc/1/root'
      - '/var/lib/kubelet/pods/'
  selection_tools:
    Image|endswith:
      - '/find'
      - '/grep'
      - '/strings'
      - '/cat'
      - '/tar'
      - '/dd'
  condition: selection_paths and selection_tools
falsepositives:
  - Container debugging by platform engineers with host mounts intentionally attached
  - Legitimate node-level monitoring agents (Datadog, Falco sidecars)
level: high
---
title: Container Enumerating Neighboring Namespaces or Mount Tables
id: 8b1e5d72-4c3a-4f68-b9d1-2a7c6e5f1098
status: experimental
description: Detects enumeration of mount namespaces, cgroup data, or process listings outside the container's own namespace — a precursor to identifying co-tenant artifacts on a shared host.
references:
  - https://attack.mitre.org/techniques/T1611/
  - https://attack.mitre.org/techniques/T1057/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.discovery
  - attack.t1611
  - attack.privilege_escalation
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - 'lsns'
      - 'nsenter'
      - 'unshare --mount'
      - '/proc/mounts'
      - 'mount | grep'
      - 'cat /proc/self/cgroup'
      - 'crictl ps'
      - 'ctr containers list'
  filter_runtime:
    Image|endswith:
      - '/containerd'
      - '/kubelet'
      - '/dockerd'
  condition: selection and not filter_runtime
falsepositives:
  - Cluster administrators performing node troubleshooting
  - CNI/service mesh initialization in privileged init containers
level: medium
---
title: Bulk Archive Creation Followed by Egress From Container Workload
id: c4d7a913-2e5b-4f80-a6d3-9b1c8e2f4577
status: experimental
description: Detects creation of compressed archives of filesystem content followed by outbound transfer tooling execution inside a container, consistent with staging and exfiltration of scavenged co-tenant data.
references:
  - https://attack.mitre.org/techniques/T1560/
  - https://attack.mitre.org/techniques/T1041/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exfiltration
  - attack.t1041
  - attack.t1560.001
logsource:
  category: process_creation
  product: linux
detection:
  selection_archive:
    CommandLine|contains:
      - 'tar -cz'
      - 'tar -czf'
      - 'zip -r'
      - '7z a'
  selection_exfil:
    CommandLine|contains:
      - 'curl -T'
      - 'curl --upload-file'
      - 'curl -F'
      - 'wget --post-file'
      - 'aws s3 cp'
      - 'rclone copy'
      - 'nc -w'
  condition: 1 of selection_*
falsepositives:
  - CI/CD pipelines packaging build artifacts inside containers
  - Legitimate backup or log-shipping jobs
level: medium

KQL — Microsoft Sentinel / Defender

For organizations ingesting container host syslog, Kubernetes audit logs, or Defender for Endpoint telemetry into Sentinel, this query hunts for the scavenging pattern: containerized processes touching host container-runtime storage paths or performing namespace enumeration, correlated with subsequent large outbound transfers from the same workload identity.

// Hunt: Cross-tenant residual data scavenging behavior on container hosts
// Data sources: Syslog/CEF from Kubernetes nodes, Defender for Endpoint (MDE) container support
let ScavengeIndicators = dynamic([
    "/var/lib/docker/overlay2/", "/var/lib/containerd/", "/run/containerd/",
    "/proc/1/root", "lsns", "nsenter", "crictl ps", "/dev/shm/"
]);
let SuspiciousProcs =
    union isfuzzy=true
    ( DeviceProcessEvents
      | where TimeGenerated > ago(7d)
      | where ProcessCommandLine has_any (ScavengeIndicators)
      | project TimeGenerated, DeviceName, InitiatingProcessAccountName,
                ProcessCommandLine, InitiatingProcessFileName, ReportId ),
    ( Syslog
      | where TimeGenerated > ago(7d)
      | where ProcessName in~ ("find","grep","strings","dd","tar")
      | where SyslogMessage has_any (ScavengeIndicators)
      | project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage )
    ;
let LargeEgress =
    DeviceNetworkEvents
    | where TimeGenerated > ago(7d)
    | where RemoteIPType == "Public"
    | summarize BytesSent=sum(SentBytes), Connections=count()
        by DeviceName, InitiatingProcessFileName, bin(TimeGenerated, 1h)
    | where BytesSent > 10485760;  // >10MB/hour from a single process
SuspiciousProcs
| summarize ScavengeEvents=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
            Commands=make_set(ProcessCommandLine, 5)
    by DeviceName
| join kind=leftouter (LargeEgress) on DeviceName
| where ScavengeEvents >= 1
| project DeviceName, FirstSeen, LastSeen, ScavengeEvents, Commands,
          InitiatingProcessFileName, BytesSent, Connections
| order by FirstSeen desc;

Also hunt your identity layer for the downstream consequence — credentials that existed only in container memory or environment variables suddenly being used from unfamiliar infrastructure:

// Hunt: Sign-ins using service credentials potentially harvested from container residuals
// Correlate service-principal sign-ins against known container egress IP ranges
SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == 0
| summarize SignInCount=count(), Locations=make_set(Location), IPs=make_set(IPAddress)
    by AppDisplayName, ServicePrincipalId, bin(TimeGenerated, 1d)
| where array_length(IPs) > 3 or SignInCount > 500   // sudden fan-out from new IPs
| order by TimeGenerated desc;

Velociraptor VQL

On container hosts and Kubernetes nodes under your control, this artifact hunts for processes with open file handles or command lines referencing other tenants' container layers and runtime storage — the host-side forensic evidence of scavenging.

-- Artifact: SecurityArsenal.CrossTenantScavenging
-- Hunt for processes accessing container runtime storage of other tenants
-- or holding open handles to overlay/containerd layer paths

LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '/var/lib/(docker|containerd)|/run/containerd|/proc/1/root|lsns|nsenter'
   AND NOT Exe =~ '(containerd|kubelet|dockerd|falco|datadog)'

LET handles = SELECT Pid, Name, FullPath
FROM handles()
WHERE FullPath =~ '/var/lib/docker/overlay2/[a-f0-9]{64}/diff|/var/lib/containerd/io.containerd'

SELECT * FROM procs
UNION ALL
SELECT Pid, NULL AS Ppid, Name, FullPath AS CommandLine, NULL AS Exe,
       NULL AS Username, NULL AS CreateTime
FROM handles

Remediation & Audit Script

Since the platform-side fix is Cloudflare's responsibility (and is deployed), your remediation work is an exposure audit: inventory every Cloudflare Containers/Sandbox workload, identify secrets that transited those workloads, and rotate them. This Bash script uses the Cloudflare API to inventory Workers and flag candidates for secret rotation.

#!/usr/bin/env bash
# cloudflare-container-exposure-audit.sh
# Inventory Workers/containers deployments and flag secrets for rotation
# Requires: curl, jq, and a Cloudflare API token with Workers read scope

set -euo pipefail

CF_API_TOKEN="${CF_API_TOKEN:?Set CF_API_TOKEN env var}"
CF_ACCOUNT_ID="${CF_ACCOUNT_ID:?Set CF_ACCOUNT_ID env var}"
API="https://api.cloudflare.com/client/v4"
REPORT="cf_exposure_audit_$(date +%Y%m%d_%H%M%S).txt"

echo "=== Cloudflare Containers/Sandbox Exposure Audit ===" | tee "$REPORT"
echo "Account: $CF_ACCOUNT_ID  Date: $(date -u)" | tee -a "$REPORT"

# 1. List all Workers scripts (candidate container/sandbox consumers)
echo -e "\n[1] Workers scripts in account:" | tee -a "$REPORT"
curl -sS -X GET "$API/accounts/$CF_ACCOUNT_ID/workers/scripts" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" | \
  jq -r '.result[]?.id // empty' | tee -a "$REPORT"

# 2. Enumerate secrets bound to each Worker (names only — values are write-only)
echo -e "\n[2] Secrets bound per Worker (ROTATE ALL that existed during exposure window):" | tee -a "$REPORT"
for SCRIPT in $(curl -sS -X GET "$API/accounts/$CF_ACCOUNT_ID/workers/scripts" \
    -H "Authorization: Bearer $CF_API_TOKEN" | jq -r '.result[]?.id // empty'); do
  echo "--- $SCRIPT" | tee -a "$REPORT"
  curl -sS -X GET "$API/accounts/$CF_ACCOUNT_ID/workers/scripts/$SCRIPT/secrets" \
    -H "Authorization: Bearer $CF_API_TOKEN" | \
    jq -r '.result[]? | "  SECRET: \(.name) (type: \(.type))"' | tee -a "$REPORT"
done

# 3. Pull audit logs for container/sandbox lifecycle events in the window
echo -e "\n[3] Recent audit log entries mentioning containers/sandboxes/workers:" | tee -a "$REPORT"
curl -sS -X GET "$API/accounts/$CF_ACCOUNT_ID/audit_logs?per_page=100" \
  -H "Authorization: Bearer $CF_API_TOKEN" | \
  jq -r '.result[]? | select((.action.type // "") | test("worker|container|sandbox"; "i")) |
         "\(.when)  \(.actor.email)  \(.action.type)  \(.resource.id // "n/a")"' | tee -a "$REPORT"

echo -e "\n=== ACTION ITEMS ===" | tee -a "$REPORT"
echo "1. Rotate EVERY secret listed in section [2] immediately." | tee -a "$REPORT"
echo "2. Review section [3] for unexpected deployment or modification events." | tee -a "$REPORT"
echo "3. Identify data classes processed by these workloads; assess breach-notification obligations." | tee -a "$REPORT"
echo "Report written to $REPORT"

Remediation

Cloudflare has patched the vulnerability at the platform level — there is no customer-side patch to apply, no version to upgrade, and no configuration toggle that would have prevented this. That reality should drive your response: your work is impact assessment and credential hygiene, not patching.

Immediate actions (within 72 hours):

1. Inventory exposure. Identify every workload your organization ran on Cloudflare Containers or Sandboxes during the exposure window. Use the audit script above or your infrastructure-as-code registry. Don't forget shadow-IT — developers frequently provision Workers Paid accounts outside central governance.
2. Rotate all secrets that transited affected workloads. API keys, database credentials, JWT signing keys, webhook secrets, TLS private keys — anything that was present in container memory, environment variables, or the container filesystem. This is non-negotiable: residual-data flaws mean you cannot rule out observation.
3. Review data classification. Determine whether regulated data (PII, PHI, cardholder data) was processed in affected containers. If so, engage legal counsel to assess notification obligations under GDPR, HIPAA, PCI-DSS, or applicable state breach laws — even absent confirmed exploitation, some frameworks require disclosure of potential exposure.
4. Pull Cloudflare audit logs. Look for anomalous modifications to your Workers, unexpected secret reads, or configuration changes during the window.

Strategic hardening (next 30-90 days):

• Never place long-lived secrets in ephemeral container environments. Use short-lived, workload-identity-issued credentials (OIDC federation, SPIFFE/SPIRE) with TTLs measured in minutes. If residual data leaks a token that expired an hour after the container died, the blast radius collapses.
• Minimize data-at-rest in containers. Process-in-memory, stream-don't-store, and explicitly zero sensitive buffers. Whatever your container leaves behind is exactly what a flaw like this exposes.
• Contract and SLA review. Ask Cloudflare (and every multi-tenant platform you use) for their tenant-isolation assurance documentation, sanitization procedures between container executions, and their disclosure timeline for this incident. Cross-tenant isolation failures should be covered in your vendor risk assessments under NIST CSF ID.SC and CIS Control 15 (Service Provider Management).
• Evaluate architecture for crown-jewel workloads. If a workload processes data whose exposure would be catastrophic, shared multi-tenant serverless/container infrastructure carries inherent co-tenancy risk that no SLA eliminates. Dedicated tenancy, confidential computing (memory-encrypted enclaves), or self-managed infrastructure may be warranted for that tier.
• Deploy the detections above against container infrastructure you do control. This bug class — incomplete cleanup between tenants — is not Cloudflare-specific. Kubernetes multi-tenancy, CI/CD runner reuse, and VM snapshot reuse all share the same failure mode.

Vendor advisory: Monitor Cloudflare's official blog and security advisories at https://www.cloudflare.com/ and the original reporting at https://www.bleepingcomputer.com/news/security/cloudflare-fixes-containers-cross-tenant-flaw-exposing-customer-data/ for updates on the disclosure timeline and any CVE assignment. There is currently no CISA KEV entry or mandated remediation deadline — this is a vendor-patched SaaS flaw, so your deadline is self-imposed: rotate secrets before someone uses them.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub