Sxdevops
Monthly
Hardcoded default secrets and credentials in aiyiyi121 SxDevOps 1.0/1.1 let unauthenticated remote attackers obtain sensitive information from instances that still run the shipped defaults - a Django SECRET_KEY of 'change-me' and the documented demo/admin password (for example Admin@123456) published in the project README. The issue is CWE-200 (exposure of sensitive information), rated CVSS 4.0 6.9 with confidentiality-only impact; no public exploit code has been identified at time of analysis, and any operator who set a strong SECRET_KEY, changed the admin/demo password, or disabled the demo accounts before exposing the service is not affected, so realistic risk is confined to negligently configured default installs of a niche self-hosted tool. The vendor was contacted early and issued a fix in commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9.
SxDevOps 1.0 and 1.1 seed demo and administrator accounts with a hard-coded default password ('Admin@123456') that is also documented in the project README, letting an unauthenticated remote attacker who can reach the login interface sign in with full administrative privileges. The flaw is only exploitable on deployments that were initialized with the demo accounts and where the password was never rotated or the accounts disabled before exposing the service; instances that set SXDEVOPS_DEMO_PASSWORD/SXDEVOPS_ADMIN_INITIAL_PASSWORD or applied the vendor fix are not affected. No public exploit code was identified at time of analysis, and the vendor has published a fixing commit (2b4bf8585c3e731e7a8af30801ea46680bc783f9).
Improper privilege management in SxDevOps 1.0/1.1 allows an authenticated user to escalate their own privileges by manipulating the update path of the UserSerializer in backend/rbac/serializers.py, reachable remotely over the network against the RBAC user-update API. The vulnerability is rated medium (CVSS 4.0 base 5.1, AV:N/AC:L/PR:H/UI:N/VC:N/VI:L/VA:L), with the main impact being integrity of role/permission data; a public exploit has not been identified at time of analysis and there is no CISA KEV listing. The vendor was contacted early, responded promptly, and published a fix in commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9, so patched deployments are no longer exposed.
Authenticated command injection in SxDevOps 1.0/1.1 lets a signed-in user with host-task/command-generation rights defeat the platform's built-in dangerous-command filter and have arbitrary shell content reach managed hosts through the Command Handler (generate_host_task in backend/aiops/services.py). The pre-patch filter relied on substring matching of strings such as 'rm -rf', 'shutdown' and 'reboot', so shell metacharacters (; && || | backtick $() and newlines) could be smuggled into the 'command' argument to chain or substitute commands. Exploitation requires valid credentials plus at least one managed host configured to receive tasks, and no public exploit code has been identified at time of analysis; the vendor was contacted early and shipped a fix under commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9, making this a lower-priority safety-filter bypass rather than an unauthenticated takeover, consistent with the independent assessment scoring it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L.
Command injection in SxDevOps 1.0 and 1.1 allows a high-privileged, authenticated operator to escape intended command restrictions when running TASK_RUN_COMMAND host tasks, because the user-supplied 'command' value is passed without neutralization to paramiko.SSHClient.exec_command in backend/ops/host_tasks.py (CWE-77). Per the assessed CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L) the attacker must already hold a role permitted to create and execute host tasks, so the practical gain is bypassing command constraints via shell metacharacters (';', '&&', '||', '|', '$(', backticks, newlines) rather than obtaining access the operator lacks. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor shipped a fix (commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9) after being contacted early in the disclosure process.
Command injection in SxDevOps 1.0 and 1.1 lets an authenticated user who can manage MCP STDIO server configurations run arbitrary operating-system commands on the host by supplying shell metacharacters in the endpoint_or_command field, which is passed unchecked to subprocess.Popen. Exploitation requires high privileges (CVSS PR:H) because the attacker must be able to create or modify MCP STDIO server entries, and the feature must be reachable on an unpatched 1.0/1.1 build; there is no public exploit identified at time of analysis and no confirmed active exploitation. The issue is rated moderate by the independent assessment (CVSS:3.1 base 7.2) and is fixed upstream in commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9, which the vendor released after being contacted.
Hardcoded default secrets and credentials in aiyiyi121 SxDevOps 1.0/1.1 let unauthenticated remote attackers obtain sensitive information from instances that still run the shipped defaults - a Django SECRET_KEY of 'change-me' and the documented demo/admin password (for example Admin@123456) published in the project README. The issue is CWE-200 (exposure of sensitive information), rated CVSS 4.0 6.9 with confidentiality-only impact; no public exploit code has been identified at time of analysis, and any operator who set a strong SECRET_KEY, changed the admin/demo password, or disabled the demo accounts before exposing the service is not affected, so realistic risk is confined to negligently configured default installs of a niche self-hosted tool. The vendor was contacted early and issued a fix in commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9.
SxDevOps 1.0 and 1.1 seed demo and administrator accounts with a hard-coded default password ('Admin@123456') that is also documented in the project README, letting an unauthenticated remote attacker who can reach the login interface sign in with full administrative privileges. The flaw is only exploitable on deployments that were initialized with the demo accounts and where the password was never rotated or the accounts disabled before exposing the service; instances that set SXDEVOPS_DEMO_PASSWORD/SXDEVOPS_ADMIN_INITIAL_PASSWORD or applied the vendor fix are not affected. No public exploit code was identified at time of analysis, and the vendor has published a fixing commit (2b4bf8585c3e731e7a8af30801ea46680bc783f9).
Improper privilege management in SxDevOps 1.0/1.1 allows an authenticated user to escalate their own privileges by manipulating the update path of the UserSerializer in backend/rbac/serializers.py, reachable remotely over the network against the RBAC user-update API. The vulnerability is rated medium (CVSS 4.0 base 5.1, AV:N/AC:L/PR:H/UI:N/VC:N/VI:L/VA:L), with the main impact being integrity of role/permission data; a public exploit has not been identified at time of analysis and there is no CISA KEV listing. The vendor was contacted early, responded promptly, and published a fix in commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9, so patched deployments are no longer exposed.
Authenticated command injection in SxDevOps 1.0/1.1 lets a signed-in user with host-task/command-generation rights defeat the platform's built-in dangerous-command filter and have arbitrary shell content reach managed hosts through the Command Handler (generate_host_task in backend/aiops/services.py). The pre-patch filter relied on substring matching of strings such as 'rm -rf', 'shutdown' and 'reboot', so shell metacharacters (; && || | backtick $() and newlines) could be smuggled into the 'command' argument to chain or substitute commands. Exploitation requires valid credentials plus at least one managed host configured to receive tasks, and no public exploit code has been identified at time of analysis; the vendor was contacted early and shipped a fix under commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9, making this a lower-priority safety-filter bypass rather than an unauthenticated takeover, consistent with the independent assessment scoring it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L.
Command injection in SxDevOps 1.0 and 1.1 allows a high-privileged, authenticated operator to escape intended command restrictions when running TASK_RUN_COMMAND host tasks, because the user-supplied 'command' value is passed without neutralization to paramiko.SSHClient.exec_command in backend/ops/host_tasks.py (CWE-77). Per the assessed CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L) the attacker must already hold a role permitted to create and execute host tasks, so the practical gain is bypassing command constraints via shell metacharacters (';', '&&', '||', '|', '$(', backticks, newlines) rather than obtaining access the operator lacks. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor shipped a fix (commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9) after being contacted early in the disclosure process.
Command injection in SxDevOps 1.0 and 1.1 lets an authenticated user who can manage MCP STDIO server configurations run arbitrary operating-system commands on the host by supplying shell metacharacters in the endpoint_or_command field, which is passed unchecked to subprocess.Popen. Exploitation requires high privileges (CVSS PR:H) because the attacker must be able to create or modify MCP STDIO server entries, and the feature must be reachable on an unpatched 1.0/1.1 build; there is no public exploit identified at time of analysis and no confirmed active exploitation. The issue is rated moderate by the independent assessment (CVSS:3.1 base 7.2) and is fixed upstream in commit 2b4bf8585c3e731e7a8af30801ea46680bc783f9, which the vendor released after being contacted.