Summary
Burrito's webhook endpoint may accept unsigned GitHub and GitLab events when a repository credential has no webhook secret or an empty one. An attacker who can reach the server and identify a tracked repository may forge events to manipulate TerraformPullRequest resources, trigger unauthorized plans using stored credentials, and potentially expose plan results.
Burrito's webhook endpoint may accept unsigned GitHub and GitLab events when a repository credential has no webhook secret or an empty one. An attacker who can reach the server and identify a tracked repository may forge events to manipulate TerraformPullRequest resources, trigger unauthorized plans using stored credentials, and potentially expose plan results.
Affected context
The issue affects Burrito deployments that expose the webhook endpoint while using TerraformRepository credentials without a non-empty webhook secret. It is most relevant where an attacker can reach the burrito-server API and knows the URL of a tracked repository. GitHub pull request processing may additionally become unsafe when event branch information is not cross-checked against the real pull request associated with the event.
The issue affects Burrito deployments that expose the webhook endpoint while using TerraformRepository credentials without a non-empty webhook secret. It is most relevant where an attacker can reach the burrito-server API and knows the URL of a tracked repository. GitHub pull request processing may additionally become unsafe when event branch information is not cross-checked against the real pull request associated with the event.
Exploit preconditions
- Attack surface: The reachable
POST /api/webhookendpoint - Required access: Network reachability to
burrito-serverand knowledge of a tracked repository URL; valid webhook authentication is not required when the configured secret is empty - Trigger point: Processing of forged GitHub or GitLab webhook events
- Why exploitation is possible: Signature or token verification is skipped for empty secrets, allowing attacker-controlled branch, base, and identifier fields to influence custom resource creation or deletion
- Additional condition for unauthorized plans: A suitable existing pull request and attacker-selected branch must be available in the same repository, with affected layers configured for processing
- Attack surface: The reachable
POST /api/webhookendpoint - Required access: Network reachability to
burrito-serverand knowledge of a tracked repository URL; valid webhook authentication is not required when the configured secret is empty - Trigger point: Processing of forged GitHub or GitLab webhook events
- Why exploitation is possible: Signature or token verification is skipped for empty secrets, allowing attacker-controlled branch, base, and identifier fields to influence custom resource creation or deletion
- Additional condition for unauthorized plans: A suitable existing pull request and attacker-selected branch must be available in the same repository, with affected layers configured for processing
Why this happens
The primary flaw is an optional webhook secret combined with parser behavior that treats an empty secret as permission to skip authentication. This maps to CWE-306: Missing Authentication for Critical Function. The resulting trust in unauthenticated event fields also creates an authorization weakness consistent with CWE-863: Incorrect Authorization, because attackers can influence operations intended to be restricted to legitimate repository events. In the GitHub path, failing to correlate the payload branch with the real pull request further allows identity and event context to be confused.
The primary flaw is an optional webhook secret combined with parser behavior that treats an empty secret as permission to skip authentication. This maps to CWE-306: Missing Authentication for Critical Function. The resulting trust in unauthenticated event fields also creates an authorization weakness consistent with CWE-863: Incorrect Authorization, because attackers can influence operations intended to be restricted to legitimate repository events. In the GitHub path, failing to correlate the payload branch with the real pull request further allows identity and event context to be confused.
Potential impact
- Attackers may create or delete
TerraformPullRequestcustom resources. - Unauthorized Terraform plans may run with the operator's stored Git and cloud credentials.
- Plan output may be posted to a legitimate pull request, exposing infrastructure details or misattributing changes.
- Provider or data-source behavior from a selected branch could potentially execute code during planning.
- Repository automation state and collaboration workflows may be disrupted.
- The vulnerability alone may not force a Terraform apply when auto-apply is disabled.
- Attackers may create or delete
TerraformPullRequestcustom resources. - Unauthorized Terraform plans may run with the operator's stored Git and cloud credentials.
- Plan output may be posted to a legitimate pull request, exposing infrastructure details or misattributing changes.
- Provider or data-source behavior from a selected branch could potentially execute code during planning.
- Repository automation state and collaboration workflows may be disrupted.
- The vulnerability alone may not force a Terraform apply when auto-apply is disabled.
General mitigation guidance
Mitigation centers on making webhook authentication mandatory and preserving event-to-resource authorization boundaries.
Common defensive patterns include:
- Require a non-empty, high-entropy webhook secret for every repository integration.
- Reject webhook requests when authentication material is absent, empty, malformed, or invalid.
- Use secure-by-default credential schemas that do not treat omitted secrets as authenticated configurations.
- Verify that repository, pull request number, branch, and base fields correspond to the same trusted event and remote object.
- Avoid using attacker-controlled identifiers to select privileged resources without server-side authorization.
- Apply least privilege to the operator's Git, cloud, and Kubernetes permissions.
- Restrict webhook endpoint exposure through network policy, ingress controls, and authenticated service boundaries.
- Treat plan output as sensitive and limit where it can be posted or who can access it.
Mitigation centers on making webhook authentication mandatory and preserving event-to-resource authorization boundaries.
Common defensive patterns include:
- Require a non-empty, high-entropy webhook secret for every repository integration.
- Reject webhook requests when authentication material is absent, empty, malformed, or invalid.
- Use secure-by-default credential schemas that do not treat omitted secrets as authenticated configurations.
- Verify that repository, pull request number, branch, and base fields correspond to the same trusted event and remote object.
- Avoid using attacker-controlled identifiers to select privileged resources without server-side authorization.
- Apply least privilege to the operator's Git, cloud, and Kubernetes permissions.
- Restrict webhook endpoint exposure through network policy, ingress controls, and authenticated service boundaries.
- Treat plan output as sensitive and limit where it can be posted or who can access it.
How teams detect issues like this
Detection can combine configuration review, source analysis, runtime monitoring, and policy enforcement:
- Search code and configuration for optional webhook secrets, empty-secret branches, or verification libraries invoked conditionally.
- Review webhook handlers for early returns that bypass signature or token validation.
- Inspect authorization logic for trust in client-supplied branch, base, repository, or pull request identifiers.
- Monitor for unsigned webhook requests, unexpected custom resource creation or deletion, and plans associated with unusual branches.
- Alert when plan comments reference pull requests or branches that do not match the triggering event.
- Enforce CI and admission policies requiring webhook authentication and least-privilege service accounts.
- Automated code review and static analysis tools may help identify missing authentication and insufficient object-correlation checks.
Detection can combine configuration review, source analysis, runtime monitoring, and policy enforcement:
- Search code and configuration for optional webhook secrets, empty-secret branches, or verification libraries invoked conditionally.
- Review webhook handlers for early returns that bypass signature or token validation.
- Inspect authorization logic for trust in client-supplied branch, base, repository, or pull request identifiers.
- Monitor for unsigned webhook requests, unexpected custom resource creation or deletion, and plans associated with unusual branches.
- Alert when plan comments reference pull requests or branches that do not match the triggering event.
- Enforce CI and admission policies requiring webhook authentication and least-privilege service accounts.
- Automated code review and static analysis tools may help identify missing authentication and insufficient object-correlation checks.
