dbcve.org
Improper AuthorizationWeakness · CWE-285

CVE-2026-56231

HIGH · 7.6 CVSS v3.1 Published 2026-06-24
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
82/100
Remediation priority · High
Remotely reachable Zero-click 8 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Capgo before 12.128.2 contains a broken object level authorization (BOLA) vulnerability in the POST /build/start/:jobId and POST /build/cancel/:jobId endpoints. The handlers authorize the request based only on the attacker-controlled app_id supplied in the request body and never verify that the jobId in the URL belongs to that app_id (or the same tenant/org) before issuing privileged builder commands with the server-held builder API key. An authenticated user with the app.build_native permission for any app they control can start or cancel arbitrary builder jobs belonging to other tenants by supplying a victim jobId, resulting in cross-tenant build sabotage (denial of service), unauthorized compute actions, and potential billing impact.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

This is a Broken Object Level Authorization (BOLA) vulnerability in Capgo's build API endpoints. The /build/start/:jobId and /build/cancel/:jobId endpoints authorize requests based solely on an attacker-controlled app_id in the request body without validating that the jobId belongs to that app_id or tenant. This allows authenticated users to manipulate build jobs belonging to other tenants by supplying arbitrary jobIds, enabling cross-tenant build sabotage and unauthorized compute actions.

MitigationUpgrade to Capgo 12.128.2 or later, and implement proper server-side validation that verifies the jobId in the URL belongs to the same tenant/organization as the authenticated user before executing builder commands.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Capgo version
    Check the installed Capgo version by reviewing package.json, package-lock.json, or running 'capgo --version' or checking the admin dashboard version display
    Affected if Version is below 12.128.2 (any version < 12.128.2 is affected)
  2. Verify build API endpoint exposure
    Review API routing configuration or server logs to confirm endpoints /build/start/:jobId and /build/cancel/:jobId are registered and accessible
    Affected if These build job control endpoints are exposed in the API surface
  3. Inspect tenant isolation in build endpoints
    Examine the source code or API gateway configuration for the /build/start/:jobId and /build/cancel/:jobId route handlers, specifically looking for server-side validation that confirms the jobId belongs to the authenticated user's tenant before processing the request
    Affected if No server-side tenant/owner validation exists for jobId in these endpoints, or validation relies only on app_id from request body
  4. Test cross-tenant access control
    If you have test environments, authenticate as User A (tenant A), obtain a valid jobId belonging to tenant B, and attempt to call /build/start/:jobId or /build/cancel/:jobId with tenant B's jobId while providing tenant A's app_id in the request body
    Affected if The request succeeds or returns a 2xx response, indicating the authorization check is bypassed

Your environment is affected if Capgo version is below 12.128.2 AND the build API endpoints are exposed, especially if tenant validation for jobId is missing or relies solely on client-provided app_id.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade to Capgo 12.128.2 or later, and implement proper server-side validation that verifies the jobId in the URL belongs to the same tenant/organization as the authenticated user before executing builder commands.

Recommended fix High confidence

12.128.2 or later

  1. 1. Identify the current version of Capgo installed in your environment
  2. 2. Upgrade Capgo to version 12.128.2 or later to address the BOLA vulnerability
  3. 3. After upgrading, verify that the /build/start/:jobId and /build/cancel/:jobId endpoints now properly validate that the jobId belongs to the requested app_id/tenant before executing builder commands
  4. 4. Test the fix by attempting to start/cancel a build job from one app using a jobId from a different app - this should now be rejected with an authorization error
  5. 5. Monitor for any unexpected behavior and review access logs to confirm the authorization checks are functioning correctly

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation3.0 h
  • Implementation8.0 h
  • Testing6.0 h
  • Review / QA3.0 h
20.0 hours of engineering $3,480
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,568.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-56231 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-56231 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data