Shlink CVE-2026-18736

Two specific conditions must both be true: (1) the attacker must possess a valid Shlink API key - CVSS PR:L confirms authentication is required and anonymous exploitation is not possible; (2) the title auto-resolution feature must be enabled in the Shlink instance configuration - the description explicitly states this precondition. Exploitation is further constrained by what internal data is actually extractable: only content appearing within an HTML <title> tag is returned, so services that do not render their sensitive data in an HTML title element are not directly exfiltrable via this path. Exploitation is blocked against: unauthenticated users, Shlink instances where title auto-resolution is disabled, and cloud metadata endpoints protected by IMDSv2 (token-gated requests, since the SSRF issues a plain GET).

The CVSS 4.0 base score of 5.3 (Medium) reflects the genuine constraints: AV:N indicates network reachability, PR:L confirms an API key is required, and the impact is bounded to partial confidentiality disclosure (VC:L, SC:L) with no integrity or availability impact. The EPSS score was not provided in the input data, so exploitation probability cannot be quantified numerically. No CISA KEV listing exists, confirming no known widespread active exploitation at time of analysis. However, a public PoC advisory repository (github.com/theopaid) is referenced, meaning exploit technique is disclosed. The most significant real-world risk amplifier is cloud metadata endpoint access: in AWS, GCP, or Azure environments, successful exfiltration of IMDSv1 metadata (169.254.169.254) can yield IAM role credentials, enabling privilege escalation far beyond what the base CVSS score suggests. The PR:L constraint and the title auto-resolution feature dependency meaningfully limit the attack surface - this is not exploitable by anonymous users or against installations where title resolution is disabled. Priority should be elevated for Shlink instances deployed in cloud environments where IMDSv2 is not enforced.

An attacker with a valid Shlink API key sets up an HTTP server at a public address that returns a 302 redirect to http://169.254.169.254/latest/meta-data/iam/security-credentials/ when queried. They then call the Shlink short URL creation API with this public URL as the long URL target while title auto-resolution is active; the Shlink server fetches the URL, follows the redirect to the cloud metadata endpoint, parses the returned content as an HTML title, and returns it in the API JSON response body. A public proof-of-concept advisory demonstrating this technique is referenced at https://github.com/theopaid/Server-side-request-forgery-through-short-URL-title-resolution-shlink-.