CTERA Portal CVE-2025-52196

Exploitation requires the attacker to get a crafted HTML file containing an <iframe> into a context where CTERA Portal 8.1.x (build 8.1.1417.24) parses or renders it, so the server follows the iframe's source URL and issues the attacker-directed HTTP request; the realistic prerequisite is the ability to upload or share an HTML file into the portal, which typically implies an authenticated/provisioned account despite the NVD PR:N rating. Limiting factors: the vulnerability is confined to the specific 8.1.x build identified, impact is confidentiality-only (S:U, no integrity/availability), and SSRF reach depends on the portal server's network position and egress controls to internal services.

The NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5) frames this as a network-reachable, low-complexity, unauthenticated SSRF with high confidentiality impact and no integrity or availability impact - consistent with CWE-918. However, the signals conflict: the description requires an attacker to supply 'a crafted HTML file containing an iframe,' which implies the attacker must get that file into the portal (upload/preview/share), a capability that in CTERA Portal typically requires an authenticated account - this contradicts the PR:N (unauthenticated) rating and should be verified with the vendor. No EPSS score, no CISA KEV listing, and no confirmed POC flag are present in the input, so there is no evidence of active or widespread exploitation; one of the two references is a GitHub gist (simonecris) that plausibly contains a write-up or proof-of-concept but its exploit status is not confirmed by the input. SSVC-style read: exploitation = none observed, automatable = likely no (requires crafting/placing an HTML file and a limited single-version target), technical impact = partial (confidentiality-only SSRF, S:U). Net: this is a legitimate but moderate-priority issue - a high-ish CVSS confidentiality SSRF constrained to a single narrow product build, not an urgent mass-exploitation threat absent any EPSS/KEV signal.

An attacker places a crafted HTML file containing an <iframe> pointing at an internal URL (e.g., a cloud metadata endpoint or internal service) where the CTERA Portal server processes or renders it, causing the server to issue an attacker-controlled HTTP request from its trusted network position. The referenced GitHub gist may provide a proof-of-concept, but its exploit status is not confirmed by the input data.