Hijacking Abandoned S3 Buckets for Global Supply Chain Compromise

TLDR: Researchers at DEF CON 2025 demonstrated a high-impact supply chain attack by identifying and reclaiming thousands of abandoned AWS S3 buckets referenced in public source code and package repositories. By registering these expired bucket names, attackers can intercept traffic, deliver malicious payloads, or execute arbitrary code on victim machines. This research proves that simple misconfigurations in build pipelines and dependency management create massive, low-cost attack surfaces that remain largely unmonitored.

Supply chain security is usually discussed in the context of complex CI/CD pipeline compromises or sophisticated nation-state actors injecting backdoors into build servers. While those threats are real, the research presented at DEF CON 2025 by Maksim Shudrak exposes a much more mundane, yet devastatingly effective, attack vector: the abandoned cloud bucket. When a company stops using an S3 bucket but leaves references to it in their public code, documentation, or build scripts, they leave a door wide open for anyone willing to register that bucket name.

The Mechanics of the Bucket Hijack

The attack flow is deceptively simple. Many developers and automated build systems use hardcoded URLs to pull dependencies, binaries, or configuration files from S3. If a project is archived, a company pivots its infrastructure, or a developer simply forgets to clean up their code, those S3 bucket names become "orphaned."

Because AWS bucket names exist in a global namespace, if a bucket is deleted, the name becomes available for anyone else to claim. The researcher used SourceGraph to crawl millions of public repositories, searching for references to s3.amazonaws.com and specific bucket patterns. Once a bucket is identified as non-existent, the attacker simply creates a new bucket with that exact name in the same region.

From that point on, any automated script, developer machine, or production server that attempts to pull a file from that URL will instead hit the attacker-controlled bucket. The impact ranges from simple data exfiltration—where the attacker logs the incoming requests to see what the victim is trying to pull—to full remote code execution (RCE).

From Traffic Interception to RCE

The most dangerous aspect of this technique is the ease of achieving code execution. During the live demonstration, the researcher showed how a hijacked bucket could be used to serve a malicious binary or a poisoned configuration file.

For instance, if a Vagrantfile or a deployment script uses a curl command to fetch a setup script from an S3 bucket, the attacker can replace that script with a malicious payload. The victim’s machine, trusting the source, executes the code with the privileges of the user running the script.

The researcher also demonstrated a more subtle attack using PyTorch models. PyTorch uses Pickle for model serialization. Because Pickle is inherently insecure, loading a model from a hijacked bucket allows for arbitrary code execution during the deserialization process. A simple payload like this is enough to trigger the exploit:

import os
import torch

# Malicious payload injected into a PyTorch model file
class MaliciousModel:
    def __reduce__(self):
        return (os.system, ('gnome-calculator',))

# When the victim loads the model, the calculator pops
model = torch.load('poisoned_model.pth')

This is a classic example of OWASP A03:2021-Injection, where the application fails to validate the integrity of the data it is loading.

Real-World Pentesters and Bug Bounties

For those of us in the field, this is a goldmine for reconnaissance. During a penetration test, don't just look for open buckets. Look for dead buckets. If you find a reference to an S3 bucket in a client's public repository that returns a 404, you have found a potential entry point.

The scale of this issue is staggering. The research identified nearly 5,000 sensitive buckets that were actively receiving traffic. These requests were coming from Fortune 500 companies, government networks, and major tech firms. The traffic included everything from sensitive configuration files to internal build logs.

If you are hunting for bugs, start by mapping the client's dependency tree. Check their pom.xml files, package.json files, and any shell scripts used for provisioning. If you can prove that you can claim a bucket they rely on, you have a high-severity finding. It is a direct path to supply chain compromise that requires zero exploitation of the target's actual infrastructure.

Defensive Strategies

Defending against this requires a shift in how we manage cloud assets. First, organizations must implement SAST tools that scan for hardcoded cloud resource references. If a bucket is decommissioned, the code referencing it must be updated or removed immediately.

Cloud providers could also mitigate this by implementing project-scoped bucket names, where a bucket name is tied to a specific account ID or organization, preventing others from claiming it even after deletion. Until that happens, the burden is on the security team to treat cloud resource names as sensitive configuration data.

Stop assuming that your build process is secure just because it uses "official" cloud infrastructure. If you are pulling code or binaries from a URL you don't actively own and monitor, you are essentially running unauthenticated code from the internet. Audit your dependencies, clean up your legacy code, and start monitoring your outbound traffic for requests to buckets that should no longer exist. The edge of tomorrow is here, and it is currently being served from an abandoned bucket.