Hijacking Abandoned S3 Buckets for Massive Supply Chain Compromise

TLDR: Researchers have identified a critical supply chain vulnerability where thousands of abandoned AWS S3 buckets are being reclaimed by attackers to serve malicious payloads. By scanning public repositories and documentation for references to these defunct buckets, attackers can easily take over the namespace and deliver backdoored software or execute arbitrary code. This technique requires zero budget and provides a high-impact entry point into the infrastructure of major global organizations.

Supply chain security is often framed as a problem of complex dependency trees or compromised CI/CD pipelines, but sometimes the most dangerous vulnerabilities are the simplest ones. The recent research presented at DEF CON 2025 on abandoned S3 buckets proves that we are still leaving the back door wide open by failing to clean up our cloud infrastructure. When a company migrates its assets or shuts down a project, it often leaves behind hardcoded references to S3 buckets in public GitHub repositories, documentation, and build scripts. If that bucket is deleted, the namespace becomes available for anyone to claim.

The Mechanics of the Hijack

The attack flow is straightforward. An attacker uses a tool like SourceGraph to crawl public code for references to s3.amazonaws.com or specific bucket patterns. Once a target bucket is identified as non-existent, the attacker simply creates a new bucket with that exact name in the same region. Because the original software or script is still configured to pull from that URL, it will now fetch whatever the attacker chooses to host.

This is not just about hosting a static file. The research demonstrates that this technique enables Arbitrary Code Execution in several ways. For example, if a script uses curl to fetch a shell script and pipes it directly into bash, the attacker gains immediate execution on the victim's machine. In more sophisticated scenarios, attackers can poison PyTorch models by exploiting Pickle deserialization, which is a classic vector for achieving code execution when a model is loaded.

Automating the Triage

Manually verifying thousands of buckets is a waste of time. The researchers developed an LLM-based agent to automate the triage process. By enabling S3 server access logs for the reclaimed buckets, they could observe the incoming traffic and use an LLM to classify the requests. The agent analyzes the User-Agent, the requested object, and the Referer header to determine if the traffic is benign, a bot, or a potential target for exploitation.

This approach is highly effective for filtering out the noise of automated scanners. During the research, they observed millions of requests, but the LLM agent successfully narrowed these down to a few hundred buckets that were receiving sensitive, actionable traffic. This methodology is a massive time-saver for any researcher looking to map the scope of a supply chain exposure.

Real-World Impact and Pentesters

During a penetration test or a bug bounty engagement, this should be one of the first things you check. If you find a hardcoded S3 URL in a client's public-facing code, verify if the bucket exists. If it returns a 404, you have found a potential Broken Access Control issue that could lead to a full system compromise.

The impact is not limited to small projects. The research identified that this technique could have compromised Fortune 500 companies, major banks, and even government networks. When an attacker can inject code into a trusted update mechanism, they bypass traditional perimeter defenses entirely. The trust relationship is already established; the victim's machine is explicitly configured to trust the content coming from that S3 bucket.

Defensive Strategies

Fixing this requires a shift in how we manage cloud lifecycle. First, organizations must implement automated scanning to identify hardcoded references to cloud resources in their source code. If a bucket is no longer needed, it should be decommissioned, but the name should be reserved or the code referencing it must be purged before the bucket is deleted.

Cloud providers have a role here as well. AWS has introduced higher caps on bucket counts, which might inadvertently discourage the deletion of old buckets, but the real solution is to make bucket names project-scoped or non-recyclable. Until that happens, the responsibility falls on the security team to treat cloud infrastructure as code that needs to be audited just as strictly as the application logic itself.

If you are currently running an engagement, stop looking for complex zero-days for a moment and start looking for the low-hanging fruit of abandoned infrastructure. The most effective attacks are often the ones that rely on the target's own forgotten configurations. Check your own repositories today, and if you find a reference to a bucket you no longer own, assume that someone else already does.