CVE-2026-28685: 
PHP vulnerability analysis and mitigation

CVE-2026-28685 is an Insecure Direct Object Reference (IDOR) / improper authorization vulnerability in Kimai, a web-based multi-user time-tracking application. The GET /api/invoices/{id} API endpoint checks only the role-based view_invoice permission without verifying that the requesting user has access to the invoice's associated customer, allowing any user with ROLE_TEAMLEAD to read all invoices system-wide. All versions up to and including 2.50.0 are affected; the issue was patched in version 2.51.0, released March 1, 2026. The vulnerability was disclosed on March 4, 2026, and has a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is an incomplete authorization check (CWE-285: Improper Authorization; CWE-862: Missing Authorization) in src/API/InvoiceController.php. The API endpoint uses Symfony's #[IsGranted('view_invoice')] attribute, which only validates the user's role, but omits the customer-level access expression #[IsGranted(new Expression("is_granted('access', subject.getCustomer())"), 'invoice')] that is correctly applied in the web controller (src/Controller/InvoiceController.php). Because the API endpoint resolves the invoice object via Symfony's ParamConverter directly from the URL parameter {id}, any authenticated teamlead can supply an arbitrary invoice ID and receive a 200 OK response with full invoice data, bypassing the CustomerVoter team-membership check entirely. A concrete PoC using a simple curl command with a bearer token was included in the advisory (GitHub Advisory, Patch Commit).

Successful exploitation allows any authenticated user with ROLE_TEAMLEAD to read all invoices across the entire Kimai instance, regardless of team assignment. Invoice records typically contain sensitive financial data including invoice numbers, totals, currency, customer names, and payment terms. In multi-team deployments, this completely breaks the intended data isolation between teams, exposing confidential business and financial information of customers belonging to other teams. There is no integrity or availability impact; the vulnerability is limited to unauthorized data disclosure (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub security advisory, consisting of a runnable curl command that demonstrates unauthorized invoice access using a valid bearer token. Exploitation requires only a low-privilege authenticated account with ROLE_TEAMLEAD and network access to the Kimai API. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.027% (0.000270), indicating a low probability of near-term exploitation (GitHub Advisory, Feedly).

1. Obtain credentials: Acquire or possess valid Kimai credentials for an account with ROLE_TEAMLEAD assigned to any team in the target instance.
2. Authenticate and retrieve API token: Log in to the Kimai instance and obtain a valid API bearer token for the teamlead account.
3. Enumerate invoice IDs: Optionally use GET /api/invoices (the list endpoint) to discover invoice IDs accessible to the attacker's team, or simply iterate integer IDs starting from 1.
4. Access unauthorized invoices: Send a crafted HTTP GET request to the API endpoint with an invoice ID belonging to a different team's customer:

curl -H "Authorization: Bearer BOB_TOKEN" http://<kimai-host>/api/invoices/1

5. Harvest financial data: Parse the 200 OK JSON response to extract sensitive invoice details (invoice number, total, currency, customer name, payment terms) for customers the attacker should not have access to (GitHub Advisory).

• Network: Repeated or sequential GET requests to /api/invoices/{id} with incrementing or non-sequential integer IDs from a single authenticated user, particularly across invoice IDs not associated with the user's assigned team.
• Logs: Kimai API access logs showing a ROLE_TEAMLEAD user successfully retrieving (HTTP 200) invoices for customers outside their team scope; unusual volume of /api/invoices/ GET requests from a single API token.
• Application Behavior: A teamlead user accessing invoice records for customers not assigned to any of their teams, which would not normally be possible through the web UI.

Upgrade Kimai to version 2.51.0 or later, which adds the missing customer-level authorization check (#[IsGranted(new Expression("is_granted('access', subject.getCustomer())"), 'invoice')]) to the GET /api/invoices/{id} API endpoint (Kimai Release, Patch Commit). As a temporary workaround prior to patching, restrict ROLE_TEAMLEAD assignment to only users who strictly require it, and consider blocking external access to the /api/invoices/ endpoint via network controls or a web application firewall if API access is not required from untrusted networks. Upgrading to 2.51.0 is the only complete remediation.

The vulnerability was reported by security researcher CE2Sec and credited in the Kimai 2.51.0 release notes. The advisory was published by project maintainer kevinpapst on March 4, 2026, with a prompt patch released the same week. No significant broader media coverage or notable community controversy has been identified beyond standard CVE tracking and aggregation sites (GitHub Advisory, Kimai Release).