CVE-2026-77769

MediumCVSS 6.5

Published: 21/08/2026(UTC)Updated: 26/08/2026(UTC)Translated: 21/08/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.24%

15th percentile - higher than 15% of all known CVEs

Summary

The report.list procedure in Reconmap's trpc package accepted a projectId and a dashboardId, but only verified membership for the supplied projectId, not that the dashboardId belonged to that project. An authenticated user could pair a projectId from their own organization with a dashboardId from another organization and receive every report in that dashboard. A correctly scoped helper, listReportsCore, already existed but was not used by the router.

Risk Assessment

An authenticated user can access reports from other organizations, breaking data isolation and potentially exposing sensitive information.

Recommendation

Immediately modify the router to use the listReportsCore function, which properly verifies dashboard ownership, and conduct an audit of report access.

Other vulnerabilities in Reconmap

CVE-2026-77767High
Reconmap's API applies a fallback authorization policy requiring an authenticated administrator, but the report preview action in ReportsController.cs carries [AllowAnonymous], opting out of that policy. PreviewReport loads the project and linked organisation without any authentication, membership, or role check. Because the id is an auto-increment primary key, an unauthenticated attacker can walk sequential ids to retrieve sensitive details of all projects.

Original NVD description (English source)

The report.list procedure in packages/trpc/src/routers/report.ts accepted a projectId and a dashboardId and returned getReportsByDashboardId(dashboardId). The enforceAccess middleware in packages/trpc/src/trpc.ts verified membership for the supplied projectId, but nothing verified that the supplied dashboardId belonged to that project, and getReportsByDashboardId in packages/db/src/services/reports.service.ts selects reports by dashboardId alone with no project scoping. An authenticated user could therefore pair a projectId from their own organization, which satisfies the middleware, with a dashboardId belonging to another organization and receive every report in that dashboard. A correctly scoped helper, listReportsCore, already existed in the same service file and resolves the dashboard through getDashboardById(dashboardId, projectId) before returning reports, but the router did not use it.