GHSA-p77j-g7h5-r2vw: GeoLens: authz flaws leak private geospatial data

GHSA-p77j-g7h5-r2vw HIGH
Published August 19, 2026
CISO Take

GeoLens 1.2.4 fixes a chain of ten flaws, the worst of which let any authenticated — and in the caching case, unauthenticated — user pull private dataset metadata, PII, and tile imagery they were never authorized to see, plus a DNS-rebinding SSRF that can reach internal or cloud metadata endpoints. With 2,899 downstream dependents and an OpenSSF Scorecard of just 6.2/10, this geospatial data catalog sits in a lot of pipelines that likely feed training data or map-based context into ML/GIS workloads, so the blast radius of a silent data leak is real even though there's no published CVSS score, no EPSS percentile, no CISA KEV listing, and no public exploit or Nuclei template yet. Treat it as high-priority patching rather than emergency response: none of the authorization or cache-disclosure issues have a workaround, so upgrade to 1.2.4 now, set ENVIRONMENT=production explicitly, rotate any tokens that may have leaked via process environment or proxy access logs, and add egress filtering to block outbound requests to link-local/metadata addresses as a compensating control for the SSRF path.

Sources: GitHub Advisory CISA KEV OpenSSF ATLAS

What is the risk?

High severity per the vendor advisory, but exploitability signals are muted for now: no CVSS vector, no EPSS score, not in CISA KEV, no public PoC or Nuclei template. The real risk driver is breadth and ease — several of the flaws (record/keyword/distribution disclosure, map visibility enumeration) require only a standard authenticated account and no special AI/ML knowledge, and one (the shared-cache tile leak) needs no authentication at all. Combined with a mediocre OpenSSF Scorecard (6.2/10), 9 prior CVEs in the same package, and 2,899 downstream dependents, this should be prioritized as a high-confidence, low-complexity data-exposure risk even absent active exploitation telemetry.

How does the attack unfold?

Initial Access
Adversary obtains a standard low-privilege authenticated account, or reaches the public-facing service directly for the unauthenticated cache-replay and SSRF paths.
AML.T0049
Authorization Bypass
Adversary calls record/keyword/distribution or map-visibility endpoints by ID without the backing dataset being re-authorized, exposing private metadata and PII.
AML.T0036
Data & Credential Collection
Adversary replays publicly-cached private tile URLs and harvests leaked authorization tokens from GDAL subprocess environment or proxy access logs.
AML.T0055
Impact / Lateral Pivot
Exposed PII, proprietary geospatial datasets, and (via DNS-rebinding SSRF) internal or cloud metadata service credentials enable data theft and potential pivot into the surrounding ML infrastructure.
AML.T0025

What systems are affected?

Package Ecosystem Vulnerable Range Patched
HF Datasets pip < 1.2.4 1.2.4
21.8K OpenSSF 6.2 2.9K dependents Pushed 7d ago 85% patched ~6d to patch Full package profile →

Do you use HF Datasets? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. Upgrade to GeoLens 1.2.4 — mandatory for the authorization and cache-disclosure issues, which have no workaround. Explicitly set ENVIRONMENT=production on public, TLS-terminated deployments so the Secure cookie flag and /docs exposure are enforced regardless of the LOG_JSON logging setting. Add network-layer egress filtering to block outbound requests to link-local/cloud metadata addresses (169.254.169.254 and equivalents) as a compensating control for the SSRF path, and rate/size-limit POST /search at the proxy layer. Rotate any authorization tokens that may have leaked via GDAL subprocess environment exposure (/proc/<pid>/environ) or reverse-proxy access logs containing api_key query parameters, and audit those logs for unexpected access patterns to private record/tile endpoints predating the patch. Reset database and admin passwords on any installation performed via the installer's headless mode, since defaults may have silently persisted.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 10 - Data and Data Governance
ISO 42001
Annex A.7.2 - Data for AI Systems
NIST AI RMF
MEASURE 2.7 - AI System Security and Resilience
OWASP LLM Top 10
LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is GHSA-p77j-g7h5-r2vw?

GeoLens 1.2.4 fixes a chain of ten flaws, the worst of which let any authenticated — and in the caching case, unauthenticated — user pull private dataset metadata, PII, and tile imagery they were never authorized to see, plus a DNS-rebinding SSRF that can reach internal or cloud metadata endpoints. With 2,899 downstream dependents and an OpenSSF Scorecard of just 6.2/10, this geospatial data catalog sits in a lot of pipelines that likely feed training data or map-based context into ML/GIS workloads, so the blast radius of a silent data leak is real even though there's no published CVSS score, no EPSS percentile, no CISA KEV listing, and no public exploit or Nuclei template yet. Treat it as high-priority patching rather than emergency response: none of the authorization or cache-disclosure issues have a workaround, so upgrade to 1.2.4 now, set ENVIRONMENT=production explicitly, rotate any tokens that may have leaked via process environment or proxy access logs, and add egress filtering to block outbound requests to link-local/metadata addresses as a compensating control for the SSRF path.

Is GHSA-p77j-g7h5-r2vw actively exploited?

No confirmed active exploitation of GHSA-p77j-g7h5-r2vw has been reported, but organizations should still patch proactively.

How to fix GHSA-p77j-g7h5-r2vw?

Upgrade to GeoLens 1.2.4 — mandatory for the authorization and cache-disclosure issues, which have no workaround. Explicitly set ENVIRONMENT=production on public, TLS-terminated deployments so the Secure cookie flag and /docs exposure are enforced regardless of the LOG_JSON logging setting. Add network-layer egress filtering to block outbound requests to link-local/cloud metadata addresses (169.254.169.254 and equivalents) as a compensating control for the SSRF path, and rate/size-limit POST /search at the proxy layer. Rotate any authorization tokens that may have leaked via GDAL subprocess environment exposure (/proc/<pid>/environ) or reverse-proxy access logs containing api_key query parameters, and audit those logs for unexpected access patterns to private record/tile endpoints predating the patch. Reset database and admin passwords on any installation performed via the installer's headless mode, since defaults may have silently persisted.

What systems are affected by GHSA-p77j-g7h5-r2vw?

This vulnerability affects the following AI/ML architecture patterns: training data pipelines, RAG pipelines, data cataloging / ingestion pipelines.

What is the CVSS score for GHSA-p77j-g7h5-r2vw?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

training data pipelinesRAG pipelinesdata cataloging / ingestion pipelines

MITRE ATLAS Techniques

AML.T0002.000 Datasets
AML.T0036 Data from Information Repositories
AML.T0049 Exploit Public-Facing Application
AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 10
ISO 42001: Annex A.7.2
NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access. ### Impact - **Private record metadata disclosure.** Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record's contact details (PII), keywords, and distributions. (Runtime-proven.) - **Private tile data via shared caches.** Private raster and vector tiles were served with shared-cache (`Cache-Control: public`) headers, so a shared cache (a CDN or the bundled reverse proxy) could retain private tile bytes and replay them to later unauthenticated requests, including unpublished public-dataset previews. - **Private dataset title enumeration.** The map visibility-check endpoint did not authorize read access to the map, allowing any editor to enumerate the titles of non-public datasets in any map by ID — including private maps owned by other users. - **SSRF via DNS rebinding.** URL validation for user-supplied service URLs (probes, STAC/OGC API sources, manifest downloads) resolved DNS once and then let the HTTP client re-resolve at connect time, allowing a low-TTL domain to pass validation as a public address and connect to an internal/metadata address. - **Token leak + header injection in service preview.** The remote-service preview path passed the authorization token to GDAL via the process environment without sanitization, leaking it through `/proc/<pid>/environ` and allowing CRLF header injection. - **Unauthenticated STAC search DoS.** `POST /search` did not cap the size of GeoJSON `intersects` geometries (the `GET` sibling did). - **API key written to access logs.** The bundled reverse proxy logged the `api_key` query-string credential in cleartext. - **Security posture coupled to a logging flag.** API documentation exposure and the Secure flag on the OAuth session cookie were keyed off the `LOG_JSON` logging flag rather than an explicit environment setting, so a production deployment at the default could expose `/docs` and emit a non-Secure session cookie. - **Missing Content-Security-Policy (defense-in-depth).** The web application shipped no `script-src`/`default-src` CSP, leaving no containment for token exfiltration if an XSS issue were introduced. - **Weak default install credentials.** The installer kept the published default database password and could silently retain the default admin password on a headless install. ### Patches Upgrade to **GeoLens 1.2.4**. No configuration changes are required for the authorization and cache fixes. Operators on a public, TLS-terminated deployment should additionally set `ENVIRONMENT=production` to make the production security posture explicit; deployments that do not set it retain their prior behavior. ### Workarounds None for the authorization/cache disclosure flaws — upgrading is required. The SSRF and STAC-DoS surfaces can be partially mitigated at the network/proxy layer (egress filtering to block link-local metadata addresses; a request-size limit on `POST /search`), but the code fix is the durable remedy. ### References - Release: https://github.com/geolens-io/geolens/releases/tag/v1.2.4 - Pull request: https://github.com/geolens-io/geolens/pull/243 - Prior related advisory: GHSA-p23g-mvhj-jh3j

Exploitation Scenario

An attacker signs up for (or already holds) a low-privilege authenticated account on a public GeoLens instance hosting a mix of public and private geospatial datasets — for example, a research organization's satellite-imagery training-data catalog. They call the record contact/keyword/distribution endpoints directly by ID for datasets they don't own, harvesting the data owner's PII and metadata without triggering any authorization check. In parallel, they request an unpublished private dataset's raster tiles through a shared CDN or the bundled reverse proxy; because those tiles were cached with public Cache-Control headers, the attacker (or even a subsequent unauthenticated user) can replay the cached URL and retrieve imagery that was never meant to be public. For a deeper foothold, the attacker registers a low-TTL DNS name that first resolves to a public IP (passing GeoLens's URL validation for a STAC/probe source) and then re-points to the cloud instance metadata address at connect time, using the DNS-rebinding gap to pull credentials from the metadata service and pivot into the broader ML data infrastructure.

Weaknesses (CWE)

CWE-1021 — Improper Restriction of Rendered UI Layers or Frames: The web application does not restrict or incorrectly restricts frame objects or UI layers that belong to another application or domain.

  • [Implementation] The use of X-Frame-Options allows developers of web content to restrict the usage of their application within the form of overlays, frames, or iFrames. The developer can indicate from which domains can frame the content. The concept of X-Frame-Options is well documented, but implementation of this protection mechanism is in development to cover gaps. There is a need for allowing frames from multiple domains.
  • [Implementation] A developer can use a "frame-breaker" script in each page that should not be framed. This is very helpful for legacy browsers that do not support X-Frame-Options security feature previously mentioned. It is also important to note that this tactic has been circumvented or bypassed. Improper usage of frames can persist in the web application through nested frames. The "frame-breaking" script does not intuitively account for multiple nested frames that can be presented to the user.

Source: MITRE CWE corpus.

Timeline

Published
August 19, 2026
Last Modified
August 19, 2026
First Seen
August 19, 2026

Related Vulnerabilities