CVE-2026-116683 in Terraform Provider CtfD
Summary
by MITRE • 10/27/2026
CTFer.io's CTFd Terraform Provider manages CTFd resources as code. From 0.1.5 until 2.8.2, ctfd_team.password is stored as a non-sensitive value in Terraform state. A local or remote user with access to that state can read the team password without an additional decryption step. This issue is fixed in 2.8.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified within CTFd Terraform Provider versions ranging from 0.1.5 through 2.8.2 represents a critical misconfiguration in how sensitive credentials are handled during infrastructure provisioning workflows. Specifically, the ctfd_team.password attribute was incorrectly defined as a non-sensitive value within the provider's schema definition. In the context of HashiCorp Terraform, attributes marked as non-sensitive are treated as standard data fields that can be logged, displayed in console output, and stored without encryption or masking protections. This design flaw fundamentally undermines the security model intended for managing sensitive infrastructure components such as user credentials, exposing them to potential interception during both state storage and runtime operations.
The operational impact of this vulnerability is severe due to the nature of Terraform's state management mechanism. When a provider executes changes against an environment, it updates a local or remote state file that records the current configuration and resource attributes. Because the password was not flagged as sensitive, it was written into this state file in plaintext without any additional encryption layer applied by the tooling itself. Consequently, any individual with read access to the Terraform state file can extract the cleartext passwords for CTFd teams directly from the stored data. This exposure bypasses standard security controls that rely on obfuscation or restricted visibility of sensitive fields during routine administrative tasks such as debugging, auditing, or reviewing infrastructure changes.
From a classification perspective, this issue aligns with CWE-312, which describes Cleartext Storage of Sensitive Information. The vulnerability also maps to the Credential Access technique within the MITRE ATT&CK framework, specifically relating to methods where adversaries target stored credentials in configuration files or state repositories. In modern DevOps environments where Terraform is used extensively for infrastructure as code, such misconfigurations can lead to widespread credential leakage across multiple systems if the same pattern of non-sensitive handling is applied to other critical secrets like API keys, database passwords, or private SSH keys within the provider's scope.
To mitigate this risk and prevent similar issues in future deployments, it is imperative that all sensitive attributes managed by infrastructure as code tools are explicitly marked with sensitivity flags. For Terraform providers, this involves defining resource arguments with the Sensitive attribute set to true, which instructs the engine to mask these values in logs and encrypt them appropriately within state files depending on backend configuration. Organizations should immediately upgrade to version 2.8.2 or later of the CTFd Terraform Provider where this behavior has been corrected. Additionally, teams currently using affected versions must rotate all compromised team passwords as a precautionary measure, assuming that any accessible state file may have already exposed these credentials to unauthorized parties.