CVE-2026-57449 in Actual
Summary
by MITRE • 09/26/2026
Actual is a local-first personal finance tool. Prior to 26.7.0, Actual Sync Server's CORS proxy is intended to let authenticated users fetch resources only from repositories listed in the official plugin allowlist. When `ACTUAL_GITHUB_TOKEN` is configured, the proxy automatically attaches the server's GitHub token to GitHub requests. The GitHub API allowlist check uses a raw `startsWith()` prefix test for `/repos/{owner}/{repo}` without requiring a path boundary after the repository name. If an allowlisted public plugin repository is `https://github.com/acme/plugin`, the proxy also accepts GitHub API URLs. Those URLs are outside the allowlisted repository but still pass because their API path starts with `/repos/acme/plugin`. The proxy then forwards the request with the server's `ACTUAL_GITHUB_TOKEN`, allowing any authenticated Actual user to read private GitHub resources reachable by that token. Version 26.7.0 fixes the issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Actual Sync Server prior to version 26.7.0 represents a critical authorization bypass stemming from an insufficient validation of Uniform Resource Locators within the CORS proxy mechanism. This component is designed to facilitate authenticated users fetching resources exclusively from repositories that have been explicitly added to an official plugin allowlist, thereby enforcing a strict boundary on external data access. The security architecture relies heavily on the assumption that matching repository names guarantees safe access only to public or permitted content, but this logic fails due to a flawed string comparison implementation in the GitHub API path validation routine.
The technical root cause lies in the use of a raw startsWith prefix check for paths beginning with /repos/{owner}/{repo}. When an administrator configures the ACTUAL_GITHUB_TOKEN environment variable, the server automatically attaches this token to outgoing requests directed at GitHub endpoints. The allowlist verification process checks if the requested URL path begins with the string corresponding to an allowed repository, such as /repos/acme/plugin. However, because the validation does not enforce a strict path boundary or delimiter after the repository name, it incorrectly accepts URLs that extend beyond the intended scope. For instance, GitHub API endpoints like /repos/acme/plugin/actions/runs are structurally distinct from the actual code repository but share the same initial prefix. Consequently, these API paths pass the allowlist check despite being outside the permitted set of resources.
This flaw results in a severe information disclosure vulnerability where any authenticated user of the Actual Sync Server can exploit this misconfiguration to read private GitHub resources accessible by the server's configured token. By crafting requests that target sensitive endpoints such as workflow runs, secrets, or internal issue trackers under an allowlisted organization name, attackers can bypass intended access controls and extract confidential data. The impact is compounded by the fact that the request carries the high-privilege ACTUAL_GITHUB_TOKEN, effectively elevating a standard authenticated user's capabilities to those of the server itself for any resource reachable via that token within the matched prefix scope.
From an industry standards perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Site 'Open Redirect'. The failure to validate path boundaries is a classic example of insufficient input validation leading to unauthorized access. In terms of the MITRE ATT&CK framework, this behavior facilitates Data from Information Repositories (T1530) by allowing adversaries to harvest sensitive data from external sources using stolen or misconfigured credentials. It also reflects aspects of Improper Restriction of XML External Entity References if similar parsing logic were applied elsewhere, but primarily it is a direct access control failure where the system trusts user-supplied input without rigorous structural verification.
To mitigate this vulnerability and prevent future occurrences, developers must implement strict path validation that ensures exact matches or requires explicit delimiters after repository names to distinguish between resource paths and API endpoints. Utilizing standardized URL parsing libraries rather than raw string operations can help enforce proper boundary checks. Additionally, the principle of least privilege should be applied by restricting the ACTUAL_GITHUB_TOKEN permissions to only those scopes absolutely necessary for plugin functionality, thereby limiting the blast radius if such a bypass is attempted in other contexts. Upgrading to version 26.7.0 or later resolves this issue by correcting the allowlist logic to properly enforce path boundaries and prevent unauthorized access to private resources.