CVE-2024-31216

5.1 MEDIUM

📋 TL;DR

The source-controller Kubernetes operator logs Azure SAS tokens when connection errors occur with Azure Blob Storage. Attackers with access to these logs can use the exposed tokens to access Azure Blob Storage until token expiration. This affects all source-controller deployments using Azure SAS token authentication prior to version 1.2.5.

💻 Affected Systems

Products:
  • fluxcd/source-controller
Versions: All versions prior to 1.2.5
Operating Systems: All platforms running Kubernetes
Default Config Vulnerable: ✅ No
Notes: Only affects deployments configured to use Azure SAS token authentication with Azure Blob Storage. Other authentication methods or storage backends are not vulnerable.

⚠️ Manual Verification Required

This CVE does not have specific version information in our database, so automatic vulnerability detection cannot determine if your system is affected.

Why? The CVE database entry doesn't specify which versions are vulnerable (no version ranges provided by the vendor/NVD).

🔒 Custom verification scripts are available for registered users. Sign up free to download automated test scripts.

Recommended Actions:
  1. Review the CVE details at NVD
  2. Check vendor security advisories for your specific version
  3. Test if the vulnerability is exploitable in your environment
  4. Consider updating to the latest version as a precaution

⚠️ Risk & Real-World Impact

🔴

Worst Case

Full compromise of Azure Blob Storage data accessible by the SAS token, potentially including sensitive source code, configuration files, or artifacts stored in the affected storage accounts.

🟠

Likely Case

Unauthorized access to specific Azure Blob Storage containers or objects that the exposed SAS token permits, leading to data exposure or modification.

🟢

If Mitigated

Limited impact if logs are properly secured with restricted access, but token exposure still creates a credential leak that could be exploited.

🌐 Internet-Facing: LOW - The vulnerability requires access to controller logs, which are typically internal.
🏢 Internal Only: MEDIUM - Internal attackers or compromised internal accounts with log access could exploit this to escalate privileges to Azure storage.

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ✅ No
Complexity: LOW

Exploitation requires access to source-controller logs where connection errors occurred. The token is directly visible in plaintext logs when present.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: 1.2.5

Vendor Advisory: https://github.com/fluxcd/source-controller/security/advisories/GHSA-v554-xwgw-hc3w

Restart Required: Yes

Instructions:

1. Update source-controller deployment to version 1.2.5 or later. 2. For Helm: 'helm upgrade source-controller fluxcd/source-controller --version >=1.2.5'. 3. For direct manifests: update image tag to 'ghcr.io/fluxcd/source-controller:v1.2.5' or later. 4. Restart the controller pod.

🔧 Temporary Workarounds

Switch to Azure Workload Identity

all

Replace Azure SAS token authentication with Azure Workload Identity, which doesn't expose credentials in logs.

# Configure Azure Workload Identity following Microsoft documentation
# Update source-controller configuration to use workload identity

🧯 If You Can't Patch

  • Restrict access to source-controller logs using Kubernetes RBAC and log storage access controls.
  • Rotate all Azure SAS tokens used by source-controller and implement shorter token expiration times.

🔍 How to Verify

Check if Vulnerable:

Check source-controller version: 'kubectl get deployment source-controller -n flux-system -o jsonpath="{.spec.template.spec.containers[0].image}"'. If version is earlier than 1.2.5 and Azure SAS token authentication is configured, the system is vulnerable.

Check Version:

kubectl get deployment source-controller -n flux-system -o jsonpath="{.spec.template.spec.containers[0].image}" | grep -o 'v[0-9.]*'

Verify Fix Applied:

Confirm source-controller is running version 1.2.5 or later: 'kubectl get pods -n flux-system -l app=source-controller -o jsonpath="{.items[0].spec.containers[0].image}"'. Check logs for connection errors to verify tokens are no longer exposed.

📡 Detection & Monitoring

Log Indicators:

  • Azure SAS tokens appearing in source-controller logs, particularly in connection error messages
  • Patterns matching Azure storage URLs with 'sig=' parameters in logs

Network Indicators:

  • Unexpected Azure Blob Storage access from non-source-controller IPs using exposed tokens

SIEM Query:

source-controller_logs AND ("sig=" OR "SharedAccessSignature" OR "connection error" AND "azure")

🔗 References

📤 Share & Export