CyberSecBulletin
CVE-2026-55178NVD status: Deferred

geolens: Exposure of Sensitive Information to an Unauthorized Actor

Published Updated By the CyberSecBulletin desk

CVE-2026-55178 is a high-severity exposure of sensitive information to an unauthorized actor vulnerability in geolens from Geolens-io, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. Affected geolens versions: < 1.2.3. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.65% chance of exploitation within 30 days, higher than 52% of scored CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Check which version of geolens you run against the affected versions below, and install the vendor's latest release.
  2. Read the advisory on github.com for workarounds and exact fixed builds.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
Geolens-iogeolens< 1.2.3Not stated

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
NoneNothing can be modified.
Availability
NoneAvailability is not affected.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Scored by CNA (github.com).

Official 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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

How developers prevent this class of flaw

  • Compartmentalize the system to have safe areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

More Exposure of Sensitive Information to an Unauthorized Actor vulnerabilities (CWE-200)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Exposure of Sensitive Information to an Unauthorized Actor vulnerabilities

Spotted an error? Tell us.