Skip to content

CVE-2026-29200 - Comet Backup tenant impersonation IDOR

Comet Backup contains a critical tenant-impersonation authorization flaw. The NVD record says Comet Backup versions from 20.11.0 through 26.1.1, plus 26.2.1, allow a tenant administrator to impersonate end-user accounts from other tenants on the same server through a vulnerable API call.

That makes this a control-plane boundary issue, not just a routine application bug. A vulnerable multi-tenant backup server can expose backup metadata, restore capabilities, and tenant-owned account context to an administrator who should only control their own tenant.

Affected versions

  • Vulnerable: Comet Backup >=20.11.0, <=26.1.1
  • Also vulnerable: Comet Backup 26.2.1
  • Fixed: Confirm the currently patched version from Comet’s vendor advisory or release channel before deployment. Treat 26.1.1 and 26.2.1 as unsafe even if they appear newer than local baselines.

Indicator-of-exposure

  • The repository owns a Comet Backup server deployment, package pin, image, installer bundle, Helm chart, Terraform module, Ansible role, runbook, or SBOM.
  • A deployable Comet Backup server resolves to a version in the affected range.
  • The Comet Backup server is multi-tenant or grants tenant administrators the ability to manage end-user accounts.
  • Public or internal network paths expose the Comet Backup admin/API surface to tenant administrators.

Quick checks:

rg -n "comet|cometbackup|Comet Backup|COMET" .
rg -n "20\\.11\\.0|26\\.1\\.1|26\\.2\\.1|comet-server|cometd" .
find . -maxdepth 5 -type f \( -iname "*comet*" -o -iname "*backup*" \) -print

Remediation strategy

  • Upgrade every Comet Backup server past the affected release line using the vendor-supported patched release for the deployment channel.
  • Regenerate package locks, image digests, SBOMs, rendered manifests, and deployment evidence that prove the patched server version is the one that will actually run.
  • Until upgrade is complete, restrict tenant-admin network access to the Comet Backup API/admin surface and disable or block the vulnerable impersonation workflow if the repository controls a reverse proxy, WAF, or gateway policy.
  • Rotate Comet Backup web sessions, tenant-admin API tokens, and any support impersonation credentials after patching.
  • Audit Comet Backup logs for tenant-admin actions that accessed or impersonated users outside the actor’s tenant boundary.

The prompt 

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-29200 (Comet Backup tenant impersonation IDOR).
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades or contains the vulnerable
  Comet Backup deployment and documents required operator cleanup, or
- TRIAGE.md if this repository does not control a Comet Backup deployment or
  cannot safely make the change.

## Rules

- Scope only CVE-2026-29200.
- Treat backup metadata, tenant IDs, user IDs, backup paths, encryption keys,
  API tokens, session cookies, and restore destinations as sensitive. Do not
  print real values in logs, test fixtures, screenshots, or PR text.
- Do not attempt live impersonation against production tenants.
- Do not delete backup sets, restore data, change retention policy, rotate
  customer encryption keys, or modify tenant ownership automatically.
- Do not invent an API endpoint name. Use repository configuration, vendor
  advisory text, release notes, or existing Comet admin/API documentation to
  identify the controlled surface.
- Do not auto-merge.

## Steps

1. Inventory Comet Backup ownership in this repository:
   - Dockerfiles, image tags, installer URLs, package pins, checksums, SBOMs;
   - Helm/Kubernetes manifests, Compose files, Terraform, Ansible, Packer, AMIs;
   - gateway, reverse proxy, WAF, or firewall policy that exposes Comet admin
     or API routes;
   - operational runbooks for tenant administration, support impersonation,
     backup restore, or API token management.
2. If the repository does not deploy or configure Comet Backup, stop with
   `TRIAGE.md` listing every path checked and the likely runtime owner.
3. Determine the resolved Comet Backup server version for every deployable
   environment. Treat `>=20.11.0, <=26.1.1` and `26.2.1` as vulnerable.
4. Upgrade each vulnerable server to the latest vendor-supported patched
   release. If the vendor maintains separate stable and latest tracks, choose
   the patched track already used by the repository unless security policy
   requires the latest channel.
5. Regenerate all derived artifacts controlled by the repository: lockfiles,
   image digests, SBOMs, Helm render output, deployment manifests, golden
   snapshots, checksum allowlists, and version evidence.
6. Add temporary containment if the patched release cannot be deployed
   immediately:
   - restrict tenant-admin access to Comet admin/API routes by VPN, allowlist,
     identity-aware proxy, or equivalent gateway control;
   - block the documented impersonation route or workflow at the edge if the
     repository controls that policy;
   - disable support impersonation features where configuration allows;
   - add an emergency runbook requiring tenant boundary log review and token
     rotation after patch.
7. Add a PR body section named `CVE-2026-29200 operator actions` that requires:
   - confirming production now runs a patched Comet Backup version;
   - invalidating Comet Backup web sessions and tenant-admin API tokens;
   - reviewing audit logs for tenant-admin impersonation or cross-tenant user
     access;
   - preserving suspicious logs for incident response;
   - validating backup and restore workflows after the upgrade without exposing
     customer backup data.
8. Add or update verification that proves the deployed artifact is not
   `20.11.0` through `26.1.1` and is not `26.2.1`. Prefer a version assertion
   in deployment tests, image metadata checks, SBOM policy, or runbook smoke
   test.
9. Run the repository's relevant validation: image build, IaC plan/render,
   deployment schema validation, SBOM generation, package checksum checks, and
   security scan.
10. Use PR title:
    `fix(sec): remediate CVE-2026-29200 in Comet Backup`.

## Stop conditions

- No Comet Backup deployment, image, runbook, or infrastructure path is
  controlled by this repository.
- The resolved Comet Backup version can only be determined from production
  access that the agent does not have.
- The vendor-patched release is not available through the repository's allowed
  deployment channel.
- The only apparent fix would delete or restore backup data, alter tenant
  ownership, rotate customer-held encryption keys, or expose tenant identifiers.
- Validation fails for unrelated pre-existing reasons; document the failure
  instead of broadening scope.

Verification - what the reviewer looks for

  • No deployable Comet Backup server artifact resolves to 20.11.0 through 26.1.1, or to 26.2.1.
  • The actual delivery path was changed: package pin, installer checksum, image digest, deployment manifest, SBOM, or operational runbook.
  • Temporary containment is present when a full upgrade is blocked.
  • Operator actions cover session/API-token invalidation and cross-tenant audit review.
  • Tests, image builds, IaC renders, and security scans pass or unrelated failures are explicitly documented.

Watch for

  • Repositories that update documentation but leave base images or installer URLs pinned to a vulnerable Comet version.
  • Multiple Comet deployment tracks where one environment uses the 26.1.x branch and another uses 26.2.1.
  • PRs that prove a package version changed but do not prove the rebuilt image or rendered deployment references the patched artifact.
  • Incident-response work that requires live tenant data. Keep code changes and production investigation clearly separated.

References