How severe is GHSA-9gjv-jvm7-vv2v?

No CVSS score has been assigned to GHSA-9gjv-jvm7-vv2v yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-9gjv-jvm7-vv2v?

GHSA-9gjv-jvm7-vv2v affects the following packages: gramps-webapi (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-9gjv-jvm7-vv2v?

Update gramps-webapi to 3.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9gjv-jvm7-vv2v is resolved across your whole dependency graph.

How do I detect GHSA-9gjv-jvm7-vv2v in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for gramps-webapi. 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.

How do I mitigate GHSA-9gjv-jvm7-vv2v if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-9gjv-jvm7-vv2v?

O3 pinpoints whether GHSA-9gjv-jvm7-vv2v is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-9gjv-jvm7-vv2v actively exploited in the wild?

No public exploit code has been indexed for GHSA-9gjv-jvm7-vv2v yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-9gjv-jvm7-vv2v published, and has it been updated?

GHSA-9gjv-jvm7-vv2v was published on April 9, 2026 and was last updated on April 9, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

GHSA-9gjv-jvm7-vv2v

Gramps Web API: Private Sub-Object Data in Non-Private Objects Exposed to Guest Users

Published

Apr 9, 2026

Updated

Apr 9, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐍gramps-webapi

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

Summary

Users with the Guest role could receive private sub-object data (e.g. private alternate names, private addresses, private note/citation/media handles) through list API endpoints such as GET /api/people/, GET /api/places/, GET /api/events/, and all other object list endpoints.

This does not expose objects (people, places, events, …) that are themselves marked private. Top-level private objects are correctly excluded from all responses. Only sub-object data attached to otherwise-public objects is affected.

Affected Versions

All versions of Gramps Web API prior to the fix.

Root Cause

The vulnerability originates from the behaviour of PrivateProxyDb.iter_*() in Gramps core. The ProxyDbBase.__iter_object() helper, which backs all iter_*() methods in PrivateProxyDb, correctly filters out top-level private objects but returns the remaining objects unsanitized — i.e. without stripping private sub-object references. In contrast, PrivateProxyDb.get_*_from_handle() does call the appropriate sanitize_*() function.

Gramps Web API's ModifiedPrivateProxyDb (which wraps the raw database for non-admin users) inherited this behaviour without override.

The same issue affects Gramps desktop features that consume iter_*() output: reports and exports generated via Gramps desktop using PrivateProxyDb may also include private sub-object data that should have been stripped.

Conditions Required

This issue only affects trees in which sub-objects have been explicitly marked private in Gramps desktop. The Gramps Web frontend UI does not expose controls for setting the private flag on sub-objects (alternate names, addresses, notes, citations, media references, event references, etc.). In practice, such flags are set in Gramps desktop and then synced or imported into Gramps Web.

Impact

When the conditions above are met, a user with the Guest role querying any list endpoint receives:

Full content of private embedded sub-objects on people, such as alternate names (first name, surname, etc.) and addresses (street, city, etc.).
Handles referencing private notes, citations, and media attached to places, events, sources, and other objects. These reveal the existence of private linked objects but not their content; fetching those objects by handle is correctly blocked by the proxy.

Fix

ModifiedPrivateProxyDb now overrides all iter_*() object methods to check obj.get_privacy() directly on the already-loaded object (eliminating the redundant per-object refetch) and to call the appropriate sanitize_*() function before yielding each object. This is consistent with the behaviour of get_*_from_handle() in PrivateProxyDb.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`gramps-webapi`	all versions	3.11.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for gramps-webapi. 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 gramps-webapi to 3.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9gjv-jvm7-vv2v 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-9gjv-jvm7-vv2v 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-9gjv-jvm7-vv2v. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary Users with the **Guest** role could receive private sub-object data (e.g. private alternate names, private addresses, private note/citation/media handles) through list API endpoints such as `GET /api/people/`, `GET /api/places/`, `GET /api/events/`, and all other object list endpoints. **This does not expose objects (people, places, events, …) that are themselves marked private.** Top-level private objects are correctly excluded from all responses. Only sub-object data attached to otherwise-public objects is affected. ## Affected Versions All versions of Gramps Web API prior to

O3 Security · Impact-Aware SCA

Is GHSA-9gjv-jvm7-vv2v in your dependencies?

O3 detects GHSA-9gjv-jvm7-vv2v across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works