CVE-2026-128970: Psono: missing accepted check allows share-right deletion

MEDIUM

Published November 13, 2026

CISO Take

Psono Server (a self-hosted password and secrets manager) fails to require accepted group membership when authorizing DELETE /share/right/, so a user who was merely invited to a group with share-admin rights, or who declined the invitation, can delete that group's share-right record if they know its UUID. The impact is availability and integrity of access rather than disclosure: all accepted group members lose access to the affected share and its secrets, but the underlying data is not deleted or read. Exploitation likelihood looks low to moderate: EPSS is not available, there is no public exploit, no Nuclei template, no CISA KEV listing and no SSVC decision, and the attacker needs an authenticated account, an invitation, and a share-right UUID. It maps only loosely to AI systems (it is categorized as ai_agent, but no AI component is evident), so it matters mainly if Psono stores credentials used by AI agents, pipelines or API integrations that would break when access is revoked. Upgrade Psono Community or Enterprise Edition to 7.5.1 (released 2026-10-13) and audit recent share-right deletions.

Sources:NVDATLASgitlab.com/esaqa

What is the risk?

Medium (CVSS 5.4). Network-exploitable with low complexity, low privileges and no user interaction (AV:N/AC:L/PR:L/UI:N). Confidentiality is unaffected; integrity and availability impact is low to moderate, limited to revoking group access to shares. Prerequisites narrow exposure: the attacker needs an account on the instance, a pending or declined invitation to a group with share_admin=True, and knowledge of a group share-right UUID. No known exploitation, no public exploit and no EPSS data. The root weakness is CWE-863 (incorrect authorization). Relevance to AI/ML is indirect: the AI categorization is weak and the flaw sits in a secrets manager, not in a model or agent framework.

How does the attack unfold?

Initial Access

Attacker holds a low-privilege Psono account and receives an invitation to a group with share-admin rights, leaving it pending or declining it.

AML.T0012

Exploitation

Attacker sends DELETE /share/right/ with a known share-right UUID, and the server authorizes it without checking accepted=True.

AML.T0049

Impact

The group's share-right is deleted, revoking access to the share and its secrets for all accepted members and disrupting dependent AI agents or pipelines.

Initial Access

Attacker holds a low-privilege Psono account and receives an invitation to a group with share-admin rights, leaving it pending or declining it.

AML.T0012

Exploitation

Attacker sends DELETE /share/right/ with a known share-right UUID, and the server authorizes it without checking accepted=True.

AML.T0049

Impact

The group's share-right is deleted, revoking access to the share and its secrets for all accepted members and disrupting dependent AI agents or pipelines.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Psono	—	—	No patch

Do you use Psono? You're affected.

How severe is it?

CVSS 3.1

5.4 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

ILow

ALow

What should I do?

1 step

1) Upgrade Psono Server Community Edition and Enterprise Edition to 7.5.1 or later (fix commit published in the GitLab repository). 2) Until patched, avoid granting share-admin rights through pending invitations, and review pending or declined group invitations that carry share_admin, revoking or deleting them where not needed. 3) Restrict self-registration and invitation workflows to trusted users, and limit network exposure of the Psono API. 4) Detection: review API and application logs for DELETE /share/right/ requests made by users whose group membership has accepted=None or accepted=False, and for unexpected loss of share access reported by users or automation. 5) Keep backups of share and group configuration so deleted share-rights can be recreated quickly. 6) Consider mirroring critical AI-agent and pipeline secrets with a fallback retrieval path to limit outage from revoked access.

How is it classified?

Auth BypassDoSFrameworkAML.T0012- Valid Accounts AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Mechanisms to respond to and recover from incidents

Frequently Asked Questions

What is CVE-2026-128970?

Is CVE-2026-128970 actively exploited?

No confirmed active exploitation of CVE-2026-128970 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-128970?

1) Upgrade Psono Server Community Edition and Enterprise Edition to 7.5.1 or later (fix commit published in the GitLab repository). 2) Until patched, avoid granting share-admin rights through pending invitations, and review pending or declined group invitations that carry share_admin, revoking or deleting them where not needed. 3) Restrict self-registration and invitation workflows to trusted users, and limit network exposure of the Psono API. 4) Detection: review API and application logs for DELETE /share/right/ requests made by users whose group membership has accepted=None or accepted=False, and for unexpected loss of share access reported by users or automation. 5) Keep backups of share and group configuration so deleted share-rights can be recreated quickly. 6) Consider mirroring critical AI-agent and pipeline secrets with a fallback retrieval path to limit outage from revoked access.

What systems are affected by CVE-2026-128970?

This vulnerability affects the following AI/ML architecture patterns: Secrets management, Agent frameworks, ML pipelines, CI/CD credential stores.

What is the CVSS score for CVE-2026-128970?

CVE-2026-128970 has a CVSS v3.1 base score of 5.4 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

Secrets managementAgent frameworksML pipelinesCI/CD credential stores

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

What are the technical details?

Original Advisory

Psono Server Community Edition versions 1.12.6 through 7.5.0 and Psono Server Enterprise Edition before 7.5.1 do not require accepted group membership when authorizing deletion of group share-rights. The DELETE /share/right/ endpoint checks for a membership matching the target group, the authenticated user, and share_admin=True, but omits accepted=True. An authenticated remote attacker who has been invited to a group with share-admin privileges, and who knows a group share-right UUID, can therefore delete that group's share-right record without accepting the invitation or after declining it. Pending invitations have accepted=None, while declined invitations retain accepted=False and the share_admin flag. Deletion revokes the group's access to the affected share and its contained secrets for all accepted group members, without deleting the underlying data or disclosing secret contents. The issue was fixed in version 7.5.1 of both editions, released on 2026-10-13.

Exploitation Scenario

An attacker with a low-privilege account on a Psono instance is invited to a group with share-admin privileges, for example by a colleague or through an invitation they can induce. They decline it or leave it pending, then obtain the UUID of the group's share-right, for instance from API responses or shared references. They send an authenticated DELETE /share/right/ request, which the server authorizes because the check omits accepted=True. The group immediately loses access to the share holding secrets such as LLM API keys or agent service credentials, causing AI agents and pipelines that depend on those secrets to fail until an admin restores access.

Weaknesses (CWE)

CWE-863Incorrect Authorization

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.