What is the CVSS score of CVE-2026-18277?

CVE-2026-18277 has a CVSS 3.1 base score of 7.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L. EPSS exploitation probability: 0.2%.

Which versions of eScriptorium are affected by CVE-2026-18277?

eScriptorium versions through 26.04.1 contain a privilege escalation vulnerability allowing any authenticated user to hijack ownership or revoke access to other researchers' OCR models without…

How to fix or mitigate CVE-2026-18277?

Within 24 hours, identify all eScriptorium instances deployed in your environment and isolate those running version 26.04.1 or earlier as higher priority; review POST request logs to OcrModelRight endpoints for suspicious ownership or permission changes from non-administrative accounts. Within 7 days, implement network access controls restricting OCR model modifications to application administrators only, enable enhanced audit logging for all model ownership changes with alerting on unauthorized transfers, and conduct a manual review of model access rights history to detect unauthorized modifications. Within 30 days, monitor the eScriptorium project release schedule for a patched version and apply immediately upon release; if an interim release is unavailable, apply a custom authorization patch to validate user ownership in POST handlers before processing create/delete operations on OcrModelRight views.

eScriptorium CVE-2026-18277

EUVD-2026-54092 HIGH

Missing Authorization (CWE-862)

2026-08-06 GitLab

GHSA-w7gw-xhpj-265q

Authentication Bypass Escriptorium Scripta

7.1

CVSS 3.1 · Vendor: GitLab

Severity by source

Vendor (GitLab) PRIMARY

7.1 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

vuln.today AI

7.6 HIGH

PR:L confirmed by authentication requirement; C:L added over NVD C:N because self-granting access to private models exposes confidential intellectual property.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (GitLab).

CVSS VectorVendor: GitLab

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

Low

Lifecycle Timeline

Analysis Generated

Aug 06, 2026 - 16:11 vuln.today

CVE Published

Aug 06, 2026 - 15:11 cve.org

HIGH 7.1

DescriptionCVE.org

Missing authorization in the OcrModelRight create and delete views in Scripta eScriptorium through 26.04.1 allows a remote authenticated user to grant themselves access to another user's private OCR model and to revoke any user's OCR model access via a POST request, because the ownership check is placed in get_context_data() and therefore runs only on the GET rendering path

AnalysisAI

Missing authorization in eScriptorium through version 26.04.1 allows any authenticated remote user to hijack access rights to another user's private OCR model or revoke any user's model access via direct POST requests. The ownership check is implemented exclusively in get_context_data(), a Django method that executes only during GET-based template rendering, leaving the POST-based create and delete operations for OcrModelRight views entirely unguarded. This is a privilege escalation affecting multi-tenant institutional instances where researchers share the platform; no public exploit has been identified at time of analysis and the CVE is not in CISA KEV.

Technical ContextAI

eScriptorium is a Django-based open-source web platform developed by the Scripta project for handwritten text recognition (HTR) and optical character recognition (OCR) of historical documents, commonly deployed in academic and archival institutions. The vulnerability resides in the OcrModelRight create and delete class-based views, which govern per-user access grants to OCR model objects. CWE-862 (Missing Authorization) identifies the root cause: Django class-based views dispatch both GET (page rendering) and POST (form submission) requests to the same view class, but the developer placed the ownership verification inside get_context_data(), a hook invoked solely during GET rendering for template context population. POST requests - which carry out the actual database write operations to create or delete OcrModelRight records - never invoke get_context_data() and therefore execute without any ownership validation. This is a well-known Django class-based view pitfall where authorization logic is attached to the wrong lifecycle method. The affected CPE is cpe:2.3:a:scripta:escriptorium:*:*:*:*:*:*:*:*.

RemediationAI

Upgrade eScriptorium to a version beyond 26.04.1 incorporating the upstream fix once a patched release is published; progress can be monitored at https://gitlab.com/scripta/escriptorium/-/work_items/1227. No patched release version has been confirmed in available data at time of analysis - the fix is currently tracked as an open work item. As compensating controls until a patch is available, administrators of shared instances should restrict user registration to vetted, trusted accounts, substantially reducing the pool of potential authenticated attackers. Placing the application behind a VPN or institutional SSO gateway prevents external parties from obtaining authenticated sessions entirely. Additionally, web application firewall rules or reverse-proxy controls that block POST requests to the OcrModelRight create and delete URL patterns (while allowing GET) would neutralize the attack vector, though this will also break legitimate model-sharing functionality. Audit logs of OcrModelRight create and delete actions should be reviewed for anomalous cross-user patterns.