GHSA-9GJV-JVM7-VV2V: Improper Access Control Exposes Private Sub-Object Data in Gramps Web API

Gramps Web API serves as the RESTful backend for the Gramps Web genealogy platform. It manages complex hierarchical data structures, including primary objects like individuals and nested sub-objects like addresses, citations, or media. The application implements role-based access control, utilizing a Guest role for users requiring read-only access to non-sensitive public records. These access controls are designed to restrict visibility based on explicit privacy flags assigned by database administrators.

The vulnerability, tracked as GHSA-9GJV-JVM7-VV2V, resides within the API's data retrieval endpoints. When a Guest user requests a list of parent objects, the API correctly enforces permissions on the primary records. However, it fails to apply the necessary privacy filters to the nested sub-objects associated with those parent records.

This discrepancy creates an improper access control condition classified under CWE-200 (Exposure of Sensitive Information) and CWE-284 (Improper Access Control). Any user authenticated with the Guest role can query the list endpoints and extract the restricted sub-object data from the resulting JSON payload. The exposure bypasses the intended application logic designed to protect specific data points within otherwise public records.

The root cause of this vulnerability is a structural deficiency in the API's serialization pipeline regarding nested database relationships. Gramps data models rely heavily on sub-objects to store granular attributes such as alternate names, media references, and geographical data. Each sub-object contains an independent boolean flag designating its privacy status, allowing administrators to share a general profile while hiding specific details.

When the API queries parent objects for list endpoints, the backend Object Relational Mapper (ORM) retrieves the associated sub-objects to construct the full entity. The serialization logic subsequently converts these database models into standardized JSON representations. This conversion process lacked the necessary conditional checks to evaluate the privacy flag of each nested sub-object against the requesting user's authorization level.

Because the list endpoints process multiple records simultaneously, the system optimized data retrieval without recursively applying the privacy filter function used elsewhere in the application. Consequently, the API embeds the raw, unfiltered sub-object dictionaries into the parent object's JSON structure. The system effectively relies on the parent object's public status to authorize the transmission of the entire hierarchical data tree.

In the vulnerable implementation, the API endpoints responsible for listing objects serialize the entire nested structure returned by the database query. The core logic verifies the user's read permissions against the parent object, ensuring a Guest cannot view a completely private person record. However, the serialization function iterates over nested collections, such as lists of addresses or notes, without evaluating their individual attributes.

The structural flaw manifests when the serialization schema maps database fields to the API response format. While a function exists to verify if a primary object should be redacted, this function is not mapped to the nested list comprehensions generating the sub-object payloads. The backend essentially executes a transformation like parent.addresses = [AddressSerializer(a).data for a in parent.db_addresses] without filtering.

The patched version introduces an explicit filtering mechanism within the serialization layer. Before a sub-object is appended to the response dictionary, the code evaluates both the object's private attribute and the requesting user's role context. The corrected logic acts as a restrictive gate, ensuring nested arrays are filtered (e.g., [AddressSerializer(a).data for a in parent.db_addresses if not a.private or user.has_override]) before the JSON payload is finalized and transmitted to the client.

Exploiting this vulnerability requires minimal technical sophistication and relies entirely on standard application features. An attacker first requires valid credentials for an account assigned the Guest role on the target Gramps Web instance. The vulnerability cannot be exploited by unauthenticated external threat actors.

Once authenticated, the attacker initiates an HTTP GET request to the vulnerable API list endpoints, such as the primary person or event retrieval paths. The server processes the request normally, validating the session token and confirming the Guest role's permission to access the public parent objects. The server compiles the data tree and returns an HTTP 200 OK response containing the structured JSON payload.

The attacker parses this JSON response to extract the nested sub-object arrays. By inspecting fields that map to alternative names, addresses, or media object handles, the attacker observes data explicitly flagged as private in the backend database. No specialized tools, payload obfuscation, or memory corruption techniques are necessary, as the flaw constitutes a direct logic error in the API's standard response generation.

The primary impact of this vulnerability is the unauthorized disclosure of sensitive genealogical data. Genealogy databases frequently contain information about living individuals, which administrators explicitly mark as private to comply with privacy expectations, organizational policies, or regional data protection regulations. The flaw directly undermines the fundamental privacy mechanism provided by the Gramps software.

Exposed data attributes include private alternate names, physical addresses, and database handles for restricted notes, citations, and media files. While the vulnerability does not permit data modification, arbitrary code execution, or privilege escalation, it severely compromises data confidentiality. The extraction of handles for private media and citations may also facilitate secondary horizontal privilege escalation attacks if those subsequent endpoints fail to re-validate access controls independently.

The scope of the exposure is bound by the size of the database and the number of sub-objects utilizing the privacy flag. An attacker can systematically harvest this data by paginating through the list endpoints, effectively mirroring the restricted datasets locally. This poses a material risk to deployments hosting extensive family histories containing contemporary, sensitive personal information.

System administrators must upgrade the gramps-webapi package to version 3.11.0 to permanently resolve this vulnerability. This release incorporates the necessary serialization filters to enforce sub-object privacy flags consistently across all nested data structures. The update should be applied using the standard package management procedures for the deployment environment, typically via pip or by pulling the latest official Docker container image.

In environments where immediate patching is not feasible, administrators should review the necessity of the Guest role. Revoking Guest access from untrusted users completely mitigates the exposure risk, as the vulnerability mandates an authenticated session to query the affected endpoints. If the platform requires public access, administrators must accept the risk of sub-object exposure until the system can be upgraded.

Following the application of the patch, administrators should conduct verification testing to ensure the integrity of the fix. This involves authenticating via a dedicated Guest test account and querying endpoints known to contain private sub-objects. Inspecting the JSON response must confirm that the nested arrays omit the private entities while correctly returning the authorized public data.