A security vulnerability exists in the Sealed Secrets controller's unauthenticated POST endpoints. By submitting a…
Résumé
Faille signalée : vulnérabilité (CVE-2026-59341). Des informations confidentielles peuvent être exposées. Exploitable via POST /v1/verify.
Description d'origine
La description telle que publiée par la source (souvent en anglais).
A security vulnerability exists in the Sealed Secrets controller's unauthenticated POST endpoints. By submitting a modified payload containing custom Go template logic in spec.template.data, an attacker with internal network access can abuse the handler as a decryption oracle to recover the full plaintext of any sealed secret.
The POST /v1/verify and /v1/rotate handlers call Unseal() to decrypt target secrets, then render any Go templates found in spec.template.data.* using the decrypted payload as the evaluation context (pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go). Errors encountered during template execution are directly reflected in the resulting HTTP response status codes.
Missing AEAD label binding: the spec.template.data field is omitted from the AEAD authenticated-data label binding ciphertext to metadata. As a result, an attacker can copy a target's valid metadata and encryptedData verbatim, satisfying AEAD decryption and label validation, while freely replacing spec.template.data with arbitrary template logic.
Side-channel oracle: template execution errors map directly to HTTP response codes. HTTP 200 (OK) indicates template execution succeeded; HTTP 409 (Conflict) indicates template execution failed (e.g. via {{ fail "..." }}).
By injecting conditional statements such as {{ if eq (substr 0 1 .password) "S" }}ok{{ else }}{{ fail "x" }}{{ end }}, an attacker receives an HTTP 200 status when a character guess is correct and an HTTP 409 when it is inc…
Source: NIST National Vulnerability Database NVD
Résumé généré automatiquement
Assemblé par SecPulse à partir des données sources (CVSS, CWE, versions affectées) à l'aide de modèles, sans IA. Vérifiez la description d'origine et les références ci-dessous.
Une vulnérabilité référencée CVE-2026-59341 a été découverte.
Des attaquants peuvent cibler un point d'entrée spécifique comme POST /v1/verify à distance pour détourner le produit.
Des informations confidentielles peuvent être exposées. Score CVSS : 4.2/10.
Action : appliquez le correctif officiel de l'éditeur.
En cas de doute, contactez votre service informatique ou cherchez « CVE-2026-59341 » sur le site de l'éditeur.
CVE-2026-59341 — CWE-203 / CVSS v3 4.2
Vecteur d'attaque : distant (réseau)
Surface d'attaque : POST /v1/verify
Plan : 1) Audit SBOM, 2) Mise à jour staging→prod, 3) Surveillance WAF/proxy sur les endpoints affectés, 4) Recherche d'IOC dans les logs.
Réfs : voir GHSA / avis éditeur / version corrigée liés sur cette page.
Une vulnérabilité (CWE-203) a été signalée. Les attaquants atteignent le code vulnérable via POST /v1/verify.
Consultez l'avis de l'éditeur pour les versions affectées. Surface d'attaque : POST /v1/verify.
Gravité : Moyenne (CVSS 4.2/10). Des informations confidentielles peuvent être exposées.
Mettre à jour vers la version corrigée selon l'avis éditeur.
En attendant le correctif : désactivez la fonctionnalité concernée, appliquez des règles WAF, ou restreignez l'accès par ACL réseau.
Recherchez dans les logs webserver/proxy/WAF des requêtes anormales vers POST /v1/verify (en-têtes d'auth malformés, méta-caractères SQL).
Actions de réponse
Étapes concrètes et exemples de commandes que les équipes SOC/SRE doivent exécuter dans l'ordre
-
1Identify exposure identify
Audit SBOM/dependencies for affected components.資産台帳・SBOM・依存マニフェストで影響コンポーネントを特定する。
-
2Hunt for indicators of compromise detect
grep 'POST /v1/verify' /var/log/nginx/access.log | grep -E '(unusual_payload|sqli_pattern)'アクセスログで
POST /v1/verifyへの異常なリクエスト (不正な認証ヘッダ・SQLメタ文字)を過去 30〜90日分捜索。WAF/SIEM があれば該当パスのアラート発火履歴を確認。 -
3Post-deployment verification verify
Replay attack against POST /v1/verify on staging to confirm patch closes the vectorパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番では Step 2 と同じログクエリでアラート再発が無いか継続監視。
Références
- web security@vmware.com
- web github.com