Stackstorm
Monthly
Improper privilege management in StackStorm st2's API Key Handler allows authenticated remote attackers to manipulate the `api_key_api.user` argument in `st2api/st2api/controllers/v1/auth.py`, enabling unauthorized privilege escalation within the automation platform. All versions through 3.9.0 are affected per the CPE data, and a publicly available proof-of-concept exploit exists (GitHub issue #6380). No vendor patch has been released; the StackStorm project has not responded to the responsible disclosure report.
Improper privilege management in StackStorm st2 up to 3.9.0 allows authenticated low-privilege users to bypass user-scoping restrictions on the action executions API by manipulating the `user` query parameter. The root cause is that `assert_user_is_admin_if_user_query_param_is_provided` in `st2api/st2api/controllers/v1/actionexecutions.py` performs no enforcement when the default NoOp RBAC backend is active - meaning every default StackStorm installation without explicit RBAC configuration is vulnerable. A public proof-of-concept exists via GitHub issue #6379, and the vendor has not yet responded to the disclosure; no patch is available at time of analysis.
Improper access control in Key-Value RBAC in StackStorm version 3.7.0 didn't check the permissions in Jinja filters, allowing attackers to access K/V pairs of other users, potentially leading to the. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Cross-site scripting (XSS) vulnerability in the Web UI of StackStorm versions prior to 3.8.0 allowed logged in users with write access to pack rules to inject arbitrary script or HTML that may be. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In StackStorm versions prior to 3.6.0, the jinja interpreter was not run in sandbox mode and thus allows execution of unsafe system commands. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
StackStorm before 3.4.1, in some situations, has an infinite loop that consumes all available memory and disk space. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In st2web in StackStorm Web UI before 2.9.3 and 2.10.x before 2.10.3, it is possible to bypass the CORS protection mechanism via a "null" origin value, potentially leading to XSS. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Incorrect access control in StackStorm API (st2api) in StackStorm before 2.9.2 and 2.10.x before 2.10.1 allows an attacker (who has a StackStorm account and is authenticated against the StackStorm. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable. No vendor patch available.
Improper privilege management in StackStorm st2's API Key Handler allows authenticated remote attackers to manipulate the `api_key_api.user` argument in `st2api/st2api/controllers/v1/auth.py`, enabling unauthorized privilege escalation within the automation platform. All versions through 3.9.0 are affected per the CPE data, and a publicly available proof-of-concept exploit exists (GitHub issue #6380). No vendor patch has been released; the StackStorm project has not responded to the responsible disclosure report.
Improper privilege management in StackStorm st2 up to 3.9.0 allows authenticated low-privilege users to bypass user-scoping restrictions on the action executions API by manipulating the `user` query parameter. The root cause is that `assert_user_is_admin_if_user_query_param_is_provided` in `st2api/st2api/controllers/v1/actionexecutions.py` performs no enforcement when the default NoOp RBAC backend is active - meaning every default StackStorm installation without explicit RBAC configuration is vulnerable. A public proof-of-concept exists via GitHub issue #6379, and the vendor has not yet responded to the disclosure; no patch is available at time of analysis.
Improper access control in Key-Value RBAC in StackStorm version 3.7.0 didn't check the permissions in Jinja filters, allowing attackers to access K/V pairs of other users, potentially leading to the. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Cross-site scripting (XSS) vulnerability in the Web UI of StackStorm versions prior to 3.8.0 allowed logged in users with write access to pack rules to inject arbitrary script or HTML that may be. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In StackStorm versions prior to 3.6.0, the jinja interpreter was not run in sandbox mode and thus allows execution of unsafe system commands. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
StackStorm before 3.4.1, in some situations, has an infinite loop that consumes all available memory and disk space. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In st2web in StackStorm Web UI before 2.9.3 and 2.10.x before 2.10.3, it is possible to bypass the CORS protection mechanism via a "null" origin value, potentially leading to XSS. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Incorrect access control in StackStorm API (st2api) in StackStorm before 2.9.2 and 2.10.x before 2.10.1 allows an attacker (who has a StackStorm account and is authenticated against the StackStorm. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable. No vendor patch available.