Padok Burrito CVE-2026-102649

The concrete prerequisite is a TerraformRepository whose credential omits the webhookSecret field or sets it to an empty value - the documented default for operators who follow the git-authentication setup and rely on polling; with the secret empty, go-playground/webhooks skips HMAC/token verification entirely. The attacker must be able to reach burrito-server's /api/webhook (which project docs instruct exposing to the internet) and must know the tracked repository's URL; no credentials, signature, or user interaction are required. For the escalation to planning an unrelated branch, the attacker additionally needs a real, existing pull request number (trivially discoverable) paired with any existing branch name in the same repo, because the controller fetches changed files by PR number but never cross-checks the payload's branch. Limiting factors that reduce real-world risk: a non-empty webhookSecret fully blocks forgery (events are rejected after the fix); auto-apply is hardcoded off for these temporary layers so this flaw alone cannot force terraform apply; and any plan-time provider/data-source code execution depends on the contents of the selected branch.

The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:H, 9.9) describes a remote, unauthenticated, no-interaction flaw with a scope change, and the vuln.today Decision label is act_now - so this should be treated as a real, high-urgency priority, not a paper-high score. The strongest corroborating signal is a working proof-of-concept embedded in the GHSA advisory itself (a Ginkgo/Gomega envtest driving the production HTTP handler against real kube-apiserver+etcd, with observed passing output), which demonstrates the directly-proven impact: forged, unsigned events creating attacker-controlled TerraformPullRequest CRs. Two key signals are MISSING from the input and should be flagged: no EPSS exploitation-probability score is provided, and the CVE is NOT listed in CISA KEV, so there is no evidence of active in-the-wild exploitation despite the act_now label - urgency here rests on ease of exploitation and the public PoC, not on observed attacks. A caveat on severity: exploitation is gated on a configuration state (credential lacking webhookSecret), which the vector's AC:L does not surface; however, the advisory establishes this is the DEFAULT for the common git-authentication + polling setup, so AC:L is defensible. The input's A:H appears overstated relative to the described impact (CR creation/deletion and forced terraform plan), where I assess integrity and availability as Low and confidentiality as Low; the real teeth are the scope change into the Kubernetes cluster and Terraform runs executing under the operator's stored git and cloud credentials.

An attacker who can reach the internet-exposed burrito-server /api/webhook (which the project's own docs instruct operators to publish) and who knows a tracked repository's URL sends a hand-crafted, unsigned pull_request event; because the repository's credential has no webhookSecret, go-playground/webhooks skips signature verification and Burrito accepts it as genuine. This creates a TerraformPullRequest CR with attacker-chosen Branch/Base/ID, forcing an unauthorized terraform plan under the operator's stored git and cloud credentials; pairing a real PR number with an unrelated existing branch can post that branch's infrastructure diff onto the real PR thread. A working PoC (a Go envtest with observed passing output) is published in the GHSA advisory proving the CR-creation and plan-trigger path.