RustFS: When 'Safe' Languages Leak Like a Sieve

We love Rust. It saves us from double-frees, dangling pointers, and the nightmares of C++ memory management. But here's the kicker: the compiler can prevent you from writing to unallocated memory, but it can't prevent you from writing your secrets to stdout. That is exactly what happened with RustFS.

RustFS is designed to be a high-performance, S3-compatible object storage layer. It's the kind of thing you deploy when you want to handle petabytes of data without the overhead of the JVM. It handles authentication, data replication, and distribution. It holds the keys to the kingdom—literally.

CVE-2026-24762 isn't a complex buffer overflow or a race condition that requires nanosecond precision. It is the digital equivalent of a bank manager shouting the vault combination across the lobby every time they open it. For nearly 70 versions (alpha.13 to alpha.81), RustFS decided that Access Keys, Secret Keys, and Session Tokens were just mundane strings worthy of the INFO log level.

The root cause here is a classic developer convenience feature turning into a security liability. In Rust, we frequently use #[derive(Debug)] on structs to automatically generate code that can format the struct for output. It's fantastic for development. You want to see what's in your User object? Just println!("{:?}", user).

However, when you apply this indiscriminately to structs containing sensitive data, Debug does exactly what you asked it to do: it prints everything. The developers likely had a struct handling S3 credentials and, innocently enough, derived Debug on it. Then, somewhere in the authentication flow, they added a logging statement like info!("Authenticating request: {:?}", credentials).

The result? Every time a client authenticated, their full credentials were serialized into the application logs. Since this was done at INFO level—which is the default in almost every production environment—these secrets weren't just staying on the machine. They were being shipped to Datadog, Splunk, ELK, and CloudWatch, effectively creating a searchable database of valid API keys.

Let's look at a reconstruction of the offending pattern. This is a common anti-pattern in Rust web services.

The Vulnerable Code (Simplification):

// The struct holds critical secrets
#[derive(Debug, Clone)] // <--- The culprit
pub struct S3Credentials {
    pub access_key: String,
    pub secret_key: String,
    pub session_token: Option<String>,
}
 
fn authenticate(creds: &S3Credentials) {
    // This looks helpful for debugging connection issues...
    // But it dumps the secret_key in plaintext to logs.
    log::info!("Processing auth for: {:?}", creds);
    
    // ... processing logic
}

When this runs, your logs fill up with: [INFO] Processing auth for: S3Credentials { access_key: "AKIA...", secret_key: "wJalr...", session_token: None }

The Fix (Proper Trait Implementation):

To fix this, you must manually implement Debug (or Display) to redact sensitive fields, rather than deriving it automatically.

impl fmt::Debug for S3Credentials {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.debug_struct("S3Credentials")
         .field("access_key", &self.access_key)
         .field("secret_key", &"[REDACTED]") // <--- Safe now
         .field("session_token", &"[REDACTED]")
         .finish()
    }
}

This change ensures that even if a developer blindly logs the struct, the output remains safe.

Exploiting this requires zero technical sophistication regarding the RustFS binary itself. You don't need a debugger, you don't need shellcode, and you don't need to bypass ASLR. You just need access to the logs. This is often easier than gaining root access to the server itself. Log aggregators are frequently shared across teams with overly permissive read access.

Attack Scenario:

1. Recon: Attacker gains read-only access to the company's ELK stack or compromises a developer laptop that has production log dumps.
2. Search: The attacker runs a simple query:

   grep -r "secret_key" /var/log/rustfs/
   # OR in Kibana:
   service:rustfs AND message:"secret_key"

3. Extraction: The logs return valid JSON or Struct-formatted credentials.
4. Persistence: The attacker uses the extracted S3 keys to upload a malicious object to the storage, or simply exfiltrate sensitive backups stored in the buckets.

The beauty (and horror) of this exploit is that it works historically. If you rotate the logs but not the keys, the attacker can mine data from six months ago and still likely find valid credentials.

The impact here is Complete Compromise of Data Confidentiality and Integrity. In object storage systems, the Access/Secret key pair is the ultimate authority.

With these keys, an attacker can:

1. Exfiltrate Data: Download proprietary datasets, customer PII, or backups.
2. Destroy Data: Issue DeleteObject or DeleteBucket commands. Ransomware gangs love this—exfiltrate the data, delete the originals, demand payment.
3. Lateral Movement: If these S3 keys are actually AWS IAM keys (passthrough authentication), the attacker might be able to pivot from the storage layer into your EC2 infrastructure or Lambda functions.

Since INFO logs are voluminous, they are often retained for weeks or months. This vulnerability creates a massive window of exposure where every single successful authentication event was recorded.

Patching the software is only step one. Upgrading to RustFS alpha.82 stops the bleeding—it stops new logs from containing secrets. However, it does nothing about the gigabytes of text files already sitting on your disk or in your cloud logging provider.

Your Remediation Checklist:

1. Upgrade: Move to version alpha.82 immediately.
2. Scrub: You must purge existing logs. sed -i 's/secret_key: ".*"/secret_key: "[REDACTED]"/g' /var/log/rustfs.log. Do this on your log servers, backups, and SIEM.
3. ROTATE KEYS: This is non-negotiable. Assume every key used in the last N months (where N is your log retention period) is compromised. Issue new Access Keys and revoke the old ones.
4. Audit: Check your access logs for unusual IP addresses or user agents accessing your buckets using the compromised keys.