CVE-2022-31105
📋 TL;DR
Argo CD versions 0.4.0 through 2.4.4 (excluding patched versions) have improper certificate validation for OpenID Connect providers, allowing attackers to impersonate legitimate OIDC providers. This affects all Argo CD deployments using external OIDC authentication. Attackers could trick Argo CD into accepting malicious tokens, potentially compromising Kubernetes cluster access.
💻 Affected Systems
- Argo CD
📦 What is this software?
Argo Cd by Argoproj
Argo Cd by Argoproj
Argo Cd by Linuxfoundation
⚠️ Risk & Real-World Impact
Worst Case
Complete cluster compromise via authentication bypass, allowing attackers to deploy malicious workloads, exfiltrate sensitive data, or disrupt operations.
Likely Case
Unauthorized access to Argo CD management interface, enabling privilege escalation and potential lateral movement within the Kubernetes environment.
If Mitigated
Limited impact with proper network segmentation and monitoring; attackers would need to intercept or spoof OIDC provider traffic.
🎯 Exploit Status
Exploitation requires man-in-the-middle position or ability to spoof OIDC provider, plus knowledge of target's OIDC configuration.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 2.2.11, 2.3.6, or 2.4.5
Vendor Advisory: https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5
Restart Required: Yes
Instructions:
1. Backup your Argo CD configuration. 2. Upgrade to patched version using your deployment method (Helm, kubectl, etc.). 3. Verify the upgrade completed successfully. 4. Test authentication flows.
🔧 Temporary Workarounds
Configure OIDC Root CA
allSet oidc.config.rootCA field in argocd-cm ConfigMap to force certificate validation during login flows (partial mitigation).
kubectl edit configmap argocd-cm -n argocd
Add or update: oidc.config.rootCA: |
-----BEGIN CERTIFICATE-----
[Your OIDC provider's root CA certificate]
-----END CERTIFICATE-----
🧯 If You Can't Patch
- Implement network controls to prevent traffic interception between Argo CD and OIDC provider
- Monitor authentication logs for suspicious OIDC provider changes or unexpected authentication attempts
🔍 How to Verify
Check if Vulnerable:
Check Argo CD version: kubectl get deployment argocd-server -n argocd -o jsonpath='{.spec.template.spec.containers[0].image}'. If version is between 0.4.0 and 2.4.4 (excluding patched versions), you are vulnerable.Check Version:
kubectl get deployment argocd-server -n argocd -o jsonpath='{.spec.template.spec.containers[0].image}'Verify Fix Applied:
Verify version is 2.2.11, 2.3.6, or 2.4.5 using same command, then test OIDC authentication with invalid certificates to ensure they are rejected.📡 Detection & Monitoring
Log Indicators:
- Unexpected OIDC provider certificate changes
- Authentication failures followed by successes from new IPs
- OIDC configuration modifications in argocd-cm
Network Indicators:
- Unusual traffic patterns between Argo CD and OIDC provider
- SSL/TLS certificate mismatches in network logs
SIEM Query:
source="argo-cd" AND ("oidc" OR "authentication") AND ("certificate" OR "validation" OR "failed")🔗 References
- https://github.com/argoproj/argo-cd/releases/tag/v2.3.6
- https://github.com/argoproj/argo-cd/releases/tag/v2.4.5
- https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5
- https://github.com/argoproj/argo-cd/releases/tag/v2.3.6
- https://github.com/argoproj/argo-cd/releases/tag/v2.4.5
- https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5
