Skip to main content
VulnerabilityPublished

CVE-2026-22806: loft · Incorrect Authorization

Affects loftSource CVE Database V5

0

Not known to be exploited · CVSS 9.1 Critical · fixed in 4.5.3 : patch loft as a priority.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
9.1Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 41% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 4.5.3, 4.4.2, 4.3.10
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 29 Jan 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade loft to 4.5.3, 4.4.2 or 4.3.10; loft-sh/loft to 4.3.10.

Affected software

ProductAffectedFixed in
loft-shloftAffected
  • >=4.5.3 <4.5.3
Fixed in
  • 4.5.3
loft-shloftAffected
  • >=4.4.0 <4.4.2
Fixed in
  • 4.4.2
loft-shloftAffected
  • <4.3.10
Fixed in
  • 4.3.10
GitHubloft-sh/loftpkg:github/loft-sh/loftOther threatsAffected
  • <4.3.10
Fixed in
  • 4.3.10

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

  1. Immediate upgrade to loft-sh vCluster versions 4.3.10, 4.4.2, 4.5.4, or 4.6.0 or later, which contain fixes for this vulnerability.
  2. Conduct a thorough audit of all existing access keys, focusing on those with scoped permissions, to ensure they are assigned only necessary privileges and are not over-privileged.
  3. Implement strict role-based access control (RBAC) policies to limit who can create or manage access keys, reducing the risk of misuse.
  4. Where immediate upgrading is not feasible, create automation users with minimal permissions and use scoped access keys for these users to limit potential exposure.
  5. Monitor cluster logs and access patterns for anomalous activity that could indicate exploitation attempts or unauthorized access.
  6. Educate administrators and DevOps teams about the risks associated with scoped access keys and enforce best practices for key management.
  7. Integrate vulnerability scanning and compliance checks into CI/CD pipelines to detect outdated loft versions and insecure configurations early.

Description

vCluster Platform provides a Kubernetes platform for managing virtual clusters, multi-tenancy, and cluster sharing. Prior to versions 4.6.0, 4.5.4, 4.4.2, and 4.3.10, when an access key is created with a limited scope, the scope can be bypassed to access resources outside of it. However, the user still cannot access resources beyond what is accessible to the owner of the access key. Versions 4.6.0, 4.5.4, 4.4.2, and 4.3.10 fix the vulnerability. Some other mitigations are available. Users can limit exposure by reviewing access keys which are scoped and ensuring any users with access to them have appropriate permissions set. Creating automation users with very limited permissions and using access keys for these automation users can be used as a temporary workaround where upgrading is not immediately possible but scoped access keys are needed.

References

Community reviews

Loading reviews…