---
id: "CVE-2026-82411"
kind: "vulnerability"
aliases: ["CVE-2026-82411"]
title: "Open Object: scoped API token reads other object types' history records"
severity: "medium"
cvss: 6.5
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["api", "government", "open-object", "package", "self-hosted"]
not_affected_if: ["patched-version", "superuser-tokens-only"]
published_at: "2026-10-28T23:17:10+00:00"
first_seen_at: "2026-10-28T23:35:49+00:00"
updated_at: "2026-10-28T23:36:39+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82411", "first_seen_at": "2026-10-28T23:35:49+00:00"}]
---

# Open Object: scoped API token reads other object types' history records

A valid API token with read access to one ObjectType can fetch the full versioned record of objects belonging to other ObjectTypes through the history-detail endpoint. The authorization checks that the normal retrieve endpoint applies are skipped on that path, so the record data, which can include sensitive personal or case records, is disclosed.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed Open Object version against the affected ranges: 2.4.3 through 2.5.0, 3.x before 3.6.2, 4.0.0 through 4.0.1, and 4.1.0.
- Look for a route `GET /api/v2/objects/{uuid}/{index}` that is reachable with non-superuser API tokens.

## Fix

- Upgrade Open Object to `2.5.1`, `3.6.2`, `4.0.2`, or `4.1.1` depending on the release line in use.
- Review API tokens that have read grants on any ObjectType, since any of them could have exposed other types' history records.

## Timeline

- 2026-10-28T23:35:49+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-82411

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_