Cloudflare said it fixed a flaw in Cloudflare Containers that allowed a paying customer to read data that other customers' containers had left behind on the same server. The important nuance from the disclosure is that the exposed data came from disk space that earlier containers had used and released, not from live workloads, and the attacker could not select a specific victim tenant. The source item does not name a CVE, CVSS score, affected version range, region, or public proof of concept, so defenders should treat this as a fixed managed-service isolation failure rather than a patchable customer-side software bug.
For security teams, the risk is not that every Cloudflare Containers customer is necessarily compromised. The risk is that ephemeral storage was not reliably sanitized before reuse in a multi-tenant environment. If secrets, tokens, cached credentials, customer records, build artifacts, request bodies, TLS session material, logs, or source code were ever written to container disk during an affected window, they should be considered potentially exposed until proven otherwise.
This matters because multi-tenant platforms are built on one core promise: strong isolation between customers sharing physical hosts. A leftover-data flaw is usually less dramatic than a live container escape, but it can still be high impact because disk remnants are often rich in secrets and sensitive data. Defenders should act now by confirming exposure scope with Cloudflare, rotating high-value credentials that may have touched container disk, increasing egress and DLP monitoring, and applying the same lesson to self-managed Kubernetes, containerd, Docker, CI runners, and serverless build environments.
Technical analysis
Affected product: Cloudflare Containers, Cloudflare's managed container offering. The news item does not provide a customer-installable version, CVE identifier, or CVSS score. The issue was in provider-side storage reuse/isolation logic rather than a tenant image vulnerability.
How this class of flaw works: in multi-tenant container platforms, many customer workloads are scheduled onto shared hosts. When a container exits, its writable layer, ephemeral volume, temporary filesystem, page cache, block allocation, or snapshot space may be released back to a host pool. If the platform reassigns that space without reliably zeroing, cryptographically erasing, TRIM/discard handling, key destruction, or otherwise preventing read access to stale blocks, a later tenant can receive allocations containing remnants of earlier tenants' data. The later tenant may be able to read uninitialized or previously used disk regions through normal file reads, raw device access in privileged contexts, debug utilities, or simply by allocating space and inspecting what is present.
Exploitation requirements based on the disclosure: the attacker needed to be a paying Cloudflare customer able to run containers, but did not need to break into a live neighboring workload and could not choose whose remnants were returned. That makes this an opportunistic cross-tenant exposure, not a targeted compromise primitive by itself. However, opportunistic exposure can still become targeted if attackers run many containers, repeatedly recycle allocations, automate carving of disk remnants, and search for high-value patterns such as bearer tokens, private keys, session cookies, database rows, source archives, and customer PII.
Defender perspective on the attack chain: provision container -> receive reused storage allocation -> read leftover blocks or files -> carve for secrets and sensitive records -> exfiltrate through allowed egress -> use recovered secrets against cloud APIs, CI/CD, SaaS, or customer data stores. The first two stages occurred inside Cloudflare's managed boundary, so customers generally cannot directly prove or disprove reads from their own host telemetry. The most reliable tenant-side evidence is downstream: unexpected use of exposed credentials, anomalous egress from container workloads, canary secret touches, DLP hits, and audit-log anomalies in systems whose tokens may have been stored on disk.
Exploitation status: the item says Cloudflare fixed the flaw after researcher disclosure. It does not state confirmed active exploitation, a public PoC, or CISA KEV inclusion. Treat public exploitation as unconfirmed, but treat data remanence as a real exposure pathway for any sensitive material written to ephemeral container disk during the relevant period. Ask Cloudflare for written confirmation of the fix date, affected regions or clusters if applicable, whether your accounts were in scope, whether provider telemetry showed suspicious remnant harvesting, and what secure-erasure controls are now enforced.
Immediate defensive posture
Prioritize secrets and data that are frequently present on disk even when teams intend to keep them in memory: npm/pip caches, compiler caches, layer build contexts, crash dumps, framework temp files, local queues, SQLite databases, request/response debug logs, TLS keylogs, CI checkout directories, and application scratch files. If a workload was designed to be stateless, verify that it is truly stateless under failure conditions. Many 'stateless' services still spill to /tmp, /var/tmp, cache dirs, or container writable layers.
Rotate credentials using risk order. Start with cloud IAM session material, registry tokens, deploy keys, database passwords, API keys, signing keys, webhook secrets, JWT signing keys, OAuth client secrets, SSH keys, mTLS private keys, and any customer-data encryption keys that could have been present unprotected in container storage. Do not rotate blindly forever; build an inventory from deployment manifests, image layers, entrypoints, environment injection methods, mounted volumes, and application config so the rotation is complete and auditable.
Detection and response
Cloudflare owns the decisive server-side telemetry for this specific incident. Customer-side hunting should therefore focus on two things: evidence that sensitive data reached disk in your own containers, and evidence that exposed secrets or data are being used or moved. The detections below are written for analogous self-managed container hosts and for tenant-side monitoring around Cloudflare workloads. They are intentionally behavior-focused; they are not a claim that Cloudflare hosts are directly observable by customers.
---
title: Linux Container Host Raw Disk or Filesystem Debug Access
id: 4e2a1b90-7c5f-4b6a-9d21-8f7c2b91a101
status: experimental
description: Detects processes on Linux container hosts inspecting raw block devices or using filesystem debug tools that could expose stale tenant data from reused storage.
references:
- https://thehackernews.com/2026/09/cloudflare-fixes-flaw-that-let-one.html
- https://attack.mitre.org/techniques/T1005/
author: Security Arsenal
date: 2026/09/19
tags:
- attack.collection
- attack.t1005
- attack.discovery
- attack.t1083
logsource:
category: process_creation
product: linux
detection:
selection_tools:
Image|endswith:
- '/dd'
- '/debugfs'
- '/xfs_db'
- '/e2image'
- '/blkid'
- '/lsblk'
- '/blkdiscard'
- '/hexdump'
- '/strings'
selection_paths:
CommandLine|contains:
- '/dev/'
- '/proc/1/root'
- '/var/lib/containerd'
- '/var/lib/docker'
- '/run/containerd'
condition: selection_tools and selection_paths
falsepositives:
- Storage administration, backup agents, forensic acquisition, and node troubleshooting
level: high
---
title: Container or Host Namespace Inspection for Adjacent Tenant Artifacts
id: 7b4dd21f-0f13-4cf2-9a55-8d2d3e901b77
status: experimental
description: Detects attempts to enter host or init namespaces, inspect container runtime state, or read root filesystem paths associated with other containers on shared Linux hosts.
references:
- https://thehackernews.com/2026/09/cloudflare-fixes-flaw-that-let-one.html
- https://attack.mitre.org/techniques/T1611/
author: Security Arsenal
date: 2026/09/19
tags:
- attack.privilege_escalation
- attack.t1611
- attack.discovery
- attack.t1083
logsource:
category: process_creation
product: linux
detection:
selection:
CommandLine|contains:
- 'nsenter'
- '/proc/1/ns'
- '/proc/1/root'
- 'crictl inspect'
- 'ctr namespaces'
- 'containerd-shim'
- '/run/containerd/io.containerd.runtime'
- '/var/lib/containerd/io.containerd.snapshotter'
falsepositives:
- Node problem detectors, runtime debugging by platform engineers, security agents, and CNI troubleshooting
level: medium
---
title: Secret Pattern Carving From Ephemeral Container Paths
id: 1d6f8c42-55af-4c60-8f4e-0f5d69b2c903
status: experimental
description: Detects use of grep, strings, ripgrep, or find against temp, cache, overlay, runtime, and block paths for tokens, keys, cookies, and credential patterns on Linux hosts.
references:
- https://thehackernews.com/2026/09/cloudflare-fixes-flaw-that-let-one.html
- https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/09/19
tags:
- attack.credential_access
- attack.t1552.001
- attack.collection
- attack.t1005
logsource:
category: process_creation
product: linux
detection:
selection_tools:
Image|endswith:
- '/grep'
- '/rg'
- '/strings'
- '/find'
- '/awk'
- '/sed'
selection_terms:
CommandLine|contains:
- 'PRIVATE KEY'
- 'Authorization'
- 'Bearer'
- 'AWS_SECRET'
- 'api_key'
- 'client_secret'
- 'session'
- '/tmp'
- '/var/tmp'
- '/var/lib/containerd'
- '/var/lib/docker'
- '/dev/'
condition: selection_tools and selection_terms
falsepositives:
- Secret scanners, DLP agents, backup tooling, and developer debugging
level: high
// Hunt Linux host telemetry ingested into Sentinel via Syslog/CEF for raw disk reads, runtime-state inspection, and secret carving.
// Tune allowlists for backup, EDR, forensics, and node administration before production deployment.
let ToolNames = dynamic(['dd','debugfs','xfs_db','e2image','blkid','lsblk','blkdiscard','hexdump','strings','nsenter','crictl','ctr','grep','rg','find']);
let SuspiciousTerms = dynamic(['/dev/','/proc/1/root','/proc/1/ns','/var/lib/containerd','/var/lib/docker','/run/containerd','PRIVATE KEY','Bearer','AWS_SECRET','client_secret','api_key','containerd-shim']);
Syslog
| where TimeGenerated >= ago(14d)
| extend ProcessName = tostring(split(ProcessName, '/')[-1])
| where ProcessName in~ (ToolNames)
| extend CommandLine = tostring(ProcessName) + ' ' + tostring(CommandLine)
| where CommandLine has_any (SuspiciousTerms)
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), DistinctHosts = dcount(Computer), SampleCommands = make_set(CommandLine, 5) by Computer, ProcessName, AccountName
| order by Count desc;
DeviceProcessEvents
| where TimeGenerated >= ago(14d)
| where FileName in~ ('dd','debugfs','xfs_db','e2image','blkid','lsblk','blkdiscard','hexdump','strings','nsenter','crictl','ctr','grep','rg','find')
| where ProcessCommandLine has_any ('/dev/','/proc/1/root','/var/lib/containerd','/var/lib/docker','PRIVATE KEY','Bearer','AWS_SECRET','client_secret','api_key')
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, FolderPath, SHA256
| order by TimeGenerated desc;
CommonSecurityLog
| where TimeGenerated >= ago(14d)
| where Message has_any ('leftover','cross-tenant','Cloudflare Containers','container disk','debugfs','/dev/','Bearer','PRIVATE KEY')
| project TimeGenerated, SourceIP, DestinationIP, DeviceVendor, DeviceProduct, Message
| order by TimeGenerated desc;
-- Velociraptor artifact: audit Linux container hosts for processes touching block devices, container runtime state, or secret-like strings.
-- Deploy as a hunt against self-managed Kubernetes, Docker, containerd, CI runners, and build fleets.
LET suspicious_proc = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '/dev/|/proc/1/root|/proc/1/ns|/var/lib/containerd|/var/lib/docker|/run/containerd'
OR CommandLine =~ 'debugfs|xfs_db|e2image|blkdiscard|nsenter|crictl inspect|ctr namespaces'
OR CommandLine =~ 'PRIVATE KEY|Bearer|AWS_SECRET|client_secret|api_key';
LET runtime_mounts = SELECT FullPath AS Path, Size, ModTime
FROM glob(globs='/proc/*/mountinfo')
LIMIT 1000;
SELECT 'process' AS ArtifactType, suspicious_proc.Pid AS Pid, suspicious_proc.Name AS Name, suspicious_proc.CommandLine AS Detail, suspicious_proc.Exe AS Path, suspicious_proc.Username AS User, suspicious_proc.CreateTime AS Timestamp
FROM suspicious_proc
UNION ALL
SELECT 'mountinfo' AS ArtifactType, NULL AS Pid, NULL AS Name, Path AS Detail, Path AS Path, NULL AS User, ModTime AS Timestamp
FROM runtime_mounts;
Use the following read-only audit on self-managed Linux/Kubernetes nodes to find risky storage patterns comparable to the provider-side failure. Run it from an admin jump host with kubectl access and node SSH as appropriate. Do not run destructive secure-erasure commands automatically in production.
#!/usr/bin/env bash
set -euo pipefail
# Kubernetes: find pods that can reach host storage, share host namespaces, or run privileged.
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.hostPID==true or .spec.hostIPC==true or .spec.hostNetwork==true or any(.spec.containers[]?; .securityContext.privileged==true) or (.spec.volumes[]?.hostPath != null)) | [.metadata.namespace,.metadata.name] | @tsv'
# Kubernetes: list emptyDir volumes that are not memory-backed; these may persist on node disk while pod lives.
kubectl get pods -A -o json | jq -r '.items[] as $p | ($p.spec.volumes[]? | select(.emptyDir != null and (.emptyDir.medium != "Memory")) | [$p.metadata.namespace,$p.metadata.name,.name] | @tsv)'
# Node: confirm runtime paths are root-only and not world-readable.
for d in /var/lib/containerd /var/lib/docker /run/containerd /var/lib/kubelet; do
if [ -e "$d" ]; then stat -c '%A %U:%G %n' "$d"; fi
done
# Node: show block devices and mounted ephemeral disks for context only.
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINT,MODEL,SERIAL
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | egrep 'containerd|docker|kubelet|ephemeral|/tmp|/var/tmp' || true
# Node: identify debugging tools that increase the blast radius if a container gains unexpected host access.
for t in debugfs xfs_db e2image blkdiscard dd hexdump strings nsenter crictl ctr; do command -v "$t" 2>/dev/null || true; done
# Runtime: list running containers and image IDs for inventory.
if command -v crictl >/dev/null 2>&1; then crictl ps --no-trunc; fi
if command -v ctr >/dev/null 2>&1; then ctr -n k8s.io containers list 2>/dev/null || true; fi
# Safe hardening examples to apply separately, not by default:
# kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted
# Remove hostPath volumes, set readOnlyRootFilesystem: true, use emptyDir.medium: Memory for scratch, drop CAP_SYS_ADMIN/CAP_SYS_PTRACE, enable seccomp and SELinux/AppArmor, and remove debug tools from production images.
Response actions for Cloudflare Containers customers
Open a Cloudflare support or security case and request the fixed-date, scope, regions or clusters, provider-side telemetry results for your account, and confirmation of the sanitization control now used for released storage. If Cloudflare provides an incident notice or advisory, bind your rotation window to that scope rather than guessing.
Search your own estate for secrets that could have existed on disk. Review application logging levels, crash-dump settings, framework temp directories, package caches, CI artifacts copied into images, local queues, SQLite or embedded databases, and debugging sidecars. Check whether environment variables were ever materialized to files by entrypoints, templates, or orchestration wrappers. Environment variables are not automatically safe; many systems write them into config files before startup.
Deploy canary secrets and data tripwires going forward. Place unique low-privilege canary tokens in approved test workloads and monitor for any use from impossible locations or principals. Use DLP and egress controls to detect bulk reads of customer records, unexpected archives, encoded blobs, rare user agents, and new destinations from container workloads. In Sentinel or your SIEM, alert when a known deploy token, registry credential, cloud access key, webhook secret, or mTLS identity is used outside its expected ASN, workload identity, region, or time window.
Review downstream audit logs for credential misuse: Cloudflare audit logs, cloud IAM logs, IdP sign-ins, registry pulls, Git provider events, CI job starts, database authentication, Kubernetes API audit logs, WAF/Bot events, and SaaS admin logs. Look for token use after container shutdown times, impossible geography, new device fingerprints, unexpected API enumeration, and creation of persistence such as new API keys, OAuth grants, runners, deploy keys, or service accounts.
Remediation and hardening
For Cloudflare-managed containers, the core remediation is provider-side and is reported as fixed. Customers cannot patch a managed isolation control, but they can reduce impact by architecture: keep secrets out of disk entirely, prefer memory-backed ephemeral storage, set read-only root filesystems, inject secrets at runtime with short TTLs, avoid writing request bodies and customer data to scratch paths, disable crash dumps in production images, remove debugfs/xfs_db/dd-style tools from final images, and encrypt any unavoidable local cache with keys that are destroyed at container termination.
For self-managed Kubernetes and container fleets, enforce restricted Pod Security Standards, prohibit hostPath except tightly allowlisted node agents, block privileged containers, block hostPID/hostIPC, drop dangerous capabilities, require seccomp and SELinux/AppArmor, pin runtimes to supported versions, and enable node image garbage collection plus encrypted ephemeral storage where the platform supports it. For bare-metal or dedicated multi-tenant nodes, use per-tenant encrypted volumes with key destruction on release, verify discard/TRIM behavior with your storage stack, and document secure-erasure guarantees for SSDs because overwrite patterns alone are not reliable on flash.
Operational validation should become a release gate. Before promoting a platform change, run a controlled test: write a unique marker into one tenant container, terminate it, allocate fresh storage under load, and verify the marker is unreadable by the next allocation. Repeat across instance types, zones, storage backends, and snapshot paths. Require platform teams to state, in writing, which of the following is used: zero-fill, cryptographic erase with key destruction, block discard with verified controller behavior, dedicated non-shared volumes, or no reuse.
Finally, update incident runbooks. Cross-tenant cloud isolation failures require a different playbook than malware: preserve deployment timelines, inventory secret types by workload, coordinate provider scope requests, rotate in dependency order, monitor downstream misuse for weeks, and record which secrets were provably memory-only versus disk-materialized. The fastest way to lose control of this class of incident is to rotate only obvious passwords while cached tokens and build-time secrets remain valid.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.