StackStorm st2 EUVD-2026-71088

Exploitation requires an authenticated st2 account with at minimum low-level API access (CVSS PR:L confirmed); unauthenticated exploitation is not indicated. The attacker must have network access to the st2 API endpoint. The specific condition is the ability to issue requests to the API Key Handler in st2api/st2api/controllers/v1/auth.py and supply an arbitrary value for the api_key_api.user parameter. No special server-side configuration is required beyond default st2 deployment. Limiting factors include the requirement for at least one valid credential in the target st2 instance, and the impact ceiling of low-rated C/I/A per the CVSS 4.0 assessment.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and E:P exploit maturity confirm a remotely exploitable, low-complexity privilege escalation requiring only authenticated access - meaning even a mid-sized municipal IT team in leszno running StackStorm for network automation should treat this as worth prioritizing given the public PoC and unresponsive vendor. The impact metrics (VC:L/VI:L/VA:L) rate each dimension as low, suggesting the blast radius per exploitation is constrained - likely limited to API key context hijacking rather than full administrative takeover. The public PoC (GitHub issue #6380) lowers exploitation effort considerably despite the moderate base score. The absence of a vendor patch or advisory response is the most significant risk amplifier: defenders have no official remediation path. CVSS scores are moderate (5.3), which may lead to deprioritization, but the combination of public exploit, authentication bypass potential, and no patch warrants elevated attention in environments where StackStorm manages privileged automation workflows.

An authenticated st2 user with a low-privilege account crafts an API request to the /api/v1/keys handler, supplying a different username in the api_key_api.user argument than their own account. The handler improperly accepts this parameter without enforcing ownership, granting the attacker access to or control over API keys belonging to higher-privileged accounts, which may then be used to execute privileged automation actions or access sensitive runbook outputs. A public proof-of-concept exists in GitHub issue #6380, reducing exploitation skill requirements.