Kitodo.Presentation EUVD-2026-104870

Exploitation requires that the Kitodo.Presentation extension's public proxy endpoint (which fetches a URL on behalf of the visitor) be deployed and network-reachable, and the attacker must use the one specific HTTP request method for which the endpoint fails to apply the authorization check that protects its other methods. No authentication is required (PR:N) and no special non-default configuration is named in the advisory. The key LIMITING factor is the disclosure scope: only the HTTP status code and selected response headers are returned to the attacker - response bodies are explicitly NOT disclosed - so the flaw is practically useful for internal host/port probing and reachability mapping rather than for reading sensitive internal content.

This is a moderate-severity SSRF (CWE-918) with a CVSS 4.0 base score of 6.9 and a vector of AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N - network-reachable, low attack complexity, no privileges (PR:N, unauthenticated), and no user interaction, which makes the flaw trivially triggerable by remote attackers. However, impact is deliberately bounded: confidentiality is only Low on both the vulnerable system (VC:L) and a subsequent system (SC:L), with no integrity or availability impact, because the attacker receives only the status code and selected response headers and NOT response bodies. No EPSS score, CISA KEV listing, or proof-of-concept indicator was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the signals are limited to the vendor advisory. On balance this is a genuine but secondary priority: the unauthenticated network vector warrants prompt patching, but the limited information disclosure (blind-ish SSRF usable mainly for internal host/port probing, not data exfiltration) and the niche deployment footprint of the affected product temper the real-world risk. No signals are directly conflicting; the main gap is the absence of exploitation-likelihood telemetry (EPSS/KEV/POC) to distinguish theoretical from observed risk.

A remote, unauthenticated attacker sends a request to the extension's public proxy endpoint using the specific HTTP method that skips the authorization check, supplying a URL pointing at an internal host (e.g., http://169.254.169.254/ or an internal service port). The server fetches that URL and returns the status code and selected response headers, letting the attacker map internal hosts and open ports behind the firewall. No public proof-of-concept was provided in the input, and only status/headers (not response bodies) are disclosed, so this is reconnaissance-oriented rather than full data exfiltration.