Terraform & IaC Security in 2026: CVE-2025-13357 (Vault Auth Bypass), tfstate Secrets & Checkov/Trivy Hardening GuideSécurité Terraform & IaC en 2026 : CVE-2025-13357 (Bypass Auth Vault), Secrets tfstate & Guide Durcissement Checkov/Trivy

Infrastructure as Code turned a week-long provisioning process into a 10-minute terraform apply. It also turned every misconfigured default, every hardcoded credential, and every leaked state file into a repeatable, version-controlled blast radius. In 2026, cloud vulnerabilities contributed to 43% of all data breaches globally — and Terraform is at the center of most of those stories.

L’Infrastructure as Code a transformé un provisionnement d’une semaine en un terraform apply de 10 minutes. Il a également transformé chaque défaut mal configuré, chaque credential codé en dur et chaque state file fuité en un rayon d’explosion versionné et reproductible. En 2026, les vulnérabilités cloud contribuent à 43% de toutes les violations de données dans le monde — et Terraform est au cœur de la plupart de ces histoires.

This guide covers the most impactful Terraform security issue of 2025–2026 — CVE-2025-13357, a critical authentication bypass in the HashiCorp Vault Terraform Provider — alongside the structural problem that no CVE number captures: the tfstate file that silently persists every secret your infrastructure ever touched. We compare the three main IaC scanners (Checkov, Trivy, and the now-retired tfsec), explain how to eliminate static credentials with OIDC, and look at OpenTofu’s native state encryption as the most impactful IaC security improvement of the year.

Ce guide couvre le problème de sécurité Terraform le plus important de 2025–2026 — CVE-2025-13357, un bypass d’authentification critique dans le HashiCorp Vault Terraform Provider — ainsi que le problème structurel qu’aucun numéro CVE ne capture : le fichier tfstate qui persiste silencieusement chaque secret que votre infrastructure a jamais touché. Nous comparons les trois principaux scanners IaC (Checkov, Trivy et feu tfsec), expliquons comment éliminer les credentials statiques avec OIDC, et examinons le chiffrement natif du state d’OpenTofu comme l’amélioration de sécurité IaC la plus importante de l’année.

CVE-2025-13357: The Vault Terraform Provider Authentication Bypass

CVE-2025-13357 : Le Bypass d’Authentification du Vault Terraform Provider

CVE-2025-13357 is a high-severity vulnerability (CVSS 7.4) in the HashiCorp Vault Terraform Provider that was disclosed in late 2025. The bug is deceptively simple: the Provider set the deny_null_bind parameter for LDAP authentication to false by default. That single misconfigured boolean allows attackers to authenticate to any Vault cluster using empty passwords — as long as the underlying LDAP server permits anonymous or unauthenticated binds.

CVE-2025-13357 est une vulnérabilité de haute sévérité (CVSS 7.4) dans le HashiCorp Vault Terraform Provider divulguée fin 2025. Le bug est trompeusement simple : le Provider définissait le paramètre deny_null_bind pour l’authentification LDAP à false par défaut. Ce seul booléen mal configuré permet aux attaquants de s’authentifier sur n’importe quel cluster Vault avec des mots de passe vides — tant que le serveur LDAP sous-jacent autorise les liaisons anonymes ou non authentifiées.

The impact is amplified by IaC’s core strength — reproducibility. When a Terraform Provider sets an insecure default, that default propagates to every Vault cluster or namespace provisioned with that code. Organizations that used Terraform Provider versions v4.2.0 through v5.4.0 to configure their Vault LDAP auth backend may have silently deployed this misconfiguration across multiple environments.

L’impact est amplifié par la force centrale de l’IaC — la reproductibilité. Quand un Terraform Provider définit un défaut non sécurisé, ce défaut se propage à chaque cluster Vault ou namespace provisionné avec ce code. Les organisations ayant utilisé les versions v4.2.0 à v5.4.0 du Provider Terraform pour configurer leur backend LDAP Vault peuvent avoir silencieusement déployé cette mauvaise configuration dans plusieurs environnements.

# Vulnerable: deny_null_bind defaults to false in Provider v4.2.0–v5.4.0
resource "vault_ldap_auth_backend" "ldap" {
  path      = "ldap"
  url       = "ldaps://ldap.example.com"
  userdn    = "ou=Users,dc=example,dc=com"
  userattr  = "uid"
  # deny_null_bind not set → defaults to false → LDAP null bind allowed
}

# Fixed: upgrade to vault-provider v5.5.0 (sets deny_null_bind = true by default)
# OR explicitly set it:
resource "vault_ldap_auth_backend" "ldap" {
  path           = "ldap"
  url            = "ldaps://ldap.example.com"
  userdn         = "ou=Users,dc=example,dc=com"
  userattr       = "uid"
  deny_null_bind = true  # Explicit — always set this
}

Remediation: Upgrade the Vault Terraform Provider to v5.5.0 or later. Additionally, upgrade Vault itself to Community Edition 1.21.1 (or Enterprise 1.21.1 / 1.20.6 / 1.19.12 / 1.16.28), which adds server-side protections that reject null binds regardless of Provider configuration. Run a drift check with terraform plan after upgrading to confirm the parameter is being set correctly.

Remédiation : Mettez à niveau le Vault Terraform Provider vers v5.5.0 ou supérieur. De plus, mettez à niveau Vault lui-même vers Community Edition 1.21.1 (ou Enterprise 1.21.1 / 1.20.6 / 1.19.12 / 1.16.28), qui ajoute des protections côté serveur rejetant les null binds quelle que soit la configuration du Provider. Exécutez un drift check avec terraform plan après la mise à niveau pour confirmer que le paramètre est correctement défini.

The tfstate Problem: Why sensitive = true Does Not Protect Your Secrets

Le Problème tfstate : Pourquoi sensitive = true Ne Protège Pas Vos Secrets

The Terraform state file (terraform.tfstate) is the most dangerous artifact in any IaC pipeline. It contains the current real-world value of every resource attribute Terraform manages — including secrets — in plaintext JSON. Database passwords, TLS private keys, IAM access keys, API tokens: all written to state, regardless of how sensitive you mark them.

Le fichier d’état Terraform (terraform.tfstate) est l’artefact le plus dangereux de tout pipeline IaC. Il contient la valeur réelle actuelle de chaque attribut de ressource que Terraform gère — y compris les secrets — en JSON en clair. Mots de passe de bases de données, clés privées TLS, clés d’accès IAM, tokens API : tout est écrit dans l’état, quelle que soit la sensibilité que vous leur attribuez.

# This looks safe — but it is NOT
variable "db_password" {
  type      = string
  sensitive = true  # Only masks output in CLI — password is still in tfstate
}

resource "aws_db_instance" "main" {
  password = var.db_password  # Written to state in plaintext
}

# In terraform.tfstate:
# "password": "your_secret_password_here"  ← plaintext JSON, always

The sensitive = true flag masks the value in terraform output and terraform plan diffs. It does not prevent the value from being written to the state file. Every aws_db_instance password, tls_private_key PEM, and aws_iam_access_key secret ends up in state regardless. This means that wherever your state lives — local disk, S3, Terraform Cloud — that location is as sensitive as a password manager.

Le flag sensitive = true masque la valeur dans les diffs terraform output et terraform plan. Il n’empêche pas la valeur d’être écrite dans le fichier d’état. Chaque mot de passe aws_db_instance, PEM tls_private_key et secret aws_iam_access_key finit dans l’état de toute façon. Cela signifie que l’endroit où vit votre état — disque local, S3, Terraform Cloud — est aussi sensible qu’un gestionnaire de mots de passe.

The three most common state exposure patterns: (1) Teams store state locally and accidentally commit the .tfstate file to git — including in .gitignore misses after a repo migration. (2) Teams configure S3 backends but skip bucket encryption, versioning, or access controls. (3) State files are included in CI/CD artifact archives or build logs without sanitization.

Les trois patterns d’exposition d’état les plus courants : (1) Les équipes stockent l’état localement et commit accidentellement le fichier .tfstate dans git — y compris les oublis dans .gitignore après une migration de dépôt. (2) Les équipes configurent des backends S3 mais omettent le chiffrement du bucket, le versionnement ou les contrôles d’accès. (3) Les fichiers d’état sont inclus dans les archives d’artefacts CI/CD ou les journaux de build sans sanitisation.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-prod"
    key            = "prod/terraform.tfstate"
    region         = "eu-west-1"
    encrypt        = true          # Server-side encryption
    kms_key_id     = "arn:aws:kms:eu-west-1:123456789:key/xxxx"
    dynamodb_table = "terraform-lock"  # State locking

    # IAM policy on the bucket must:
    # - Deny s3:PutObject without x-amz-server-side-encryption
    # - Deny s3:GetObject to all principals except your CI/CD role
    # - Block public access — all four settings
  }
}

# .gitignore — add these lines
# terraform.tfstate
# terraform.tfstate.backup
# .terraform/

OpenTofu 1.7+: Native State Encryption — the Most Important IaC Security Feature of 2025

OpenTofu 1.7+ : Chiffrement Natif du State — la Plus Importante Fonctionnalité de Sécurité IaC de 2025

OpenTofu is the Linux Foundation–governed, MPL-licensed fork of Terraform, created after HashiCorp switched to the Business Source License (BSL) in August 2023. Version 1.7, released in 2024, introduced native state file encryption — a feature HashiCorp has not shipped in Terraform core. With OpenTofu’s encryption, even if your S3 bucket or remote backend is fully compromised, the state file remains unreadable without the correct decryption key.

OpenTofu est le fork de Terraform sous licence MPL géré par la Linux Foundation, créé après que HashiCorp soit passé à la Business Source License (BSL) en août 2023. La version 1.7, sortie en 2024, a introduit le chiffrement natif des fichiers d’état — une fonctionnalité que HashiCorp n’a pas encore livrée dans le core Terraform. Avec le chiffrement d’OpenTofu, même si votre bucket S3 ou votre backend distant est entièrement compromis, le fichier d’état reste illisible sans la bonne clé de déchiffrement.

# OpenTofu 1.7+ — encryption block in terraform.tf
terraform {
  encryption {
    method "aes_gcm" "my_method" {
      keys = key_provider.aws_kms.my_key
    }

    key_provider "aws_kms" "my_key" {
      kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/xxxx"
      region     = "eu-west-1"
    }

    state {
      method = method.aes_gcm.my_method
      enforced = true  # Refuse to read unencrypted state
    }

    plan {
      method = method.aes_gcm.my_method
    }
  }
}

The enforced = true flag is critical: it makes OpenTofu refuse to read any unencrypted state, preventing accidental decryption rollbacks. For teams evaluating the Terraform vs. OpenTofu decision in 2026, native state encryption is the single strongest security argument for OpenTofu. Note: CVE-2026-25499, a path traversal vulnerability in the Proxmox OpenTofu/Terraform Provider documentation (fixed in v0.93.1), shows that providers themselves remain an attack surface in both ecosystems.

Le flag enforced = true est critique : il fait refuser à OpenTofu de lire tout état non chiffré, empêchant les rollbacks de déchiffrement accidentels. Pour les équipes évaluant le choix Terraform vs. OpenTofu en 2026, le chiffrement natif du state est le seul argument de sécurité le plus fort pour OpenTofu. À noter : CVE-2026-25499, une vulnérabilité de path traversal dans la documentation du Provider Proxmox OpenTofu/Terraform (corrigée en v0.93.1), montre que les providers eux-mêmes restent une surface d’attaque dans les deux écosystèmes.

IaC Scanning in 2026: Checkov vs. Trivy vs. tfsec (and the Trivy Supply Chain Incident)

Scanning IaC en 2026 : Checkov vs. Trivy vs. tfsec (et l’Incident Supply Chain Trivy)

Three tools dominate Terraform security scanning in 2026. Understanding their differences — and their own security histories — matters as much as choosing which one to run.

Trois outils dominent le scanning de sécurité Terraform en 2026. Comprendre leurs différences — et leurs propres historiques de sécurité — est aussi important que de choisir lequel exécuter.

tfsec — Archived (February 2023)

tfsec — Archivé (février 2023)

Aqua Security merged tfsec into Trivy in 2023. The tfsec repository now redirects users to Trivy, and the project has been in maintenance-only mode since February 2023. Its last release (v1.28.14, May 2025) contained only a dependency CVE fix — no new scanning rules have been added since early 2024. If you are still running tfsec in CI/CD in 2026, you are running an unpatched, unmaintained tool. Migrate to Trivy (trivy config . runs the same checks) or Checkov.

Aqua Security a fusionné tfsec dans Trivy en 2023. Le dépôt tfsec redirige désormais les utilisateurs vers Trivy, et le projet est en mode maintenance uniquement depuis février 2023. Sa dernière release (v1.28.14, mai 2025) ne contenait qu’un correctif CVE de dépendance — aucune nouvelle règle de scan n’a été ajoutée depuis début 2024. Si vous exécutez encore tfsec dans CI/CD en 2026, vous utilisez un outil non patché et non maintenu. Migrez vers Trivy (trivy config . exécute les mêmes vérifications) ou Checkov.

Trivy — 34K+ Stars, All-in-One, but Supply Chain Compromised in March 2026

Trivy — 34K+ Stars, Tout-en-Un, mais Compromis Supply Chain en Mars 2026

Trivy (34,000+ GitHub stars) handles IaC misconfigurations, container image CVEs, application dependency scanning, secrets detection, and license compliance in a single binary. After absorbing tfsec, trivy config runs the same misconfiguration checks with a smaller policy library than Checkov. The critical caveat for 2026: Trivy’s release infrastructure was compromised in a supply chain attack in March 2026. Attackers hijacked GitHub Actions tags and published fake releases. We covered this incident in detail in our GitHub Actions Supply Chain Security guide. Always pin Trivy to a specific SHA in CI/CD, not a floating tag.

Trivy (34 000+ étoiles GitHub) gère les mauvaises configurations IaC, les CVE d’images container, le scanning de dépendances applicatives, la détection de secrets et la conformité des licences dans un seul binaire. Après absorption de tfsec, trivy config exécute les mêmes vérifications de mauvaise configuration avec une bibliothèque de politiques plus petite que Checkov. La mise en garde critique pour 2026 : l’infrastructure de release de Trivy a été compromise dans une attaque supply chain en mars 2026. Les attaquants ont détourné les tags GitHub Actions et publié de fausses releases. Nous avons couvert cet incident en détail dans notre guide Sécurité Supply Chain GitHub Actions. Pinez toujours Trivy sur un SHA spécifique dans CI/CD, jamais sur un tag flottant.

- name: Run Trivy IaC scan
  uses: aquasecurity/trivy-action@b2a49f93a7a8abf0a9b88f5b45f90efbe85ae0c8
  # ^ SHA-pinned, not @main or @v0.x.x
  with:
    scan-type: config
    scan-ref: .
    severity: HIGH,CRITICAL
    exit-code: 1

Checkov — 750+ Policies, Graph Checks, and OpenTofu Support

Checkov — 750+ Politiques, Graph Checks et Support OpenTofu

Checkov (by Bridgecrew/Palo Alto Networks) ships with over 750 built-in policies, expanded to 1,000+ with graph-based cross-resource checks that verify relationships between resources. Unlike Trivy, Checkov can verify that an EC2 instance connects to a network interface in a VPC-attached subnet — catching misconfigurations that attribute-level checks miss entirely. Checkov also supports frameworks that Trivy does not: OpenTofu, Kustomize, Bicep, AWS CDK, and the Serverless Framework. It maps results to CIS, SOC 2, HIPAA, and PCI DSS compliance frameworks. The tradeoff: Checkov is IaC-only; it does not scan container images or application dependencies.

Checkov (par Bridgecrew/Palo Alto Networks) est livré avec plus de 750 politiques intégrées, étendues à 1 000+ avec des vérifications cross-ressources basées sur des graphes vérifiant les relations entre ressources. Contrairement à Trivy, Checkov peut vérifier qu’une instance EC2 se connecte à une interface réseau dans un sous-réseau attaché à un VPC — détectant des mauvaises configurations que les vérifications au niveau des attributs manquent entièrement. Checkov supporte également des frameworks que Trivy ne prend pas en charge : OpenTofu, Kustomize, Bicep, AWS CDK et le Serverless Framework. Il mappe les résultats aux frameworks de conformité CIS, SOC 2, HIPAA et PCI DSS. La contrepartie : Checkov est réservé à l’IaC ; il ne scanne pas les images container ni les dépendances applicatives.

# Install
pip install checkov

# Scan a Terraform directory
checkov -d ./infrastructure --framework terraform

# Specific checks only (CIS Terraform AWS benchmark)
checkov -d . --framework terraform --check CKV_AWS_*

# In CI/CD — fail on HIGH and CRITICAL
checkov -d . --soft-fail-on LOW,MEDIUM --compact --output cli --output junitxml --output-file-path checkov-results.xml

# OpenTofu support (same command)
checkov -d . --framework terraform

OIDC Authentication for Terraform CI/CD: Eliminating Static Cloud Credentials

Authentification OIDC pour Terraform CI/CD : Éliminer les Credentials Cloud Statiques

The most common Terraform security anti-pattern in CI/CD is storing long-lived cloud credentials (AWS access keys, GCP service account JSON, Azure client secrets) as CI/CD secrets and passing them as environment variables. These static credentials can sit unrotated for months, leak through log files, and survive after an engineer leaves. OIDC eliminates them entirely.

L’anti-pattern de sécurité Terraform le plus courant dans CI/CD est de stocker des credentials cloud long-lived (clés d’accès AWS, JSON de compte de service GCP, secrets client Azure) en tant que secrets CI/CD et de les passer comme variables d’environnement. Ces credentials statiques peuvent rester non rotatés pendant des mois, fuir via des fichiers de log et survivre après le départ d’un ingénieur. OIDC les élimine entièrement.

With OIDC, GitHub Actions (or any CI/CD system) requests short-lived, scoped credentials from your cloud provider on every run. The credentials expire after the workflow completes — there are no static secrets to rotate, leak, or forget about. AWS, GCP, and Azure all support Terraform OIDC authentication.

Avec OIDC, GitHub Actions (ou tout système CI/CD) demande des credentials à durée limitée et sco-pés à votre fournisseur cloud à chaque exécution. Les credentials expirent après la fin du workflow — il n’y a pas de secrets statiques à faire tourner, à faire fuir ou à oublier. AWS, GCP et Azure supportent tous l’authentification OIDC Terraform.

name: Terraform Plan & Apply

on:
  push:
    branches: [main]

permissions:
  id-token: write   # Required for OIDC
  contents: read

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/GitHubActionsRole
          aws-region: eu-west-1
          # No AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY needed

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Plan
        run: terraform plan -no-color

The AWS IAM role must trust the GitHub OIDC provider and restrict the trust condition to your specific repository and branch (token.actions.githubusercontent.com:sub: repo:your-org/your-repo:ref:refs/heads/main). Without this condition, any GitHub repository could assume your role. For GCP, use Workload Identity Federation. For Azure, use Federated Identity Credentials on a Service Principal.

Le rôle IAM AWS doit faire confiance au fournisseur OIDC GitHub et restreindre la condition de confiance à votre dépôt et branche spécifiques (token.actions.githubusercontent.com:sub: repo:your-org/your-repo:ref:refs/heads/main). Sans cette condition, n’importe quel dépôt GitHub pourrait assumer votre rôle. Pour GCP, utilisez Workload Identity Federation. Pour Azure, utilisez les Federated Identity Credentials sur un Service Principal.

Terraform Security Hardening Checklist for 2026

Checklist de Durcissement Sécurité Terraform pour 2026

Below is a prioritized checklist covering the most impactful Terraform security controls. Start from the top — each item reduces your blast radius significantly.

Voici une checklist priorisée couvrant les contrôles de sécurité Terraform les plus impactants. Commencez par le haut — chaque élément réduit significativement votre rayon d’explosion.

## State File Security
[ ] Remote backend only — no local terraform.tfstate ever committed to git
[ ] S3 backend: encrypt=true, KMS customer-managed key, versioning, block_public_access
[ ] terraform.tfstate and *.tfstate.backup in .gitignore
[ ] State backend access restricted to CI/CD role only — no developer direct access
[ ] OpenTofu: enable native encryption with enforced=true

## Secrets Management
[ ] No secrets or credentials in .tf files — use AWS Secrets Manager, Vault, or SOPS
[ ] sensitive=true on all variable inputs that accept secrets (for CLI masking)
[ ] Use data sources to retrieve secrets at plan/apply time, never hardcode
[ ] Rotate any secret that has ever appeared in git history (assume compromised)

## Provider Security
[ ] Pin provider versions with = (exact) or ~> (minor range), never >=
[ ] Required_providers block with source and version for every provider
[ ] Upgrade vault-provider to v5.5.0+ (CVE-2025-13357 fix)
[ ] Audit deny_null_bind=true in all vault_ldap_auth_backend resources

## CI/CD Security
[ ] OIDC authentication — no static AWS/GCP/Azure credentials in CI/CD secrets
[ ] IAM role trust condition restricted to specific repo/branch
[ ] Checkov or Trivy IaC scan in every PR pipeline, fail on CRITICAL
[ ] Trivy: pin to SHA hash in GitHub Actions, not floating tag (supply chain risk)
[ ] terraform plan output stored as artifact, not printed in public logs

## Access Control
[ ] Least-privilege IAM for Terraform execution roles
[ ] Separate Terraform roles per environment (dev ≠ staging ≠ prod)
[ ] State locking via DynamoDB (AWS) or equivalent
[ ] Audit trail: CloudTrail/Audit Logs on all Terraform-managed resources

## Drift Detection
[ ] Scheduled terraform plan in CI to detect infrastructure drift
[ ] Alert on drift between state and real infrastructure

How Terraform CVEs Reach Your Application Dependencies

Comment les CVE Terraform Atteignent Vos Dépendances Applicatives

Terraform providers are software dependencies, and they carry CVEs just like any npm or pip package. CVE-2025-13357 in the Vault Provider is a perfect example: it shipped as a silent default misconfiguration across every version from v4.2.0 to v5.4.0. Providers sourced from the Terraform Registry are not immune to supply chain attacks — and unlike application lockfiles, Terraform provider version pinning is often looser (~> 5.0 instead of = 5.4.0), meaning a malicious patch release can reach your infrastructure automatically.

Les providers Terraform sont des dépendances logicielles, et ils portent des CVE tout comme n’importe quel package npm ou pip. CVE-2025-13357 dans le Vault Provider en est un exemple parfait : elle a été shipée comme une mauvaise configuration par défaut silencieuse dans chaque version de v4.2.0 à v5.4.0. Les providers provenant du Terraform Registry ne sont pas à l’abri des attaques supply chain — et contrairement aux lockfiles applicatifs, le pinning de version des providers Terraform est souvent plus lâche (~> 5.0 au lieu de = 5.4.0), ce qui signifie qu’une release de patch malveillante peut atteindre votre infrastructure automatiquement.

The broader picture: your application’s package-lock.json, poetry.lock, or Cargo.lock is not the only dependency file that needs continuous monitoring. Terraform provider versions, Helm chart dependencies, and Docker base image layers all carry CVEs that can compromise your infrastructure before a single line of application code runs. Learn more about monitoring all of these in our SBOM for Containers & Helm Charts guide.

La vision globale : le package-lock.json, poetry.lock ou Cargo.lock de votre application n’est pas le seul fichier de dépendances qui nécessite un monitoring continu. Les versions des providers Terraform, les dépendances des charts Helm et les couches d’images de base Docker portent toutes des CVE qui peuvent compromettre votre infrastructure avant qu’une seule ligne de code applicatif ne s’exécute. En savoir plus sur le monitoring de tout cela dans notre guide SBOM pour Containers & Helm Charts.

Frequently Asked Questions

Questions fréquentes