Termix EUVD-2026-62855

Exploitation requires a valid, authenticated Termix user account - CVSS PR:L confirms that at minimum a low-privileged account is required, ruling out fully unauthenticated exploitation. The attacker must have network access to the Termix web interface and the ability to issue POST requests to /host/db/proxy/test. The most severe impact - cloud credential theft - additionally requires that the Termix server be deployed on a cloud instance where link-local metadata services (AWS 169.254.169.254, Azure 169.254.169.254, GCP metadata.google.internal) are reachable over the host's network stack, which is the default condition in most IaaS deployments. For on-premise deployments without cloud metadata, exploitation is limited to internal TCP port scanning and host reachability enumeration via connection error analysis. No non-default Termix configuration setting is required beyond possessing a user account. Exploitation is limited by the authenticated prerequisite - anonymous or external unauthenticated attackers cannot exploit this without first obtaining credentials.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N scoring 7.7 is technically accurate and well-calibrated for this vulnerability. The Scope:Changed metric correctly captures that the primary damage extends beyond Termix itself to internal infrastructure and cloud provider credential stores - a textbook SSRF-to-cloud-credential-theft pattern. The PR:L requirement (authenticated Termix user) limits opportunistic mass exploitation but remains a meaningful threat from insider accounts, compromised credentials, or weak authentication configurations. No EPSS data was supplied in the intelligence package, and the CVE is absent from the CISA KEV catalog, so no public exploit or confirmed active exploitation is established. Despite the absence of exploitation signals, practical risk is elevated for cloud-hosted Termix deployments: access to AWS IMDSv1, Azure IMDS, or GCP metadata endpoints is a default reachability condition in most cloud VM deployments, and credential theft from those endpoints has historically enabled full account takeover. On-premise deployments without cloud metadata still face meaningful risk from internal port scanning and service fingerprinting through Termix's error responses. The low prevalence of Termix constrains aggregate risk, but per-instance impact is high.

An authenticated Termix user submits a POST request to /host/db/proxy/test with the testTarget field set to the AWS instance metadata URL (169.254.169.254/latest/meta-data/iam/security-credentials/) or an internal Kubernetes API server address. The Termix server establishes a raw TCP or SOCKS connection to the specified address from its privileged network position, and the response body or structured connection result is returned to the attacker - exposing IAM role credentials, internal service banners, or host reachability data. No public exploit code is known at time of analysis, but the attack requires only a valid session token and a standard HTTP client, making it trivially executable by any authenticated user.