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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| HF Datasets | pip | < 1.2.4 | 1.2.4 |
Do you use HF Datasets? You're affected.
How severe is it?
What should I do?
1 step-
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:
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
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
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
Primary
CWE-1392 Use of Default Credentials
Primary
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Primary
CWE-285 Improper Authorization
Primary
CWE-400 Uncontrolled Resource Consumption
Primary
CWE-524 Use of Cache Containing Sensitive Information
Primary
CWE-532 Insertion of Sensitive Information into Log File
Primary
CWE-918 Server-Side Request Forgery (SSRF)
Primary
CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')
Primary
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.
References
Timeline
Related Vulnerabilities
CVE-2026-61667 9.9 DIRAC: SQLi chained into eval() gives RCE
Same package: datasets CVE-2026-50027 9.8 mcp-memory-service: auth bypass on document API
Same package: datasets CVE-2026-71851 9.0 crypto-js: weak PRNG enables wallet key recovery
Same package: datasets CVE-2026-55178 7.5 GeoLens: IDOR leaks private datasets via AI metadata API
Same package: datasets CVE-2026-65010 6.6 Datasets: symlink following enables arbitrary file write
Same package: datasets