PipesHub EUVD-2026-114117

The attacker must get a document containing an attacker-chosen HTTP(S) image URL into the indexing pipeline; the URL only needs to be a well-formed http/https link ending in a valid image extension, because ImageParser._is_valid_image_url checks scheme and extension only, never the host, and _fetch_single_url then calls session.get(allow_redirects=True) without the blocked-host policy. Three entry paths exist: an authenticated member uploading a Markdown/HTML file (requires a PipesHub account, hence PR:L), or - requiring NO account - an email to a connector-synced mailbox or a page crawled by the web/RSS connector. The flaw is present in default configurations of PipesHub before 0.10.0. Limiting factors: full read-back of the fetched response into persisted indexed content depends on the indexing stage completing (the PoC host could not persist content because no model provider was configured), and cloud-metadata credential theft only applies on cloud-hosted deployments where 169.254.169.254 is reachable; the blind outbound request itself, however, requires none of these.

This is a genuine but mid-tier priority, not a drop-everything emergency, and the signals are largely consistent. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L) scores 5.3 (Medium) and reflects network reach, low complexity, and some privilege. The vuln.today decision label is 'this_month' - meaningful urgency but below act_now/emergency. There is no CISA KEV listing and no EPSS value in the provided data, so there is no evidence of active or widespread exploitation; this reads as a credible, reported weakness rather than a mass-exploited one. The VulnCheck/GHSA advisory includes an executed proof-of-concept that demonstrably caused the server to fetch a loopback URL, which raises practical risk above a purely theoretical SSRF. The key tension is impact magnitude: the input 4.0 vector rates confidentiality Low (VC:L/SC:L), but the advisory argues the fetched response is base64-embedded into indexed content - a read primitive reaching internal microservices and cloud instance-metadata (169.254.169.254) credentials, which would justify a materially higher confidentiality impact. The advisory itself flags that response read-back was code-inferred, not demonstrated on the test host (indexing halted at extraction because no model provider was configured). So treat the high-confidentiality metadata-theft outcome as plausible and architecturally supported but not proven. Net: a real SSRF worth patching within the vendor's and vuln.today's stated window, with upside risk on cloud-hosted deployments.

An attacker places an image reference pointing at an internal address (e.g. <img src="http://169.254.169.254/latest/meta-data/..."> or http://127.0.0.1:9411/x.png) inside a document that PipesHub will index - an authenticated upload, an email to a synced mailbox, or a page crawled by the web/RSS connector. When the indexing service parses the document it fetches the URL via its own aiohttp client without consulting the blocked-host policy, reaching loopback, private-network, or cloud-metadata endpoints. A working PoC in the vendor advisory already demonstrated the server fetching an attacker-chosen loopback URL; given AV:N/AC:L the request is reliable, though full response exfiltration via indexed content is inferred rather than demonstrated.