GHSA-5Q8V-J673-M5V4: Insecure Direct Object Reference and Authorization Bypass in Firefly III API

Firefly III is an open-source financial management application that exposes a RESTful API for system administration and user management. The vulnerability, tracked as GHSA-5Q8V-J673-M5V4, affects the API endpoints responsible for handling user data retrieval. This defect resides within the UserController component, specifically the endpoints handling index and show operations.

The vulnerability is classified as an Insecure Direct Object Reference (IDOR) and an Improper Authorization flaw (CWE-863). The core issue manifests as a failure to enforce role-based access controls on specific API endpoints. The system relies on the auth:api middleware to ensure requests are authenticated but neglects to apply secondary authorization checks to verify if the requesting user holds the necessary administrative privileges.

Any authenticated user, regardless of their designated role, possesses the ability to interact with the vulnerable endpoints. This lack of restriction allows standard users to query the user management API and extract information about all registered accounts within the Firefly III instance. The exposure includes metadata such as email addresses, role assignments, and account status indicators.

The vulnerability affects Firefly III versions 6.4.23 through 6.5.0. Systems deployed via the grumpydictator/firefly-iii Packagist package within this version range expose this attack surface to all registered users. The vendor addressed the flaw in version 6.5.1 by introducing explicit ownership and role checks within the affected controller logic.

The root cause of GHSA-5Q8V-J673-M5V4 is an inconsistent implementation of authorization controls within app/Http/Controllers/Api/V1/UserController.php. Firefly III implements a role-based access control (RBAC) model where administrative actions require the owner role. However, the application developers did not uniformly apply these role checks across all user management methods.

The UserController class processes incoming API requests for user data. Methods responsible for mutating data, such as creating or deleting users, correctly verify the requester's role before processing the instruction. In contrast, the methods responsible for reading data, specifically index() at approximately line 94 and show() at line 126, omit these critical authorization validations entirely.

The routing configuration defined in routes/api.php further compounds the controller-level omissions. The route group for user management utilizes the auth:api middleware, which exclusively verifies the presence of a valid authentication token. The configuration lacks an intermediate middleware layer, such as an admin or owner gate, to evaluate the specific permissions associated with the authenticated token prior to routing the request to the controller.

Triggering the vulnerability requires a single condition: the attacker must possess a valid Bearer token for any standard user account. When the application receives a request to the /api/v1/users endpoints, the auth:api middleware authenticates the token and passes the request to the UserController. Because the index() and show() methods execute their database queries without inspecting the user's role context, the application returns the requested data unconditionally.

Analysis of the UserController.php file reveals the absence of authorization gates in the vulnerable versions. The original show() method accepts a User model instance injected by the framework's route model binding. The method directly returns the serialized user data without evaluating whether the authenticated user context matches the requested user ID or holds elevated privileges.

The vulnerable implementation of the show method executes as follows:

public function show(User $user): JsonResponse
{
    // Vulnerable: Returns user data without authorization checks
    return response()->json(new UserResource($user));
}

This implementation assumes the routing layer handles authorization, which is incorrect in this architectural configuration. The index() method suffers from the exact same structural deficiency, retrieving all rows from the user database table and mapping them to a JSON resource collection.

The fix, introduced in commit 26c6985c742593d081f8b58450f463a584a4203a, implements an explicit authorization gate directly within the controller methods. The patch leverages the auth()->user() helper to inspect the requester's role and identity. The validation logic mandates that the requester must either possess the owner role or the requested user_id must match the authenticated user's ID.

The patched code resolves the vulnerability by introducing a conditional check that throws an exception if the authorization requirements fail:

public function show(User $user): JsonResponse
{
    // Fix: Verify if the authenticated user is an owner or requesting their own data
    if (!auth()->user()->hasRole('owner') && auth()->id() !== $user->id) {
        throw new FireflyException('200025: No access to function.');
    }
    return response()->json(new UserResource($user));
}

This logical structure ensures that standard users receive a designated exception when attempting to access unauthorized records.

Exploitation of GHSA-5Q8V-J673-M5V4 relies on standard API interaction tools and requires minimal technical sophistication. The primary prerequisite is active authentication; the attacker must hold a valid account on the target Firefly III instance and obtain a valid API Bearer token. No specific network positioning is required beyond HTTP access to the application's external interfaces.

To enumerate all users on the platform, an attacker transmits an HTTP GET request to the /api/v1/users endpoint. The request must include the Authorization header populated with the attacker's Bearer token. The server processes this request and responds with a JSON array containing the user records for the entire instance.

A functional proof-of-concept for the enumeration attack uses standard command-line tools:

curl -H "Authorization: Bearer <any_user_token>" https://<instance_url>/api/v1/users

The response payload exposes internal system identifiers for each user, which facilitates targeted extraction.

Attackers extract data for a specific individual by appending the target's internal identifier to the API route. Using the data harvested from the enumeration phase, the attacker issues a GET request to /api/v1/users/<user_id>. The server returns a structured JSON object detailing the targeted user's attributes, ignoring the permission mismatch.

The exploitation of this vulnerability results in direct information disclosure affecting all user accounts on the vulnerable instance. While the vulnerability does not permit data modification or arbitrary code execution, it exposes sensitive account metadata. The disclosed records include full email addresses, role assignments, account creation timestamps, and active block statuses.

The exposure of email addresses and role assignments presents a significant risk for secondary attacks. Attackers utilize this information to identify accounts holding the owner role. This enables highly targeted spear-phishing campaigns or credential stuffing attacks directed specifically at the instance administrators.

The vulnerability carries a CVSS v4.0 base score of 5.7, evaluated under the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P. This metric reflects the network attack vector, the requirement for low-privileged authentication, and the high impact on data confidentiality. The structural integrity and availability of the application remain unaffected.

The categorization of this flaw under CWE-863 (Incorrect Authorization) underscores the risk of decentralized access control logic. The failure to enforce authorization boundaries allows horizontal and vertical privilege escalation in the context of data visibility. Organizations hosting multi-user Firefly III environments face the highest exposure.

The primary and most effective remediation strategy is to upgrade the Firefly III installation to version 6.5.1 or a subsequent release. This version incorporates the authorization checks within the UserController to validate the requester's role. Administrators utilizing Composer to manage dependencies must update the grumpydictator/firefly-iii package explicitly.

Organizations unable to execute an immediate application upgrade can implement temporary mitigations at the infrastructure level. Reverse proxies or Web Application Firewalls (WAF) can intercept and evaluate traffic directed at the /api/v1/users endpoints. Administrators can configure these tools to enforce strict IP allowlisting for these specific administrative routes.

Developers maintaining forks or custom distributions of Firefly III must manually backport the authorization logic. The required modifications involve injecting role verification guards into all data retrieval methods within the user management controllers. The verification must confirm either an owner role assignment or a precise match between the requester's identity and the target resource.

Security teams should proactively audit application logs to identify historical exploitation attempts. Defenders should search access logs for high-frequency GET requests targeting the /api/v1/users and /api/v1/users/* endpoints originating from non-administrative IP addresses or user accounts. Abnormal patterns of data egress from these API routes serve as indicators of compromise.