Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-15T15:17:18.747Z",
  "pubdate": "2026-09-15T15:17:18.747Z",
  "executiveSummary": "GeoLens versions prior to 1.2.3 are susceptible to a critical improper authorization vulnerability affecting multiple read and link API endpoints. The root cause is a failure to perform recursive or secondary authorization checks when accessing resources via relationships, map layers, VRT sources, or externalId lookups.\nThis vulnerability allows unauthenticated attackers to bypass access controls and exfiltrate sensitive data, including private dataset metadata, row-level table data, vector geometries, and raster imagery. Furthermore, authenticated users with limited privileges (editor role) can leverage internal features to mosaic and access private raster data belonging to other users.\nThe risk is severe, as the vulnerability enables the discovery of non-public infrastructure details, including filenames, source URLs, and schema information. An attacker requires only network access to the API endpoints to perform these actions; no specific administrative privileges are necessary to exploit the majority of the exposure paths. The lack of validation on HMAC-based tile URLs further compounds the risk by allowing replayable access to private spatial assets.",
  "technicalDetails": "The primary vulnerability stems from an insecure authorization design pattern where the application validates access only for the primary resource identified in the request URL, neglecting to verify the authorization context of secondary resources resolved through linked references. This logic flaw spans several subsystems, including the STAC API, OGC services, and custom dataset management endpoints.\nThe attack surface includes, but is not limited to, the following vectors:\n1. Map/Layer Exposure: GET /maps/{id} and GET /maps/{id}/style.json endpoints do not verify the visibility of private datasets referenced within a public map's style configuration. This allows an attacker to retrieve metadata, sampled values, and vector tiles. Critically, the style response provides HMAC-signed tile URLs that are not bound to specific user sessions, enabling persistent unauthorized access.\n2. Relationship Traversal: When a public dataset maintains a relationship with a private dataset, the relationship APIs fail to enforce access controls, allowing an attacker to enumerate the private target and perform raw queries against the backing table.\n3. External ID Lookups: The GET /collections/datasets/items endpoint accepts externalId dataset UUIDs without performing visibility checks, granting anonymous users the ability to query metadata for unpublished or restricted datasets.\n4. Logical Flaw in Post-Processing: Authenticated editors can manipulate VRT sources to include private raster data belonging to other users. Additionally, POST /ai/metadata/{summary,keywords,lineage,quality-statement} performs no authorization check on the user-supplied dataset_id in the request body, facilitating the unauthorized retrieval of internal metadata and sampling data.\nThe exploitation flow typically involves an attacker observing public resources (such as maps or datasets) and then manipulating the request parameters or following linked references to objects that should be restricted. Because the backend code assumes the parent request's authorization context implicitly covers all subordinate or linked data, the application returns sensitive information that remains unfiltered. This results in the disclosure of complete schema definitions, feature counts, file paths, and actual row content or raster pixels. The issue is pervasive across the application's data layer, where pre-existing 'vrt_source_links' also suffer from lack of read-time filtering, leaking member metadata and system health data to any caller capable of requesting the source definition."
}