CVE-2026-77767 in Reconmapinfo

Summary

by MITRE • 08/21/2026

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.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 08/21/2026

The vulnerability identified in Reconmap represents a critical failure in access control logic within its API layer, specifically stemming from an improper implementation of fallback authorization policies. The application is designed to enforce strict authentication requirements for most endpoints, mandating that users possess the administrator role to interact with sensitive resources. However, this security posture is undermined by specific controller configurations that inadvertently bypass these safeguards. In particular, the ReportsController contains a PreviewReport action method decorated with an AllowAnonymous attribute. This explicit directive instructs the framework to skip authentication and authorization checks for any requests directed at this endpoint, creating a significant gap in the application's defense-in-depth strategy where sensitive data can be accessed without valid credentials or proper user context.

From a technical perspective, the flaw lies in how the PreviewReport method processes incoming requests. When an unauthenticated caller provides a project identifier via the URL path segment, the system retrieves the corresponding Project record from the database using this auto-increment primary key. It then fetches associated organizational data linked through the ClientId field and renders both entities into a default report template. This process results in the exposure of detailed engagement information, including the project name, description, and comprehensive client organization details such as names, physical addresses, and web URLs. Crucially, there are no checks to verify if the requester has any relationship with the project or possesses the necessary permissions to view this data. The reliance on sequential integer identifiers for primary keys further exacerbates the issue by allowing attackers to easily enumerate valid resources through simple iteration of identifier values.

The operational impact of this vulnerability is severe due to the sensitive nature of the data involved. Reconmap serves as a platform for managing penetration testing engagements, which inherently contain confidential information about an organization's security posture and infrastructure vulnerabilities. The unauthorized disclosure of project descriptions and client organizational records can lead to significant reputational damage, legal liabilities, and strategic disadvantages for affected clients. Attackers can systematically crawl through sequential IDs to harvest data from every active engagement on the instance. Furthermore, the application’s behavior of returning a 404 status code for non-existent identifiers inadvertently aids attackers in enumerating valid project IDs, as they can distinguish between missing records and successful retrievals based on response codes or content differences.

This vulnerability aligns with CWE-285, which describes Improper Authorization, specifically illustrating how explicit overrides of security policies can lead to unauthorized access when not carefully managed. It also maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as it allows unauthenticated users to effectively bypass authentication mechanisms and access resources intended for authorized personnel only. The ability to enumerate identifiers via sequential ID probing relates to CWE-203, Observable Discrepanancy in Response, which facilitates further reconnaissance activities.

To mitigate this risk, immediate remediation is required by removing the AllowAnonymous attribute from the PreviewReport action or implementing granular authorization checks that verify user ownership or administrative privileges before rendering sensitive data. Additionally, relying on auto-incrementing integer primary keys for public-facing resources should be avoided; instead, using non-sequential identifiers such as UUIDs can prevent enumeration attacks based on ID guessing. Implementing consistent fallback authorization policies across all controllers and ensuring that no endpoint inadvertently opts out of security checks without rigorous review is essential to maintaining the integrity of the application's access control framework.

Responsible

VulnCheck

Reservation

08/21/2026

Disclosure

08/21/2026

Moderation

accepted

CPE

ready

EPSS

0.00361

KEV

no

Activities

low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!