CVE-2026-102649 in Burrito
Summary
by MITRE • 10/26/2026
Burrito is a Terraform Automation Collaboration Software (TACoS) Kubernetes operator. Prior to 0.13.0, `POST /api/webhook` accepts unsigned GitHub and GitLab events when a `TerraformRepository`'s credentials omit `webhookSecret` or set it to an empty value, including credentials configured for git authentication and polling. `Credential.WebhookSecret` is optional, and `go-playground/webhooks` skips signature or token verification when the secret is empty. Anyone who can reach `burrito-server`'s endpoint and knows a tracked repository's URL can forge events to create or delete `TerraformPullRequest` custom resources with attacker-chosen `Branch`, `Base`, and `ID` fields. For GitHub `pull_request` events, the controller fetches changed files using the real pull request number but does not cross-check the payload's branch against that pull request. Pairing a real, existing pull request number with an unrelated existing branch in the same repository can therefore cause an unauthorized `terraform plan` for affected layers using the operator's stored git and cloud credentials. Code analysis also indicates that the resulting plan can be posted to the real pull request's comment thread, exposing and misattributing another branch's infrastructure changes. Auto-apply is disabled for these temporary layers, so this vulnerability alone cannot force a `terraform apply`; plan-time provider and data-source code execution depends on the selected branch's contents. This issue is fixed in version 0.13.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/26/2026
The Burrito Terraform Automation Collaboration Software (TACoS) Kubernetes operator, prior to version 0.13.0, contains a critical authentication bypass vulnerability within its webhook handling mechanism that allows attackers to forge repository events and trigger unauthorized infrastructure planning operations. This flaw stems from the optional nature of the `webhookSecret` configuration field in TerraformRepository resources. When this secret is omitted or set to an empty value, which includes credentials configured for both git authentication and polling mechanisms, the underlying library go-playground/webhooks skips signature verification entirely. Consequently, any external actor who can reach the burrito-server endpoint and possesses knowledge of a tracked repository's URL can inject forged GitHub or GitLab events without cryptographic validation. This lack of integrity checking represents a fundamental failure in input validation where trusted sources are assumed based on network accessibility rather than verified identity, leading to CWE-287 Improper Authentication vulnerabilities that undermine the security boundary between external event streams and internal automation logic.
The operational impact of this vulnerability is severe as it enables attackers to create or delete TerraformPullRequest custom resources with arbitrary values for Branch, Base, and ID fields. The system's design flaw becomes particularly dangerous when processing GitHub pull_request events because while the controller fetches changed files using a real pull request number provided in the forged payload, it fails to cross-check whether the branch specified in the event actually corresponds to that specific pull request. This logical inconsistency allows an attacker to pair a legitimate, existing pull request identifier with an unrelated but valid branch within the same repository. By doing so, the system proceeds to execute terraform plan for affected layers using the operator's stored git and cloud credentials against the attacker-selected branch rather than the intended one. This misalignment results in unauthorized infrastructure state analysis that leverages privileged access tokens without proper authorization checks.
Furthermore, the vulnerability extends beyond mere execution of plans into significant information disclosure and operational confusion. The resulting terraform plan output is posted to the comment thread of the real pull request referenced by the forged event ID. This action exposes sensitive infrastructure change details for a branch unrelated to the actual pull request discussion while simultaneously misattributing these changes to that legitimate context. Such behavior can lead to severe confusion among development and operations teams, potentially causing incorrect deployment decisions or masking malicious activity within normal CI/CD workflows. Although auto-apply is disabled for these temporary layers preventing immediate infrastructure modification via this specific vector, the exposure of plan outputs constitutes a high-severity data leakage risk under CWE-200 Information Exposure. Additionally, if the selected branch contains provider plugins or data sources capable of code execution during the planning phase, an attacker could potentially achieve remote code execution on the system running the operator, aligning with ATT&CK techniques related to command and script interpretation within CI/CD pipelines.
To mitigate this vulnerability, organizations must ensure that all TerraformRepository resources are configured with a strong, non-empty webhookSecret value before deploying Burrito in production environments. This secret acts as the cryptographic key for verifying incoming event signatures from GitHub or GitLab services, ensuring that only legitimate events trigger automation workflows. For systems already running versions prior to 0.13.0, immediate patching to version 0.13.0 is required as this release explicitly addresses the signature verification bypass by enforcing mandatory secret validation regardless of configuration defaults. Additionally, implementing network-level restrictions such as IP whitelisting for webhook endpoints can provide defense-in-depth against unauthorized access attempts from untrusted networks. Regular auditing of TerraformRepository configurations should be conducted to verify that no resources are left with empty or missing security credentials, thereby closing the gap exploited by this authentication bypass flaw and maintaining the integrity of automated infrastructure management processes.