Goobi viewer EUVD-2026-109060

The viewer must be fetching external resources via the DownloadTaskEndpoint download flow - the attacker needs to induce the server to download from an HTTP(S) URL under their control (reachable unauthenticated per GHSA-79jg-3m2m-jgc8). The attacker must operate an HTTP server returning a crafted Content-Disposition header whose filename contains an absolute path or ../ sequences. RCE specifically requires the Tomcat process to have write access to the deployed web-application directory, which the advisory states holds in the standard installation. Limiting factor: the fix adds an externalResource[@enabled] configuration gate (default false), indicating the external-resource download capability must be enabled/used for the fetch-and-write primitive to be reachable; where that feature is not used, the file-write path is not triggered. No per-user authentication or user interaction is required for the download trigger itself.

This is a genuine top-priority vulnerability, not a high-CVSS-but-low-real-risk case. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) describes fully remote, low-complexity exploitation with no privileges and no user interaction, and the GHSA advisory corroborates the unauthenticated nature: the linked GHSA-79jg-3m2m-jgc8 WebSocket endpoint (DownloadTaskEndpoint) lets an unauthenticated user specify the download URL, so the attacker can force the viewer to fetch from a server they control. The technical impact is total (arbitrary file write to any Tomcat-writable path, yielding RCE as the tomcat OS user, plus targeted directory destruction via prepareNewFolder). The vuln.today decision label is act_now, which aligns with the critical CVSS and confirmed unauthenticated RCE mechanism. Signals that are MISSING and should temper over-certainty: no EPSS probability was provided, there is no CISA KEV listing in the input (so no confirmed active exploitation), and no verified working exploit code is referenced - only the vendor advisory and the public patch commit. The practical caveat is configuration: the fix commit adds an isExternalResourceUrlsEnabled() gate defaulting to false, implying the external-resource download feature must be enabled for the viewer to fetch external URLs, which may narrow the exploitable population below what the raw 9.8 suggests. Overall: treat as act_now based on the confirmed unauthenticated-RCE design and vendor advisory, while recognizing exploitation is contingent on the external-resource feature being in use.

An attacker connects to the unauthenticated DownloadTaskEndpoint WebSocket and supplies a download URL pointing at an HTTP server they control. That server returns a Content-Disposition header whose filename contains ../ traversal or an absolute path (e.g. a JSP webshell targeting the deployed webapp directory), which ExternalFilesDownloader.getFilename() passes to Path.resolve() unsanitised, writing attacker content to an arbitrary Tomcat-writable location and achieving remote code execution as the tomcat user. No public, verified exploit code is referenced in the available data, though the vendor advisory and patch commit are public.