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

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

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

eScriptorium through version 26.04.1 contains a server-side request forgery vulnerability in the METS and IIIF import endpoints that enables authenticated users to exfiltrate cloud infrastructure…

How to fix or mitigate CVE-2026-18359?

Within 24 hours: Identify and inventory all eScriptorium instances at version 26.04.1 or earlier, assess user access to import features, and implement network-level access controls to block outbound requests from application servers to cloud metadata services (169.254.169.254:80 for AWS IMDS). Within 7 days: Modify the IMPORT_ALLOWED_DOMAINS setting from its default wildcard to an explicit whitelist of required domains, implement and enforce request timeout limits on import API endpoints, and enable detailed audit logging on METS/IIIF import operations to detect internal resource access attempts. Within 30 days: Monitor vendor security channels for eScriptorium security updates, coordinate with the vendor on patch availability and upgrade timelines, and implement role-based access controls to restrict import functionality to only necessary users.

eScriptorium CVE-2026-18359

EUVD-2026-54091 HIGH

Server-Side Request Forgery (SSRF) (CWE-918)

2026-08-06 GitLab

GHSA-cpqx-fhwg-cr7g

SSRF Escriptorium Scripta

8.5

CVSS 3.1 · Vendor: GitLab

Severity by source

Vendor (GitLab) PRIMARY

8.5 HIGH

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

vuln.today AI

8.5 HIGH

Network-reachable API requires only low-privilege authentication (PR:L); default wildcard domain config enables unrestricted SSRF with scope change to internal systems including IMDS (S:C, C:H); no availability impact applies.

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

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/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

Changed

Confidentiality

High

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

Aug 06, 2026 - 16:11 vuln.today

CVE Published

Aug 06, 2026 - 15:11 cve.org

HIGH 8.5

DescriptionCVE.org

Server-side request forgery in the METS and IIIF import URI handling in Scripta eScriptorium through 26.04.1 allows a remote authenticated user to make the server issue arbitrary HTTP requests to internal hosts, including the cloud instance metadata service, via the mets_uri or iiif_uri parameter of POST /api/documents/{pk}/imports/, because the IMPORT_ALLOWED_DOMAINS setting defaults to '*' and no address filtering, redirect cap or timeout is applied

AnalysisAI

Server-side request forgery in eScriptorium through 26.04.1 allows remote authenticated users to pivot from the application server into internal networks, including cloud instance metadata services (IMDS), by supplying attacker-controlled URIs to the METS or IIIF import API endpoint. The vulnerability is rooted in the default wildcard value of the IMPORT_ALLOWED_DOMAINS setting combined with a total absence of address filtering, redirect-following caps, or request timeouts - meaning any authenticated user can coerce the server into issuing arbitrary HTTP requests. With CVSS S:C (scope changed) and C:H, the primary risk is exfiltration of cloud credentials via IMDS (e.g., AWS 169.254.169.254), which can escalate a low-privilege application account into full cloud environment compromise. No public exploit or KEV listing identified at time of analysis.

Technical ContextAI

eScriptorium (CPE: cpe:2.3:a:scripta:escriptorium:*:*:*:*:*:*:*:*) is a web-based platform for transcribing historical manuscripts, built around the METS (Metadata Encoding and Transmission Standard) and IIIF (International Image Interoperability Framework) protocols - both standard in digital humanities infrastructure for referencing remote image manifests and metadata. The import workflow exposes a POST /api/documents/{pk}/imports/ endpoint that accepts mets_uri and iiif_uri parameters and fetches the supplied URLs server-side. CWE-918 (Server-Side Request Forgery) applies: the server acts as an HTTP proxy without validating whether the target is a legitimate external resource or a sensitive internal address. The IMPORT_ALLOWED_DOMAINS configuration variable controls which domains are permitted targets, but its default value is '*' - an unrestricted wildcard - and no complementary blocking layer (address family filtering, RFC 1918/loopback block, redirect-following limit, or DNS rebinding protection) is applied. This configuration pattern is the canonical SSRF deployment mistake in applications with fetch-on-behalf functionality.

RemediationAI

No vendor-released patched version has been confirmed from available data - the only reference is the upstream GitLab work item at https://gitlab.com/scripta/escriptorium/-/work_items/1230, which should be monitored for a fix release. Pending an official patch, apply the following compensating controls in order of effectiveness: First, explicitly set IMPORT_ALLOWED_DOMAINS to an allowlist of known trusted external domains (e.g., specific IIIF and METS provider hostnames) rather than the default wildcard - this is the most direct mitigation and requires identifying all legitimate import sources in your deployment. Second, on cloud-hosted instances, block server-originated requests to IMDS addresses (169.254.169.254 for AWS/Azure, 169.254.169.254 and metadata.google.internal for GCP) via host-level iptables or security group egress rules; note this does not prevent SSRF against other internal services. Third, restrict access to the /api/documents/{pk}/imports/ endpoint to only explicitly trusted user roles if the application supports role-based access control, reducing the attack surface to a smaller authenticated population. Fourth, deploy an outbound HTTP proxy (e.g., Squid) in front of the application server with an allowlist of permitted destination ranges, which also captures future similar misconfigurations. Each network-level control carries the trade-off of requiring maintenance when legitimate import sources change.