CVE-2026-95613 in Connect
Summary
by MITRE • 11/13/2026
The pREST database REST API in Zenitel Connect firmware before 1.11.0 signs and verifies JWTs with the platform CA private key, which is stored on a data volume shared between containers, and sets the PostgreSQL session role from the unvalidated sub claim of each request while connected to the database as the "postgres" superuser, which allows local attackers who can read the platform CA private key from the container filesystem to execute database operations as the PostgreSQL superuser, including reading the master encryption key and password hashes, via a forged JWT with sub=postgres sent to the pREST API.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability in Zenitel Connect firmware prior to version 1.11.0 stems from critical misconfigurations within the pREST database REST API authentication mechanism and its interaction with the underlying PostgreSQL instance. The core technical flaw involves the use of a shared platform Certificate Authority private key for signing and verifying JSON Web Tokens across multiple containers. This architectural decision places sensitive cryptographic material on a data volume that is accessible to all containerized components, effectively negating isolation boundaries between services. When an API request arrives, the system extracts the subject claim from the JWT and directly maps it to a PostgreSQL session role without performing adequate validation or authorization checks against allowed roles. Consequently, any user capable of forging a JWT with the sub field set to postgres can impersonate the database superuser account.
This flaw allows local attackers who have gained access to the container filesystem to read the platform CA private key and subsequently forge valid authentication tokens. By sending these forged requests to the pREST API endpoint, an attacker can execute arbitrary database operations under the privileges of the postgres superuser. The operational impact is severe, as it grants unrestricted access to all data stored within the PostgreSQL instance. This includes sensitive information such as master encryption keys and user password hashes, which are critical for maintaining system integrity and confidentiality. Compromise of these assets enables further lateral movement, decryption of protected data, or complete takeover of the application infrastructure.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication due to reliance on shared secrets in an insecure manner and CWE-940 Improper Verification of Authenticated User's Role leading to privilege escalation. In terms of adversary behavior, it corresponds to ATT&CK technique T1552 Unsecured Credentials where attackers retrieve unencrypted credentials from local systems, followed by T1078 Valid Accounts for leveraging legitimate system accounts with elevated privileges. The root cause lies in the failure to implement least-privilege principles and proper separation of duties between service components.
Mitigation strategies must focus on immediate remediation through firmware updates to version 1.11.0 or later, which addresses these architectural weaknesses. In environments where patching is not immediately feasible, administrators should restrict filesystem permissions to prevent unauthorized access to the data volume containing CA keys. Additionally, implementing strict input validation for JWT claims and ensuring that database roles are mapped based on verified authorization policies rather than raw token content can reduce risk. Long-term fixes require redesigning the authentication flow to use distinct signing keys per service or a centralized identity provider with proper role-based access control enforcement at both the API and database layers.