Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI
Not in CISA KEV

GHSA-p77j-g7h5-r2vw — geolens

Fix: geolens-io/geolens#243

GHSA-p77j-g7h5-r2vw is a security vulnerability in geolens. A fix is available for geolens — see the affected versions and patch details below.

GeoLens's authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Aug 19, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐍geolens

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIgeolensall versions1.2.4pip install --upgrade 'geolens==1.2.4'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for geolens, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update geolens to 1.2.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p77j-g7h5-r2vw is resolved across your whole dependency graph.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

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: pub
O3 Security · Impact-Aware SCA

Is GHSA-p77j-g7h5-r2vw in your dependencies?

Find it across PyPI, including transitive dependencies.

GHSA-p77j-g7h5-r2vw: XSS — Fixed in 1.2.4 | O3 Security