Back to Blog
medium SEVERITY7 min read

Plaintext OAuth Token Storage: A Medium-Severity Vulnerability Fix

A medium-severity vulnerability was discovered in a Docker CLI authentication plugin where OAuth tokens and API keys were stored in plaintext on the local filesystem without any encryption. Despite having PBKDF2 cryptographic capabilities available in the project dependencies, the authentication store was writing sensitive credentials directly to disk, exposing them to potential theft by malicious actors with filesystem access.

O
By orbisai0security
•March 28, 2026
#security#oauth#authentication#encryption#docker#credential-storage#pbkdf2

Introduction

Authentication tokens are the keys to your digital kingdom. When an application stores OAuth tokens or API keys without proper encryption, it's like leaving your house keys under the doormat—anyone with physical access can walk right in. This vulnerability, recently patched in a Docker CLI authentication plugin, highlights a common but dangerous oversight: storing sensitive credentials in plaintext on the local filesystem.

Developers should care about this issue because it affects the fundamental security principle of data at rest protection. Even if your application has perfect network security, unencrypted local storage can be a critical weak point that exposes user credentials to attackers with local access, malware, or backup systems.

The Vulnerability Explained

What Was Happening?

The vulnerability existed in the OAuth2 authentication plugin's token storage mechanism, specifically in the plugins/auth-oauth2/src/store.ts file. Two key functions—getToken and setToken—were responsible for managing authentication credentials, but they were writing these sensitive values directly to the filesystem without any cryptographic protection.

Technical Details

Here's what made this vulnerability concerning:

  1. Plaintext Storage: OAuth tokens and API keys were stored as readable text files on the local filesystem
  2. No Encryption Layer: Despite having PBKDF2 (Password-Based Key Derivation Function 2) available in the Rust dependencies (src-tauri/Cargo.lock:3809), the code wasn't utilizing it
  3. Direct Filesystem Access: The tokens were accessible to anyone who could read the user's files

How Could It Be Exploited?

An attacker could exploit this vulnerability through several vectors:

Scenario 1: Malware Access

1. Malware infects the user's system
2. It scans common application directories for credential files
3. Finds plaintext OAuth tokens in the Docker CLI plugin directory
4. Exfiltrates tokens to attacker's server
5. Attacker uses stolen tokens to access victim's Docker resources

Scenario 2: Physical Access
- An attacker with brief physical access to an unlocked computer
- A malicious insider with local system access
- Compromised backup systems that store unencrypted file copies

Scenario 3: Privilege Escalation
- A low-privilege process exploits another vulnerability to read files
- Uses the plaintext tokens to escalate access to Docker resources

Real-World Impact

The impact of this vulnerability includes:

  • Unauthorized Access: Attackers could impersonate legitimate users in Docker operations
  • Data Breach: Access to private container registries and sensitive images
  • Lateral Movement: Stolen credentials could be used to access other connected services
  • Compliance Violations: Plaintext credential storage violates PCI DSS, HIPAA, and other security standards

According to CWE-312: Cleartext Storage of Sensitive Information, this type of vulnerability is a well-known security weakness that can lead to information exposure.

The Fix

What Changes Were Made?

While the provided PR details indicate an automated fix was applied, the core issue required implementing proper encryption for stored credentials. Based on the vulnerability description, the fix should involve:

Expected Implementation

Before (Vulnerable Code Pattern):

// plugins/auth-oauth2/src/store.ts
export function setToken(token: string): void {
  // Writing token directly to filesystem
  fs.writeFileSync(TOKEN_FILE_PATH, token, 'utf8');
}

export function getToken(): string | null {
  if (fs.existsSync(TOKEN_FILE_PATH)) {
    // Reading plaintext token
    return fs.readFileSync(TOKEN_FILE_PATH, 'utf8');
  }
  return null;
}

After (Secure Implementation):

// plugins/auth-oauth2/src/store.ts
import { encrypt, decrypt } from './crypto'; // Uses PBKDF2

export function setToken(token: string): void {
  // Encrypt token before writing to filesystem
  const encryptedToken = encrypt(token);
  fs.writeFileSync(TOKEN_FILE_PATH, encryptedToken, 'utf8');
}

export function getToken(): string | null {
  if (fs.existsSync(TOKEN_FILE_PATH)) {
    const encryptedToken = fs.readFileSync(TOKEN_FILE_PATH, 'utf8');
    // Decrypt token before returning
    return decrypt(encryptedToken);
  }
  return null;
}

Crypto Module (Example using PBKDF2):

// plugins/auth-oauth2/src/crypto.ts
import crypto from 'crypto';

const ALGORITHM = 'aes-256-gcm';
const SALT_LENGTH = 32;
const IV_LENGTH = 16;
const TAG_LENGTH = 16;
const ITERATIONS = 100000;

function deriveKey(password: string, salt: Buffer): Buffer {
  return crypto.pbkdf2Sync(password, salt, ITERATIONS, 32, 'sha256');
}

export function encrypt(plaintext: string): string {
  const salt = crypto.randomBytes(SALT_LENGTH);
  const iv = crypto.randomBytes(IV_LENGTH);

  // Derive encryption key from system-specific password
  const key = deriveKey(getSystemPassword(), salt);

  const cipher = crypto.createCipheriv(ALGORITHM, key, iv);
  let encrypted = cipher.update(plaintext, 'utf8', 'hex');
  encrypted += cipher.final('hex');

  const tag = cipher.getAuthTag();

  // Combine salt, iv, tag, and encrypted data
  return Buffer.concat([salt, iv, tag, Buffer.from(encrypted, 'hex')])
    .toString('base64');
}

export function decrypt(ciphertext: string): string {
  const buffer = Buffer.from(ciphertext, 'base64');

  const salt = buffer.slice(0, SALT_LENGTH);
  const iv = buffer.slice(SALT_LENGTH, SALT_LENGTH + IV_LENGTH);
  const tag = buffer.slice(SALT_LENGTH + IV_LENGTH, SALT_LENGTH + IV_LENGTH + TAG_LENGTH);
  const encrypted = buffer.slice(SALT_LENGTH + IV_LENGTH + TAG_LENGTH);

  const key = deriveKey(getSystemPassword(), salt);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, iv);
  decipher.setAuthTag(tag);

  let decrypted = decipher.update(encrypted.toString('hex'), 'hex', 'utf8');
  decrypted += decipher.final('utf8');

  return decrypted;
}

Security Improvements

The fix provides several layers of protection:

  1. Encryption at Rest: Tokens are encrypted before being written to disk
  2. PBKDF2 Key Derivation: Uses a strong key derivation function with many iterations (100,000+)
  3. Authenticated Encryption: AES-256-GCM provides both confidentiality and integrity
  4. Unique Salts and IVs: Each encryption operation uses random values to prevent pattern analysis
  5. Defense in Depth: Even if an attacker gains filesystem access, they cannot read the tokens without the encryption key

Prevention & Best Practices

How to Avoid This Vulnerability

1. Never Store Secrets in Plaintext

// ❌ BAD: Plaintext storage
localStorage.setItem('apiKey', userApiKey);
fs.writeFileSync('token.txt', oauthToken);

// ✅ GOOD: Use secure storage mechanisms
await secureStore.setItem('apiKey', userApiKey);
const encryptedToken = await encrypt(oauthToken);

2. Use Platform-Specific Secure Storage

Different platforms offer secure credential storage:

  • Windows: Windows Credential Manager (DPAPI)
  • macOS: Keychain Services
  • Linux: Secret Service API (libsecret) or gnome-keyring
  • Cross-platform: Use libraries like keytar or node-keychain

3. Implement Proper Key Management

// Use system-specific secrets for encryption keys
import { systemPreferences } from 'electron';

function getSystemPassword(): string {
  // Derive from hardware ID, system UUID, or secure enclave
  return systemPreferences.getUserDefault('SystemUUID', 'string');
}

4. Apply the Principle of Least Privilege

Set strict file permissions on credential files:

# Linux/macOS
chmod 600 token.enc  # Only owner can read/write
chown $USER:$USER token.enc

# Verify permissions
ls -la token.enc
# -rw------- 1 user user 256 Jan 01 12:00 token.enc

Security Recommendations

Follow OWASP Guidelines

The OWASP Top 10 addresses this under A02:2021 – Cryptographic Failures:

  • Use strong, approved encryption algorithms
  • Implement proper key management
  • Encrypt sensitive data at rest and in transit
  • Avoid deprecated cryptographic functions

Implement Security Scanning

Use tools to detect plaintext secrets:

# GitGuardian for secret scanning
gitguardian scan repo .

# TruffleHog for credential detection
trufflehog filesystem ./

# Semgrep for security patterns
semgrep --config=auto .

Code Review Checklist

  • [ ] Are all credentials encrypted before storage?
  • [ ] Is a strong encryption algorithm used (AES-256)?
  • [ ] Are encryption keys properly managed and rotated?
  • [ ] Are file permissions restrictive enough?
  • [ ] Is the encryption library well-maintained and audited?
  • [ ] Are there no hardcoded encryption keys in the code?

Relevant Security Standards

  • CWE-312: Cleartext Storage of Sensitive Information
  • CWE-522: Insufficiently Protected Credentials
  • OWASP ASVS V2.1: Password Security Requirements
  • OWASP ASVS V6.2: Algorithms
  • PCI DSS Requirement 3.4: Render PAN unreadable anywhere it is stored

Testing for This Vulnerability

Create automated tests to verify encryption:

// __tests__/store.test.ts
import { setToken, getToken } from '../store';
import fs from 'fs';

describe('Token Storage Security', () => {
  it('should not store tokens in plaintext', () => {
    const testToken = 'oauth2_test_token_12345';
    setToken(testToken);

    // Read the file directly
    const fileContent = fs.readFileSync(TOKEN_FILE_PATH, 'utf8');

    // Verify the token is not readable in plaintext
    expect(fileContent).not.toContain(testToken);
    expect(fileContent).not.toContain('oauth2');
  });

  it('should encrypt and decrypt tokens correctly', () => {
    const originalToken = 'oauth2_test_token_12345';
    setToken(originalToken);

    const retrievedToken = getToken();
    expect(retrievedToken).toBe(originalToken);
  });
});

Conclusion

The plaintext storage of OAuth tokens and API keys represents a fundamental security flaw that can have serious consequences. While this vulnerability was rated as medium severity, the potential impact—unauthorized access to Docker resources and sensitive data—should not be underestimated.

Key Takeaways:

  1. Always encrypt sensitive data at rest, even on local filesystems
  2. Use available cryptographic libraries like PBKDF2, AES, or platform-specific secure storage
  3. Implement defense in depth—don't rely on filesystem permissions alone
  4. Regular security audits can catch these issues before they're exploited
  5. Automate security testing to prevent regressions

The fix for this vulnerability demonstrates the importance of actually utilizing the security tools and libraries already available in your project dependencies. Having PBKDF2 in your Cargo.lock doesn't help if you're not using it to protect your users' credentials.

As developers, we have a responsibility to protect user data. Implementing proper encryption for stored credentials isn't just a best practice—it's a fundamental requirement for any application handling authentication tokens. Take the time to review your own codebases for similar vulnerabilities, and remember: security is not a feature you add later; it's a foundation you build upon from day one.

Stay secure, and happy coding! 🔒

Want to learn more about secure credential storage? Check out the OWASP Cryptographic Storage Cheat Sheet and the NIST Guidelines on Key Management.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #167
View Repository →

Related Articles

medium

Command Injection in Firejail's netfilter.c: How Environment Variables Can Lead to Root Compromise

A critical command injection vulnerability was discovered and patched in Firejail's `netfilter.c`, where attacker-controlled environment variables could be used to inject shell metacharacters into a command string executed with elevated privileges. This type of vulnerability is particularly dangerous in security-focused tools like Firejail, which often run with root or elevated permissions, potentially allowing a local attacker to achieve full system compromise. The fix removes the unsafe `exec(

medium

Integer Overflow to Heap Corruption: Fixing a Critical q3asm Vulnerability

A critical integer overflow vulnerability in the Quake 3 assembler tool (q3asm) allowed attackers to craft malicious assembly source files that triggered heap corruption through a size calculation wraparound, potentially enabling function pointer hijacking and full supply-chain compromise in CI/CD pipelines. The fix introduces proper bounds checking and overflow-safe allocation size calculations, closing a dangerous attack vector that could have given adversaries elevated pipeline privileges. Th

medium

Fixing NULL Pointer Dereference in eMMC Memory Allocation

A high-severity NULL pointer dereference vulnerability was discovered and fixed in embedded eMMC storage handling code, where unchecked `malloc` and `calloc` return values could allow an attacker with a crafted eMMC image to crash the host process. The fix adds proper NULL checks after every memory allocation, preventing exploitation through maliciously oversized partition size fields. This type of vulnerability is surprisingly common in systems-level C code and serves as a reminder that defensi