GPU VulnDB

Database/Control plane, storage & DevOps

Harness: missing space-scoped access control lets any authenticated user read other spaces' infra provider configs

CVSS 7.1CVE-2026-92750Control plane, storage & DevOpscurated

Impact

Harness through 3.3.0 does not check space membership on the infrastructure provider read/list endpoints, so any logged-in user can pass an arbitrary space identifier and pull back that space's provider configuration. The exposed metadata includes Docker endpoints, TLS certificate paths and cloud project identifiers - a map of the build and delegate infrastructure behind another team's pipelines. On a shared GPU fleet where Harness drives image builds and job submission, this hands a low-privileged tenant the addresses and cert locations needed to plan a follow-on attack against a neighbour's build plane. Confidentiality only; no write or execution is claimed.

Who can reach it

Any authenticated Harness user, over the network, with a valid login but no membership in the target space. No admin role required.

What to do

Upgrade Harness past 3.3.0 to a release carrying the access-control fix and restart the Harness service; the advisory does not name a fixed version, so confirm against the vendor issue before scheduling. Until then, review who holds accounts on the instance and rotate any credentials or certificates whose paths were exposed. Control-plane only - no GPU node needs to be drained.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.