CVE-2026-117469 in Psono
Summary
by MITRE • 10/27/2026
Psono Server (CE & EE) versions 1.0.0 through 7.2.3 did not enforce the direction of file-transfer credentials on file-repository operations. An authenticated remote attacker with read-only access to a file could present a download transfer to the upload endpoint, obtain a signed upload URL for an attacker-selected object key, and append a chunk to the owner's file. Exploitation could upload or overwrite repository objects and consume storage, subject to transfer size, chunk-count, and lifetime limits.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Psono Server versions 1.0.0 through 7.2.3 represents a critical logic flaw within the application's file-repository operations, specifically concerning how credentials for file transfers are validated and enforced. This issue stems from an insufficient enforcement of directionality when handling requests to upload or download files. In secure systems, authentication tokens or signed URLs generated for downloading content should be strictly scoped to read-only actions, preventing their reuse in write operations such as uploads. However, the affected implementation fails to distinguish between these distinct operational modes during credential validation. This architectural oversight allows an attacker who has already authenticated and possesses only read access privileges to a specific file within the repository to manipulate the transfer mechanism for malicious purposes.
From a technical perspective, the exploitation path involves intercepting or obtaining a valid download transfer token intended for retrieving data from the server. Instead of using this credential solely for its intended purpose of downloading files, an authenticated attacker with limited permissions can present this same signed URL or token against the upload endpoint of the API. Because the backend logic does not rigorously check whether the generated signature corresponds to a write operation versus a read operation, it accepts the request as valid. The system then generates a new signed upload URL for an object key selected by the attacker. This effectively bypasses the intended access control restrictions that should prevent users with only read permissions from modifying or creating files in the repository.
The operational impact of this vulnerability is significant, allowing for unauthorized data manipulation and resource exhaustion. An attacker can successfully upload new objects to the file repository or overwrite existing ones belonging to other users, despite having been granted only read-only access initially. This capability compromises the integrity of stored data, as legitimate files can be replaced with malicious content without detection by standard permission checks. Furthermore, the vulnerability enables denial-of-service conditions through storage consumption. By repeatedly exploiting this flaw to upload large chunks or numerous small objects, an attacker can exhaust available disk space on the server, rendering the service unavailable for legitimate users. The extent of damage is constrained only by specific system limits regarding transfer size, chunk count, and the lifetime validity of the generated tokens, but within those bounds, the impact is severe.
This flaw aligns with CWE-284 Improper Access Control, as it involves a failure to properly restrict access for unauthorized actors, specifically bypassing intended restrictions on write operations through credential reuse. It also relates to CWE-693 Protection Mechanism Failure, where the system's built-in security controls fail to prevent the attack due to flawed logic in handling credentials. In terms of offensive cybersecurity frameworks, this behavior is characteristic of MITRE ATT&CK technique T1078 Valid Accounts, as it leverages legitimate authentication tokens for unauthorized actions, and potentially T1565 Data Manipulation if used to alter stored data or T1496 Resource Hijacking if utilized primarily for storage exhaustion.
Mitigation strategies must focus on strict separation of concerns between read and write operations at the API level. Developers should ensure that signed URLs and authentication tokens are generated with explicit scopes that prohibit cross-operation usage; a token created for downloading must be cryptographically bound to GET requests only, while upload capabilities require distinct credentials or additional validation steps. Implementing server-side checks that verify the intended action against the permissions associated with the current session is essential. Additionally, applying the principle of least privilege ensures that users cannot escalate their effective rights through API manipulation. For organizations running affected versions, immediate upgrading to a patched version where this logic flaw has been resolved is the primary remediation step. Until an upgrade can be performed, network-level controls such as Web Application Firewalls may help detect anomalous patterns of token reuse across different endpoints, although application-layer fixes remain necessary for complete protection.