Remote code execution vulnerability in /cmsms-2.1.6-install.php/index.php in CMS Made Simple version 2.1.6 allows remote attackers to inject arbitrary PHP code via the "timezone" parameter in step 4 of a fresh installation procedure.

In System Management Module (SMM) versions prior to 1.06, a field in the header of SMM firmware update images is insufficiently sanitized, allowing post-authentication command injection on the SMM as the root user.

Dell EMC ScaleIO versions prior to 2.5, contain a command injection vulnerability in the Light Installation Agent (LIA). This component is used for central management of ScaleIO deployment and uses shell commands for certain actions. A remote malicious user, with network access to LIA and knowledge of the LIA administrative password, could potentially exploit this vulnerability to run arbitrary commands as root on the systems where LIAs are installed.

An issue was discovered on Dongguan Diqee Diqee360 devices. The affected vacuum cleaner suffers from an authenticated remote code execution vulnerability. An authenticated attacker can send a specially crafted UDP packet, and execute commands on the vacuum cleaner as root. The bug is in the function REQUEST_SET_WIFIPASSWD (UDP command 153). A crafted UDP packet runs "/mnt/skyeye/mode_switch.sh %s" with an attacker controlling the %s variable. In some cases, authentication can be achieved with the default password of 888888 for the admin account.

Artica Web Proxy before 3.06.112911 allows remote attackers to execute arbitrary code as root by conducting a cross-site scripting (XSS) attack involving the username-form-id parameter to freeradius.users.php.

An OS command injection vulnerability exists in the web interface /action/ipcamRecordPost functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A specially-crafted HTTP request can lead to arbitrary command execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.

Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.