CVE-2026-46700 in actual
Summary
by MITRE • 07/08/2026
Actual is a local-first personal finance tool. Prior to 26.6.0, the GET /secret/:name endpoint in @actual-app/sync-server checks only that the caller has a valid session and does not verify the caller is an admin, while the sibling POST /secret/ handler enforces an admin check in OpenID mode. Any authenticated non-admin BASIC user in OpenID multi-user deployments can probe the secrets store and learn which admin-managed bank-sync integrations have been configured, including simplefin_accessKey, pluggyai_clientSecret, pluggyai_itemIds, and the gocardless secrets. This issue is fixed in version 26.6.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/08/2026
The vulnerability under discussion affects Actual, a local-first personal finance tool that operates in OpenID multi-user deployments. This security flaw exists in versions prior to 26.6.0 within the @actual-app/sync-server component where the GET /secret/:name endpoint fails to properly authenticate administrative privileges despite requiring a valid session. The inconsistency arises from the fact that while the POST /secret/ endpoint correctly enforces admin verification in OpenID mode, the GET endpoint only validates session legitimacy without confirming administrative status. This discrepancy creates a privilege escalation vector that allows authenticated non-admin users to access sensitive configuration data through direct probing of the secrets store.
The technical implementation of this vulnerability stems from an incomplete authorization check pattern within the sync-server's authentication flow. The GET endpoint performs basic session validation but omits the critical admin role verification that should accompany access to administrative resources. This represents a classic authorization bypass weakness where the system assumes that any authenticated user with a valid session should be able to access certain endpoints without proper privilege validation. The flaw aligns with CWE-285, which addresses improper authorization in software systems, and demonstrates how inconsistent security checks can create exploitable gaps even when basic authentication mechanisms function correctly.
The operational impact of this vulnerability in OpenID multi-user environments is significant for organizations relying on Actual for financial data management. Non-admin users can discover administrative bank-sync integration configurations including sensitive credentials such as simplefin_accessKey, pluggyai_clientSecret, pluggyai_itemIds, and gocardless secrets. This exposure creates potential attack surface expansion where unauthorized individuals gain knowledge of legitimate integration points that could be leveraged for further exploitation. The information disclosure affects the confidentiality aspect of the CIA triad by revealing administrative configuration details that should remain restricted to authorized personnel only.
Organizations using Actual in multi-user OpenID deployments face immediate security implications from this vulnerability, particularly those handling sensitive financial data where the exposure of integration secrets could enable attackers to compromise third-party banking connections. The issue represents a failure in the principle of least privilege where users receive access beyond their intended administrative boundaries. Mitigation strategies should include upgrading to version 26.6.0 which implements proper admin verification for the GET /secret/:name endpoint, along with implementing comprehensive access logging and monitoring for secret store interactions. Security teams should also consider conducting privilege audits to ensure that only authorized personnel maintain administrative access to financial integration configurations.
From an ATT&CK framework perspective, this vulnerability maps to T1566.002 (Phishing: Spearphishing Attachments) and T1078.004 (Valid Accounts: Cloud Accounts) as attackers could potentially use the exposed secrets to gain unauthorized access to banking services through compromised integration points. The vulnerability also aligns with T1213.002 (Data from Information Repositories: Databases) as it enables unauthorized access to stored administrative configuration data. Organizations should implement network segmentation and privilege management controls to limit access to sensitive endpoints while ensuring proper audit trails exist for all secret store interactions.
The fix implemented in version 26.6.0 addresses the root cause by synchronizing the authorization requirements between GET and POST endpoints, ensuring that both require proper admin verification in OpenID mode deployments. This correction establishes consistent security controls across the API surface area and prevents unauthorized information disclosure. Security teams should validate that the upgrade properly enforces admin checks and verify that no other similar inconsistencies exist within the application's authorization framework. Regular security assessments of authentication and authorization mechanisms remain essential to prevent similar vulnerabilities from emerging in future releases.