CVE-2026-59709: Ghostfolio Authorization Bypass in Portfolio Tag Modification

Technical summary

CVE-2026-59709 affects the PUT /api/v1/portfolio/holding/:dataSource/:symbol/tags endpoint in Ghostfolio. The endpoint processes the Impersonation-Id header but fails to validate whether the authenticated user's Access.permissions field actually grants tag modification rights before applying the requested changes. An attacker with a valid read-only share token can forge or manipulate impersonation requests to assign or remove tags on holdings, bypassing the intended permission model. This is classified as a missing authorization check (CWE-862).

Business impact

Read-only portfolio shares are commonly used to grant auditors, advisors, or family members visibility into investment holdings without modification privileges. This vulnerability undermines that trust boundary. Attackers can corrupt portfolio categorization by adding misleading tags or removing legitimate ones, compromising the accuracy of portfolio reports, tax basis tracking, and investment analysis. While the vulnerability does not expose underlying portfolio data, the ability to modify metadata can degrade decision-making and create audit trail confusion.

Affected systems

Ghostfolio is affected. No specific version boundaries were disclosed in the published advisory. Organizations using Ghostfolio should immediately verify their current version against vendor advisories and patch releases to determine exposure.

Exploitability

Exploitation requires a valid read-only share token for a target portfolio, making the attack require some level of access. No user interaction is needed once the attacker possesses the token. The attack is network-based and can be performed in a low-complexity manner, though the prerequisite of having legitimate (albeit limited) portfolio access prevents this from being trivially exploitable against arbitrary targets.

Remediation

Apply the latest Ghostfolio patch that implements proper permission validation in the tag modification endpoint. The fix should ensure that the endpoint explicitly checks the Access.permissions field and denies tag operations if the authenticated user does not have modification privileges, regardless of impersonation headers. Review share token issuance practices and consider implementing shorter token expiration windows for read-only shares.

Patch guidance

Consult the Ghostfolio project's security advisories and release notes for the specific patched version. Apply updates in a staging environment first to validate portfolio functionality and ensure tag data integrity is preserved during the transition. After patching, audit recent tag modifications on shared portfolios to identify any unauthorized changes that may have occurred.

Detection guidance

Monitor API logs for PUT requests to /api/v1/portfolio/holding/*/tags endpoints originating from users with read-only role assignments. Flag requests that succeed despite the authenticated session not holding modification permissions. Implement alerting on tag changes associated with read-only share tokens or impersonation headers that do not correspond to account owners. Review tag modification audit logs for entries made by users who should only have view access.

Why prioritize this

Although the CVSS score of 4.3 reflects medium severity, the integrity impact to portfolio data and the exploitation prerequisite of existing access keep this from being critical. However, organizations with shared portfolio functionality should prioritize this patch because the attack is straightforward to execute and undermines the entire purpose of read-only access controls. The risk is particularly elevated if portfolios contain sensitive investment or tax information.

Risk score, explained

The CVSS 3.1 score of 4.3 (MEDIUM) reflects: network-accessible endpoint (AV:N), low attack complexity (AC:L), authenticated attacker requirement (PR:L), no user interaction needed (UI:N), single impact scope (S:U), no confidentiality impact (C:N), low integrity impact (I:L), and no availability impact (A:N). The score appropriately captures that the vulnerability requires prior access and does not leak sensitive data, but does allow unauthorized modification of portfolio metadata.

Frequently asked questions