CVE-2026-55178 in GeoLens
Summary
by MITRE • 09/15/2026
GeoLens is a self-hosted geospatial data catalog with semantic search, OGC and STAC APIs, and a map builder. Prior to 1.2.3, multiple read and link endpoints authorize only the resource named in the request URL and fail to re-authorize a second caller-influenced dataset reached through a relationship, map layer, VRT source, externalId lookup, or request body. When a public map references a private dataset, anonymous callers can use GET /maps/{id} and GET /maps/{id}/style.json to obtain the private layer's metadata, sampled values, or vector tiles. The style response can expose a replayable HMAC tile URL that is bound to neither a user nor a map. When a public source dataset has a relationship to a private target dataset, anonymous callers can use the dataset relationship APIs to enumerate the relationship and read rows from the private target's backing table. Anonymous callers can also use GET /collections/datasets/items with an externalId dataset UUID to obtain metadata for any private, restricted, or unpublished dataset because that lookup performs no visibility check. Authenticated users with the default editor role can mosaic another user's private raster into an owned VRT and read its pixels, and POST /ai/metadata/{summary,keywords,lineage,quality-statement} accepts a body-controlled dataset_id without a visibility check and returns private metadata and sample values. Pre-existing vrt_source_links also expose unauthorized member metadata and health unless each member is filtered at read time. These paths can disclose vector geometries and attributes, raster pixels, table rows, table names, column schemas, feature counts, extents, source URLs and filenames, contacts, and sampled row values. This issue is fixed in version 1.2.3.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
GeoLens is a self-hosted geospatial data catalog that provides semantic search capabilities along with Open Geospatial Consortium (OGC) and SpatioTemporal Asset Catalog (STAC) APIs, as well as an integrated map builder functionality. In versions prior to 1.2.3, the application suffers from multiple broken access control vulnerabilities stemming from a fundamental flaw in its authorization logic. The core issue lies in the failure of several read and link endpoints to re-authorize secondary resources that are reached through relationships or indirect references. While the initial request URL may specify a resource accessible to the caller, the system fails to validate permissions for any subsequent dataset accessed via a relationship, map layer configuration, Virtual Vector Tile (VRT) source, external identifier lookup, or data provided in the request body. This architectural oversight allows attackers to bypass intended visibility restrictions by leveraging these indirect pathways to access sensitive geospatial information that should remain private or restricted.
The operational impact of this vulnerability is severe for users relying on GeoLens to manage confidential datasets. When a public map references a private dataset, anonymous callers can exploit endpoints such as GET /maps/{id} and GET /maps/{id}/style.json to retrieve the metadata associated with the private layer. Beyond mere metadata disclosure, these requests allow attackers to obtain sampled values or vector tiles from data that is not intended for public consumption. Furthermore, the style response may expose a replayable HMAC tile URL which is bound neither to a specific user nor to a particular map instance. This means that once obtained, such URLs can be reused indefinitely by unauthorized parties to access sensitive raster imagery without further authentication checks.
In scenarios where a publicly accessible source dataset has an established relationship with a private target dataset, the vulnerability enables enumeration and data exfiltration through dataset relationship APIs. Anonymous attackers can traverse these relationships to discover hidden datasets and subsequently read rows directly from the backing database table of the private target. Additionally, the endpoint GET /collections/datasets/items allows for unauthorized access when supplied with an externalId corresponding to a private, restricted, or unpublished dataset UUID. This specific lookup mechanism performs no visibility check, effectively allowing any user to retrieve metadata for datasets they should not be able to see simply by knowing or guessing the unique identifier.
The vulnerability extends beyond anonymous access and also affects authenticated users operating under default roles. Users with the editor role can exploit this flaw to mosaic another user's private raster data into a Virtual Vector Tile source that they own, thereby gaining read access to its pixel values. Similarly, the POST /ai/metadata/{summary,keywords,lineage,quality-statement} endpoint accepts a dataset_id controlled by the request body without performing any visibility verification. This allows attackers to inject identifiers of restricted datasets and retrieve their private metadata along with sampled row values. Pre-existing vrt_source_links also expose unauthorized member metadata and health status unless each member is explicitly filtered at read time, further expanding the attack surface for information disclosure.
The scope of data exposure resulting from these flaws is extensive. Attackers can disclose vector geometries and attributes, raster pixel data, database table rows, table names, column schemas, feature counts, spatial extents, source URLs, filenames, contact information, and sampled row values. This level of detail provides a comprehensive view of the underlying geospatial infrastructure and sensitive business or scientific data contained within the catalog. The vulnerability is classified under CWE-284 Improper Access Control as it involves failing to enforce proper restrictions on authenticated users' access to resources. From an ATT&CK perspective, this behavior aligns with T1078 Valid Accounts for initial access if exploited by authenticated users and T1530 Data from Cloud Storage Object Discovery or T1213 Data from Information Repositories when enumerating and extracting data through indirect paths.
To mitigate these risks, organizations using GeoLens must upgrade to version 1.2.3 immediately, as this release addresses the authorization flaws by implementing rigorous re-authorization checks for all indirectly accessed resources. Administrators should also review their current configurations to ensure that no legacy VRT source links or map layers expose sensitive data through unfiltered relationships. Regular security audits focusing on access control logic in API endpoints are recommended to prevent similar issues where indirect references bypass primary permission checks. Ensuring that every step of a multi-hop resource traversal validates the caller's permissions against the specific target resource is critical for maintaining the confidentiality and integrity of geospatial datasets managed by such platforms.