EUVD-2026-54090
GHSA-4mrh-554p-w3v7
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Low-privilege account required (PR:L); high integrity impact from content overwrite (I:H); no data read (C:N) and no denial of service (A:N).
Primary rating from Vendor (GitLab).
CVSS VectorVendor: GitLab
Lifecycle Timeline
1DescriptionCVE.org
Authorization bypass in the process and annotation taxonomy serializers in Scripta eScriptorium through 26.04.1 allows a remote authenticated user to run segmentation and transcription against other users' document parts, overwriting their content, via part primary keys supplied to a many=True related field whose queryset restriction was applied to the ManyRelatedField instead of its child_relation and therefore had no effect
AnalysisAI
Authorization bypass in eScriptorium through version 26.04.1 enables any authenticated remote user to overwrite other users' document parts by supplying arbitrary part primary keys to misconfigured serializer endpoints. The flaw is a Django REST Framework IDOR (CWE-639): queryset access restrictions were applied to the ManyRelatedField wrapper instead of its child_relation, rendering them completely inoperative. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; the integrity impact is high in collaborative archival workflows where document content corruption is irreversible without backup.
Technical ContextAI
eScriptorium is a Django-based collaborative document transcription platform. The vulnerability resides in the Django REST Framework serializers for the process and annotation taxonomy subsystems, specifically in fields declared with many=True. In DRF, a many=True relational field wraps a child_relation in a ManyRelatedField; queryset restrictions intended to scope accessible object IDs must be applied to child_relation. Here, the restriction was mistakenly applied to the outer ManyRelatedField, which never enforces it, leaving the child_relation unrestricted. This is a textbook CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR): an authenticated user can supply arbitrary integer primary keys of document parts owned by other users, and the server processes them without authorization checks. Affected CPE: cpe:2.3:a:scripta:escriptorium:*:*:*:*:*:*:*:* covering all versions through 26.04.1.
RemediationAI
Users should monitor the eScriptorium GitLab repository (https://gitlab.com/scripta/escriptorium/-/work_items/1228) for a release that supersedes 26.04.1 addressing this flaw - no exact patched version is confirmed in the available data. Until a patched release is available, the most effective compensating control is restricting platform registration to fully trusted users only, since exploitation requires an authenticated low-privilege account; removing untrusted or shared accounts eliminates the attack surface entirely. Administrators may also consider operating in single-user or closed-group mode, disabling public registration if enabled, though this trades multi-user collaboration for security. Monitoring API logs for cross-user primary key patterns (a user submitting PKs outside their own document namespace) can provide detective coverage. No side-effect-free technical workaround at the serializer level is available without a code patch.
More in Escriptorium
View allAuthorization bypass across multiple API endpoints in eScriptorium through version 26.04.1 allows any authenticated user
Server-side request forgery in eScriptorium through 26.04.1 allows remote authenticated users to pivot from the applicat
Missing authorization in eScriptorium through version 26.04.1 allows any authenticated remote user to hijack access righ
Missing authorization in eScriptorium's WebSocket consumer (all versions through 26.04.1) allows any authenticated user
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today