CVE-2026-117472 in Psono
Summary
by MITRE • 10/27/2026
Psono Server CE && EE versions 4.0.33 through 7.2.3 compared the request path for the bulk-secret-read endpoint with a hard-coded unprefixed path. In deployments configured with URL_PREFIX, the comparison failed and the POST request was authorized using write scope instead of read scope. An authenticated remote attacker with an unusual read-disabled, write-enabled API key could therefore retrieve encrypted secret data and nonces through the prefixed bulk-secret-read endpoint despite lacking read permission. The default configuration without URL_PREFIX was not affected.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Psono Server versions 4.0.33 through 7.2.3 represents a critical authorization bypass rooted in improper handling of URL prefixes within the application's access control logic. This flaw specifically affects deployments that utilize the URL_PREFIX configuration parameter, which is commonly employed to host multiple services behind a reverse proxy or to isolate specific applications on shared domains by routing traffic through distinct sub-paths rather than root paths. In these environments, the server fails to correctly validate the request path against its internal authorization rules when determining whether an API key possesses sufficient privileges for bulk secret retrieval operations.
The technical core of this vulnerability lies in a flawed comparison mechanism within the bulk-secret-read endpoint handler. The application compares the incoming request path against a hard-coded unprefixed string, effectively ignoring any URL prefix configured by the administrator. This logical error results in the authorization system misinterpreting the context of the request. Instead of recognizing that the request is targeting a prefixed route where specific read-only permissions might be enforced or restricted, the server defaults to evaluating the endpoint based on its base path definition. Consequently, the security check incorrectly grants write scope privileges to requests that should have been evaluated under stricter read scope constraints.
This misconfiguration allows for a significant escalation of privilege for authenticated users possessing API keys with specific permission profiles. An attacker who has obtained an API key configured with write-enabled but read-disabled permissions can exploit this flaw to bypass the intended restrictions. By crafting POST requests directed at the bulk-secret-read endpoint, the attacker leverages the server's erroneous authorization logic to execute operations that require higher-level access than their credentials should permit. The system erroneously accepts these requests as valid under a broader scope of authority, effectively neutralizing the security controls designed to limit data exposure based on user roles and key permissions.
The operational impact of this vulnerability is severe, particularly in environments where sensitive cryptographic material or confidential secrets are stored within Psono Server. An authenticated remote attacker can successfully retrieve encrypted secret data and associated nonces from the server despite lacking explicit read access rights. This breach compromises the confidentiality integrity of the vaulted information, as the attacker gains unauthorized visibility into protected assets that were intended to be inaccessible via their current credentials. The ability to extract these elements facilitates further potential attacks, including offline decryption attempts if additional keys are compromised or social engineering efforts targeting key holders.
Mitigation strategies must address both immediate remediation and long-term architectural resilience. Organizations running affected versions of Psono Server should immediately upgrade to a patched version that corrects the path comparison logic for URL-prefixed deployments. For environments where upgrading is not immediately feasible, administrators can temporarily disable access to the bulk-secret-read endpoint via reverse proxy configurations or firewall rules until the patch is applied. Furthermore, it is advisable to audit API key permissions across all user accounts and services, ensuring that write-only keys are strictly limited in scope and monitored for anomalous activity patterns indicative of exploitation attempts.
From a standards perspective, this vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically the failure to enforce proper authorization checks based on contextual parameters such as URL paths. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, where an attacker uses legitimate credentials but exploits a flaw in how those accounts' permissions are evaluated by the system. The incident underscores the importance of rigorous input validation and context-aware access control mechanisms in web applications that support complex routing configurations like URL prefixes. Developers must ensure that authorization logic dynamically adapts to all relevant request attributes rather than relying on static, hard-coded path comparisons that may not account for deployment-specific variations.