GHSA-p77j-g7h5-r2vw
Fix: geolens-io/geolens#243GHSA-p77j-g7h5-r2vw is a security vulnerability in geolens. O3 Security confirms whether GHSA-p77j-g7h5-r2vw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
GeoLens's authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)
Real-World Exposure
geolensReal-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>/environand allowing CRLF header injection. - Unauthenticated STAC search DoS.
POST /searchdid not cap the size of GeoJSONintersectsgeometries (theGETsibling did). - API key written to access logs. The bundled reverse proxy logged the
api_keyquery-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_JSONlogging flag rather than an explicit environment setting, so a production deployment at the default could expose/docsand emit a non-Secure session cookie. - Missing Content-Security-Policy (defense-in-depth). The web application shipped no
script-src/default-srcCSP, 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | geolens | all versions | 1.2.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for geolens. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-p77j-g7h5-r2vw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-p77j-g7h5-r2vw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-p77j-g7h5-r2vw in your dependencies?
O3 detects GHSA-p77j-g7h5-r2vw across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.