Description

Reconmap's API applies a fallback authorization policy in apps/api/app/Program.cs that requires an authenticated user holding the administrator role, so controllers without their own attribute reject anonymous callers. The report preview action in apps/api/app/Controllers/ReportsController.cs carries [AllowAnonymous] and therefore opts out of that policy. PreviewReport loads the Project row named by the id path segment, loads the linked Organisation through the project's ClientId, and renders both into default-report-template.html, which prints the project name and description together with the client organisation's name, address and URL. No authentication, project membership or role check is performed. Because the id is the auto-increment primary key of the project table, an unauthenticated remote caller can walk sequential ids to retrieve the engagement details and client organisation of every project on the instance, and the 404 returned for a missing id reveals which project ids exist. Reconmap stores penetration-testing engagements, so the disclosed descriptions and client records are sensitive by nature.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-21T11:17:07.107Z",
  "pubdate": "2026-08-21T11:17:07.107Z",
  "executiveSummary": "A Broken Object Level Authorization (BOLA) or Insecure Direct Object Reference (IDOR) vulnerability exists within the Reconmap API.\nThe vulnerability affects the report preview functionality implemented in the Reconmap application, specifically impacting engagement details and client organisation records stored within the system.\nThe root cause stems from the application's global fallback authorization policy, which requires administrative privileges, being explicitly bypassed on a specific controller action via the [AllowAnonymous] attribute without implementing secondary authorization checks.\nAn unauthenticated remote attacker can exploit this flaw to read sensitive data, including project names, descriptions, client organisation names, addresses, and URLs.\nDue to the predictability of the resource identifiers, which rely on auto-incrementing integer primary keys, an attacker can perform enumeration attacks by sequentially iterating through ID values.\nFurthermore, distinct HTTP response behaviors, specifically the return of standard 404 Not Found errors for non-existent records versus valid data responses, facilitate efficient enumeration of valid project resources.\nGiven that Reconmap stores penetration-testing engagements, the exposure of these records presents severe confidentiality risks, allowing unauthorized third parties to harvest sensitive client and engagement metadata across the entire instance without any prior authentication, project membership, or specific role requirements.",
  "technicalDetails": "The vulnerability is located within the API routing and controller logic of the Reconmap application, specifically governed by the configuration in apps/api/app/Program.cs and the implementation in apps/api/app/Controllers/ReportsController.cs.\nIn apps/api/app/Program.cs, the API establishes a default fallback authorization policy enforcing that incoming requests originate from an authenticated user holding the administrator role. Consequently, API controllers lacking explicit authorization attributes automatically inherit this strict policy and reject anonymous callers.\nHowever, the report preview action defined inside apps/api/app/Controllers/ReportsController.cs is explicitly decorated with the [AllowAnonymous] attribute. This attribute overrides the global fallback authorization policy, permitting unauthenticated requests to access the endpoint without validating user sessions, tokens, or role assignments.\nWithin the vulnerable PreviewReport function, the application parses an id parameter provided via the URI path segment. This id directly represents the auto-increment primary key of the project database table. The function proceeds to load the corresponding Project row from the database using this integer identifier, retrieves the linked Organisation record through the project's ClientId foreign key, and injects both entities into default-report-template.html for rendering.\nCrucially, the PreviewReport method fails to perform any authorization checks to verify whether the requesting entity possesses membership within the targeted project or holds sufficient administrative privileges.\nBecause the project identifiers are auto-incrementing sequential integers, the attack flow relies on enumeration. An unauthenticated remote attacker can craft an automated script to systematically request sequential id values (e.g., /api/reports/preview/1, /api/reports/preview/2, etc.).\nAs the application processes these requests, successful iterations return rendered report previews containing proprietary penetration-testing engagement metadata and sensitive client PII, including organisation names, physical addresses, and target URLs.\nIn cases where an iterated id does not correspond to an existing database record, the application responds with a 404 Not Found status code. This differential response behavior serves as an oracle, allowing the attacker to map out the exact bounds of valid project identifiers present on the server instance.\nThe network exposure of this endpoint is public-facing, requiring no prior authentication or specialized client-side payloads beyond standard HTTP GET requests targeting the vulnerable route.\nThe resulting impact includes total confidentiality breach of stored penetration-testing engagements and associated client records, exposing sensitive internal security assessments and client portfolios to unauthorized external actors."
}