BaSyx AAS Web UI EUVD-2026-90890

Requires a BaSyx AAS Web UI deployment running version v2-241220 up to (but not including) v2-260924 AND configured to use authentication (Basic Auth, Bearer token, or OAuth2) against its infrastructure - unauthenticated/open deployments do not expose a credential to steal. Exploitation further requires victim interaction: an already-authenticated user must open an attacker-crafted Web UI link whose aas or path query parameter points to an attacker-controlled origin (CVSS UI:A). No attacker authentication or special privileges are needed (PR:N), and the attack is network-delivered, but it is limited by the social-engineering step and does not work against instances already upgraded to v2-260924 or that restrict destinations via the new trustedOrigins allowlist.

This is a genuine, well-substantiated credential-disclosure flaw, not a paper-high score. The vendor-supplied CVSS 4.0 vector (8.3, AV:N/AC:L/AT:N/PR:N/UI:A) captures it well: an unauthenticated attacker (PR:N) exploits over the network, but exploitation requires victim interaction (UI:A - the user must open a crafted link), which is the main brake on severity. The high rating is driven legitimately by VC:H plus subsequent-system impact (SC:H/SI:H): once the victim's browser discloses its Basic Auth credential, Bearer token, or OAuth2 access token to the attacker endpoint, those credentials are replayed to reach protected AAS services with the victim's privileges - so the real-world impact is both disclosure and downstream unauthorized access. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation or automated mass-exploitation; absence of these signals lowers urgency relative to the raw 8.3. Note the gating condition emphasized by the vendor: this only bites 'in deployments using authentication' - unauthenticated/open BaSyx instances are not exposed to credential theft here. The fix is confirmed (v2-260924, PR #1557), which is the single most actionable signal: upgrade.

An attacker crafts a BaSyx AAS Web UI URL whose aas or path query parameter points to a server they control, then phishes a logged-in operator into clicking it (e.g., a link in an email or chat). The victim's browser, following the UI's shared request handler, attaches the configured infrastructure Authorization header (Basic credentials, Bearer, or OAuth2 token) to the request sent to the attacker's endpoint, and the attacker replays that credential to query protected AAS repositories/services as the victim. No public exploit code is identified at time of analysis.