Alleged 569GB RapidFort Data Sale: Detailed Analysis of a Cloud and Software Supply-Chain Exposure Claim

On July 21, 2026, an underground threat actor using the handle "xpl0itrs" published a post claiming to sell 569GB of data allegedly obtained from RapidFort. The actor associated the material with a March 2026 operation called "CanisterWorm" and stated that the activity was conducted with TeamPCP.

The post is unusually detailed. It claims the dataset contains 140,061 files extracted from 48 Amazon S3 buckets and provides a bucket-by-bucket description covering container-hardening pipelines, vulnerability databases, DevOps automation, Kubernetes configurations, scanner data, cloud logs, billing exports, test environments, customer onboarding templates, and exposed credentials or cryptographic material.

The actor priced the dataset at USD 40,000, and alleged that some material relates to the U.S. Department of Defense. The post also claims that RapidFort had not notified customers or issued a breach statement.

As of July 23, 2026, CyberMon did not locate an official public statement from RapidFort confirming or denying this specific data-sale claim.

The post claims RapidFort as a victim of the CanisterWorm campaign attributed to "TeamPCP." CanisterWorm is a self-propagating software supply-chain campaign detected in March 2026. The actor provides encrypted-contact identifiers and an itemised "S3 Bucket Manifest," suggesting an attempt to demonstrate familiarity with the environment.

• The actor organised the claim around named S3 buckets, approximate sizes and workload descriptions.
• The post explicitly alleges exposure of five plaintext AWS credential files in one production-hardening bucket.
• The actor claims a large portion of the dataset belongs to a vulnerability-database pipeline.

• That any cloud credential, private key or kubeconfig is valid and unrevoked.
• That customer or Department of Defense data was actually exposed.
• That the alleged intrusion originated through CanisterWorm rather than another access path.

The second part of the post focuses on vulnerability-data stores and is important because it indicates that the alleged exposure may involve the internal knowledge layer of a security product, not only conventional application files. The actor lists development, test, pre-production and production repositories, which may indicate multiple stages of a data engineering pipeline.

The naming pattern distinguishes development clusters, test environments, production artifact storage and temporary or pre-artifact storage. This separation could provide an attacker with a broad view of how vulnerability data is collected, transformed, justified and released.

• Production vulnerability source data and per-distribution release-version mappings.
• AI-extended vulnerability data and daily snapshots, which the actor interprets as machine-learning-enhanced CVE enrichment.
• Java/Maven archives, Golang module mappings, Fedora and Red Hat source data, NVD synchronisation state and end-of-life release data.
• CVE justification records, unknown-package lists, upstream patch mappings and package-to-patch relationships.
• Pre-production and production compiled vulnerability-database updates, including timestamped compressed artifacts.
• RapidRisk analyst justifications and release-cadence dictionaries used for fix-time prediction.

Public CVE records are not, by themselves, confidential. The sensitive value lies in enrichment and operational context: internal analyst decisions, false-positive handling, patch mapping, unresolved packages, coverage gaps, release cadence, proprietary scoring logic and compiled update pipelines. Such material could reveal how a platform prioritises risk, where its knowledge base is incomplete, and which internal processes can be manipulated or bypassed.

An attacker could also compare production and pre-production datasets to identify upcoming changes, discover weaknesses in update validation, or target the ingestion pipeline with poisoned data. This is a research inference based on the claimed repository structure; it is not evidence that such manipulation occurred.

The post describes a central DevOps repository, Kubernetes kubeconfig files for Azure Kubernetes Service clusters, GitLab configuration containing database credentials and Azure storage keys, Jenkins Helm overrides, IP allowlists, Terraform state and CloudFormation templates used for customer onboarding.

A kubeconfig can contain cluster endpoints, certificate-authority data, user or service-principal authentication settings and context names. Its impact depends on whether the credentials remain valid and what privileges they hold. In a worst-case scenario, a privileged kubeconfig can permit an attacker to inspect secrets, alter workloads, deploy malicious containers or use cluster access as a bridge into connected cloud services.

The claimed GitLab and Jenkins material is similarly important. CI/CD systems frequently hold build tokens, registry credentials, deployment keys and environment-specific secrets. Compromise at this layer can affect not only stored data but also the integrity of software releases.

The post describes CloudFormation templates that create cross-account IAM roles through AWS STS AssumeRole permissions so RapidFort can scan customer EC2 images, snapshots and volumes. Public templates may be harmless; however, customer-specific parameters, external IDs, role ARNs, trust policies or embedded credentials could expose the structure of vendor-to-customer access relationships.

This changes the incident from a single-vendor data question into a potential third-party risk issue. Customers should determine whether their account identifiers, trust policies or vendor roles appear in the claimed material and whether those roles remain necessary and correctly restricted.

The actor lists a directory labelled as Department of Defense deployment configuration and claims a 3.7GB archive of pipeline automation. The post mentions platform release manifests, Helm overrides, AWS and SaaS configurations, ingress, cloud storage, resources and user configuration. CyberMon cannot determine whether these files are authentic, current, sensitive, classified or merely generic deployment templates. The claim should therefore be described as alleged and unverified.

The next part of the post expands the claim into scanner databases, vulnerability findings, software-bill-of-materials records, CDN logs, Kubernetes logs, CloudTrail data and AWS billing exports. These categories can be valuable for reconnaissance even where they do not contain direct credentials.

The actor claims an 18GB Redis backup from the scanner service containing AWS Inspector findings, package-analysis data, cross-distribution aliases, scanner-comparison scripts, CLI images, SPDX documents, SBOM scripts and vulnerability JSON. If authentic, a database backup may preserve relationships and metadata not visible in ordinary exports, including job history, customer references, internal identifiers or cached secrets.

• CloudFront logs allegedly covering September–October 2025, with timestamps, client IP addresses, methods, URIs, status codes, user agents and byte counts.
• Network Load Balancer logs associated with Kubernetes pods across production, staging and CI environments.
• CloudTrail data containing at least some AWS API call records.
• AWS Cost and Usage Reports covering February 2024 through January 2026, with resource tags such as customer, generated-by and purpose.

Logs and billing records can reveal customer names, internal naming conventions, usage timing, infrastructure regions, service relationships and operational scale. These details can improve phishing credibility, help identify high-value accounts, and guide cloud reconnaissance. The presence of customer tags would be especially important for downstream notification and scoping.

The final part of the post describes test and demo environments and concludes with a consolidated list of allegedly exposed credentials and secrets. Test systems are often treated as lower risk, but they can become an entry point where credentials are reused, network controls are weaker, or test workloads retain access to production services.

• Six AWS credential pairs.
• Two complete kubeconfig files using service-principal authentication for AKS clusters.
• GitLab PostgreSQL credentials and PostgreSQL replication-user credentials.
• A PostgreSQL password and a full Azure storage-account key.
• A key with broad access to GitLab registry storage.
• RSA private keys, encryption keys and EC2 instance credentials.

The actor also names a small bucket used for an AWS account-takeover or pivot simulation. It allegedly contains a Lambda function that creates an IAM role with the AdministratorAccess managed policy and trusts an externally supplied role ARN. Such code may be legitimate CTF or security-testing material. Its mere presence does not prove malicious capability in a live environment; risk would depend on associated permissions, active trust relationships and whether the artifact contains deployable configuration or credentials.

Independent security research identified CanisterWorm in March 2026 as a self-propagating npm supply-chain worm associated with TeamPCP. Aikido reported detecting the worm on March 20, 2026 and named it for its use of an Internet Computer Protocol canister as a command-and-control dead drop. StepSecurity and other researchers described the campaign as following the compromise of Trivy and spreading through compromised npm maintainer credentials.

Palo Alto Networks Unit 42 separately documented TeamPCP campaigns that targeted software supply chains and extracted cloud access tokens, SSH keys and Kubernetes secrets. This is relevant because the categories described in the RapidFort listing are consistent with the credential-harvesting objectives reported for the group.

• A compromised developer or CI/CD environment executes malicious package code.
• The malware harvests npm, GitHub, cloud, SSH or Kubernetes credentials from the environment.
• Stolen credentials provide access to repositories, registries, cloud storage or clusters.
• The actor collects data across development, test and production stores.
• The material is catalogued and offered for sale, while selected technical details are published as proof.

This sequence is a threat-model scenario derived from public reporting on TeamPCP and the structure of the post. CyberMon has no evidence that this exact sequence occurred at RapidFort.

• Request confirmation of whether any S3 bucket, CI/CD platform, Kubernetes cluster, vulnerability-data pipeline, scanner database or billing export was accessed without authorisation.
• Ask whether customer-specific account IDs, role ARNs, external IDs, CloudFormation parameters or deployment configurations were present.
• Request the timeline for detection, containment, credential rotation, forensic investigation and customer notification.
• Ask whether RapidFort has validated the integrity of post, scanner outputs and vulnerability-database updates.

• Inventory all IAM roles, service principals, API keys, registry credentials and network allowlists associated with RapidFort.
• Review cross-account trust policies and enforce external IDs, narrow actions, resource scoping and session restrictions.
• Disable or remove vendor access that is no longer required.
• Rotate credentials or secrets that were shared with or stored in vendor-managed systems.

• Search CloudTrail and Azure activity logs for unusual role assumption, bulk object access, access-key use, snapshot operations or data transfer.
• Review Kubernetes audit logs for anomalous secret reads, service-account token activity, pod creation, exec operations or privilege changes.
• Review GitLab, Jenkins, registry and CI/CD logs for unexpected clone, build, token-use or artifact-publication events.
• Validate software artifacts and container images against known-good provenance and hashes.

• Warn security and engineering teams about phishing using vendor, project, cloud-account or billing context.
• Monitor for leaked role ARNs, account IDs, project names, IP addresses and customer tags.
• Treat emails requesting credential resets, access changes or emergency vendor actions as high risk and verify out of band.

• Threat-actor posts naming a vendor together with S3, Kubernetes, GitLab, Jenkins, Terraform, CloudFormation or vulnerability-database terminology.
• Listings that provide bucket manifests, environment labels, file counts and descriptions instead of only a headline claim.
• Claims involving cross-account IAM roles, customer onboarding templates, external IDs or vendor scanning permissions.
• Mentions of kubeconfig files, cloud keys, private keys, registry credentials, database backups or CI/CD secrets.
• References to public-sector or defence delivery configurations.
• New posts by actors linked to known supply-chain campaigns, particularly when the listed data types match previously reported credential-harvesting behaviour.

CyberMon DRI continuously monitors underground communities, leak markets, ransomware and extortion channels, credential exposure, public code sources and threat-actor chatter for company names, domains, subsidiaries, executives, projects, vendors and cloud indicators. In a case such as this, the objective is not to repeat an actor's claims. It is to discover the signal early, preserve the evidence, assess credibility, identify potentially affected assets, and give security teams enough time to begin vendor assurance and credential containment.

The alleged RapidFort dataset has not been independently verified and should not be described as an officially confirmed breach. However, the post deserves attention because it presents a detailed and internally structured account of cloud, DevOps, scanner, vulnerability-intelligence and customer-onboarding data. The most important risk is not the headline figure of 569GB. It is the possible intersection of active secrets, software delivery systems, customer trust relationships and security-product data.

For organisations that rely on RapidFort or similar software supply-chain security vendors, the prudent response is measured validation: seek written assurance, review vendor access, rotate shared credentials where appropriate, hunt for anomalous activity and monitor for secondary exposure. The broader lesson is that security tools and their development pipelines are high-value supply-chain targets. Third-party risk programmes must therefore include external intelligence about stolen code, credentials, cloud configurations and vendor-managed access.