Description
Open Object provides an API and admin interface to manage objects and object types. From 2.4.3 until 2.5.1, 3.6.2, 4.0.2, and 4.1.1, a token scoped to read one ObjectType can read the full versioned record of an object of any other ObjectType via the history-detail endpoint `GET /api/v2/objects/{uuid}/{index}`. The `history_detail` action in `src/objects/api/v2/views.py` calls `self.get_queryset()` and `get_object_or_404` directly instead of `self.get_object()`, so `check_object_permissions` and the per-object check in `ObjectTypeBasedPermission.has_object_permission` are not invoked. The queryset's `filter_for_token` applies only to the list and search actions, while `ObjectTypeBasedPermission.has_permission` allows non-create actions, leaving neither check to constrain history-detail records to the token's permitted ObjectType. The normal retrieve endpoint returns 403 for the same unauthorized object, and the sibling history action enforces the grant. Any valid non-superuser API token with a read grant on at least one ObjectType can therefore disclose another ObjectType's complete versioned object `data`, which can include citizen or case records and sensitive identifiers in government deployments. This issue is fixed in versions 2.5.1, 3.6.2, 4.0.2, and 4.1.1.
Published: 2026-10-28
Score: 6.5 Medium
EPSS: n/a
KEV: No
Impact: Unauthorized Data Disclosure
Action: Immediate Patch
AI Analysis

Impact

The vulnerability in the Open Object API allows an attacker who possesses a valid non‑superuser API token with a read grant on any single ObjectType to retrieve the complete, versioned record of an object belonging to any other ObjectType via the history-detail endpoint. This bypasses the expected authorization checks, enabling disclosure of sensitive data such as citizen or case records. The flaw is an authorization bypass; it is categorized under CWE‑639, which describes an actor gaining access to resources beyond their intended scope.

Affected Systems

Affected products are the open‑object package from maykinmedia. Versions 2.4.3 through 2.5.1, 3.6.2, 4.0.2, and 4.1.1 contain the flaw; it is remedied in releases 2.5.1, 3.6.2, 4.0.2, and 4.1.1. The issue is triggered by the GET /api/v2/objects/{uuid}/{index} history‑detail action, and the fix was applied in the commits referenced in the advisory. Systems running any earlier major or minor releases remain vulnerable.

Risk and Exploitability

The CVSS score of 6.5 indicates a moderate severity; the EPSS score is not available, and the vulnerability is not listed in CISA’s KEV catalog. The attack vector is remote via the exposed HTTP API. An adversary only needs a legitimate token that has read permission on any object type, which may be obtained through credential compromise, misconfiguration, or token reuse. Because the flaw bypasses per‑object policy checks and returns the full serialized data, it can lead to privacy violations and the exposure of confidential identifiers.

Generated by OpenCVE AI on October 29, 2026 at 00:22 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade Open Object to a patched release such as 2.5.1, 3.6.2, 4.0.2, or 4.1.1.
  • Revoke or regenerate any API tokens that provide read permissions on object types; issue new tokens with the least privilege required.
  • Limit exposure of the history‑detail endpoint by implementing network‑level filtering or firewall rules to restrict API access to trusted hosts.

Generated by OpenCVE AI on October 29, 2026 at 00:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 28 Oct 2026 23:00:00 +0000

Type Values Removed Values Added
Description Open Object provides an API and admin interface to manage objects and object types. From 2.4.3 until 2.5.1, 3.6.2, 4.0.2, and 4.1.1, a token scoped to read one ObjectType can read the full versioned record of an object of any other ObjectType via the history-detail endpoint `GET /api/v2/objects/{uuid}/{index}`. The `history_detail` action in `src/objects/api/v2/views.py` calls `self.get_queryset()` and `get_object_or_404` directly instead of `self.get_object()`, so `check_object_permissions` and the per-object check in `ObjectTypeBasedPermission.has_object_permission` are not invoked. The queryset's `filter_for_token` applies only to the list and search actions, while `ObjectTypeBasedPermission.has_permission` allows non-create actions, leaving neither check to constrain history-detail records to the token's permitted ObjectType. The normal retrieve endpoint returns 403 for the same unauthorized object, and the sibling history action enforces the grant. Any valid non-superuser API token with a read grant on at least one ObjectType can therefore disclose another ObjectType's complete versioned object `data`, which can include citizen or case records and sensitive identifiers in government deployments. This issue is fixed in versions 2.5.1, 3.6.2, 4.0.2, and 4.1.1.
Title Objects API: Cross-object-type authorization bypass on the object history-detail endpoint
Weaknesses CWE-639
References
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N'}


Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-10-28T22:40:13.728Z

Reserved: 2026-08-28T22:00:43.514Z

Link: CVE-2026-82411

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-28T23:17:10.930

Modified: 2026-10-28T23:17:10.930

Link: CVE-2026-82411

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T00:30:14Z

Weaknesses
  • CWE-639

    Authorization Bypass Through User-Controlled Key