The 1E-Exchange-URLResponseTime instruction that is part of the Network product pack available on the 1E Exchange does not properly validate the URL parameter, which allows for a specially crafted input to perform arbitrary code execution with SYSTEM permissions. This instruction only runs on Windows clients. To remediate this issue download the updated Network product pack from the 1E Exchange and update the 1E-Exchange-URLResponseTime instruction to v20.1 by uploading it through the 1E Platform instruction upload UI

The 1E-Exchange-CommandLinePing instruction that is part of the Network product pack available on the 1E Exchange does not properly validate the input parameter, which allows for a specially crafted input to perform arbitrary code execution with SYSTEM permissions. This instruction only runs on Windows clients. To remediate this issue download the updated Network product pack from the 1E Exchange and update the 1E-Exchange-CommandLinePing instruction to v18.1 by uploading it through the 1E Platform instruction upload UI

Affected 1E Platform versions have a Blind SQL Injection vulnerability that can lead to arbitrary code execution.  Application of the relevant hotfix remediates this issue. for v8.1.2 apply hotfix Q23166 for v8.4.1 apply hotfix Q23164 for v9.0.1 apply hotfix Q23169 SaaS implementations on v23.7.1 will automatically have hotfix Q23173 applied. Customers with SaaS versions below this are urged to upgrade urgently - please contact 1E to arrange this

A vulnerability has been identified in POWER METER SICAM Q100 (All versions < V2.50), POWER METER SICAM Q100 (All versions < V2.50), POWER METER SICAM Q100 (All versions < V2.50), POWER METER SICAM Q100 (All versions < V2.50), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10). Affected devices do not properly validate the RecordType-parameter in requests to the web interface on port 443/tcp. This could allow an authenticated remote attacker to crash the device (followed by an automatic reboot) or to execute arbitrary code on the device.

A vulnerability has been identified in POWER METER SICAM Q100 (All versions < V2.50), POWER METER SICAM Q100 (All versions < V2.50), POWER METER SICAM Q100 (All versions < V2.50), POWER METER SICAM Q100 (All versions < V2.50), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10). Affected devices do not properly validate the EndTime-parameter in requests to the web interface on port 443/tcp. This could allow an authenticated remote attacker to crash the device (followed by an automatic reboot) or to execute arbitrary code on the device.

A vulnerability has been identified in POWER METER SICAM Q100 (7KG9501-0AA01-0AA1) (All versions < V2.50), POWER METER SICAM Q100 (7KG9501-0AA01-2AA1) (All versions < V2.50), POWER METER SICAM Q100 (7KG9501-0AA31-0AA1) (All versions < V2.50), POWER METER SICAM Q100 (7KG9501-0AA31-2AA1) (All versions < V2.50), SICAM P850 (7KG8500-0AA00-0AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA00-2AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA10-0AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA10-2AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA30-0AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA30-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA01-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA01-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA02-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA02-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA11-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA11-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA12-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA12-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA31-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA31-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA32-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA32-2AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA00-0AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA00-2AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA10-0AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA10-2AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA30-0AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA30-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA01-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA01-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA02-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA02-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA11-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA11-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA12-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA12-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA31-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA31-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA32-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA32-2AA0) (All versions < V3.10), SICAM T (All versions < V3.0). Affected devices do not properly validate the Language-parameter in requests to the web interface on port 443/tcp. This could allow an authenticated remote attacker to crash the device (followed by an automatic reboot) or to execute arbitrary code on the device.

IBM QRadar SIEM 7.4 and 7.5 is vulnerable to privilege escalation, allowing a user with some admin capabilities to gain additional admin capabilities. IBM X-Force ID: 239425.

A vulnerability has been identified in SIMATIC RTLS Locating Manager (All versions < V3.2). Affected products do not properly validate input for a backup script. This could allow an authenticated remote attacker with high privileges in the application to execute arbitrary code with 'NT Authority/SYSTEM' privileges.

An improper input handling vulnerability exists in the web-based management interface of mobility conductors running either AOS-10 or AOS-8 operating systems. Successful exploitation could allow an authenticated malicious actor with valid credentials to trigger unintended behavior on the affected system.

An issue was discovered in Backdrop CMS 1.13.x before 1.13.5 and 1.14.x before 1.14.2. It allows the upload of entire-site configuration archives through the user interface or command line. It does not sufficiently check uploaded archives for invalid data, allowing non-configuration scripts to potentially be uploaded to the server. This issue is mitigated by the fact that the attacker would be required to have the "Synchronize, import, and export configuration" permission, a permission that only trusted administrators should be given. Other measures in the product prevent the execution of PHP scripts, so another server-side scripting language must be accessible on the server to execute code.

Improper Input Validation of plugin files in Administrator Interface of Secomea GateManager allows a server administrator to inject code into the GateManager interface. This issue affects: Secomea GateManager versions prior to 10.0.

An OS command injection and memory corruption vulnerability in the PAN-OS management web interface that allows authenticated administrators to disrupt system processes and potentially execute arbitrary code and OS commands with root privileges. This issue impacts: PAN-OS 8.1 versions earlier than PAN-OS 8.1.16; PAN-OS 9.0 versions earlier than PAN-OS 9.0.10; PAN-OS 9.1 versions earlier than PAN-OS 9.1.4; PAN-OS 10.0 versions earlier than PAN-OS 10.0.1.

An Improper Input Validation in Ivanti EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1 allows a remotely authenticated user with administrative access to achieve remote code execution.

In Moodle before 3.8.2, 3.7.5, 3.6.9 and 3.5.11, insufficient input escaping was applied to the PHP unit webrunner admin tool.

A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in UniFi OS to execute a Command Injection on the host device.

An authenticated command injection vulnerability exists in the Archer BE450 v1 and BE7200 v1 router that allows an administrator to execute arbitrary system commands through the web management interface. After successfully authenticating to the admin interface, an attacker can leverage the browser’s developer console by supplying a crafted input that is passed to backend system commands without adequate sanitization. Successful exploitation enables execution of arbitrary commands with elevated privileges on the device, which may allow the attacker to start unauthorized services, modify system configuration, or otherwise fully compromise the router’s operating environment.

A vulnerability in the radius authentication system of Brocade Fabric OS before Brocade Fabric OS 9.0 could allow a remote attacker to execute arbitrary code on the Brocade switch.

A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.

A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in UniFi Access Application to execute a Command Injection on the host device.

A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in certain devices running UniFi OS to execute a Command Injection within such UniFi OS devices or instances.

A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in certain devices running UniFi OS to escalate privileges within such UniFi OS devices or instances.

A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in UID Enterprise Agent to execute a Command Injection on the host device.

Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. In versions 8.2.6.4 and prior, the HAProxy section-save endpoints (POST /api/service/haproxy/<server_id>/section/<section_type> and the PUT / global / defaults variants) accept a JSON option field that is not validated, not escaped, and is rendered verbatim into the generated HAProxy configuration via the section.j2, global.j2, and defaults.j2 Ansible templates. Because Roxy-WI then pushes the generated config to the load balancer and runs systemctl reload haproxy, an authenticated user with role ≤ 3 (user) can inject arbitrary HAProxy directives into the config that runs on every load balancer their group manages — including option external-check + external-check command /bin/bash -c '…', which gives remote code execution on the load balancer as the haproxy user on every health-check tick. At time of publication, there are no publicly available patches.

Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. In versions 8.2.6.4 and prior, POST /waf/<service>/<server_ip>/rule/<rule_id>/save accepts a config_file_name form field that is passed straight through to config_mod.master_slave_upload_and_restart(...) as the destination path. The validation chain (_replace_config_path_to_correct → check_is_conf) only requires the path to contain a hard-coded service substring (nginx/haproxy/apache2/httpd/keepalived) and the substring conf or cfg, and to not contain ... The encoded-slash substitution 92 → / is applied before the substring check, so the attacker can build any absolute path anywhere on the LB filesystem as long as it satisfies those substring constraints. The body of the WAF rule (config form field) is written verbatim to that path. By choosing a filename like 92etc92cron.d92nginx_cfg_evil (resolving to /etc/cron.d/nginx_cfg_evil), an attacker drops a cron entry on the load balancer with attacker-controlled content. Cron parses the file on its next scan, executing the embedded job as root — full RCE on every load balancer the caller's group manages. At time of publication, there are no publicly available patches.

On F5 BIG-IP AFM 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5.1, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, an authenticated attacker with high privileges can upload a maliciously crafted file to the BIG-IP AFM Configuration utility, which allows an attacker to run arbitrary commands. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated

Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. A vulnerability in versions prior to 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 allows attackers who have control over a given apps update server / update storage to serve maliciously crafted update packages that pass the code signing validation check but contain malicious code in some components. This kind of attack would require significant privileges in a potential victim's own auto updating infrastructure and the ease of that attack entirely depends on the potential victim's infrastructure security. Electron versions 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 contain a fix for this issue. There are no known workarounds.

Chamilo LMS v1.11.13 lacks validation on the user modification form, allowing attackers to escalate privileges to Platform Admin.

In Apache Iceberg, the table's metadata files are control files: they tell readers which data files belong to the table and which table version to read. `write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations. The full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target. `allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite. In that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs. If the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating it. In plain terms, Polaris can later hand out temporary storage access for the same attacker-chosen area. That attacker-chosen area does not need to be limited to the poisoned table's own files. If it is a broader storage prefix, another table's prefix, or, depending on configuration or provider behavior, even a bucket/container root, the resulting disclosure or corruption scope can extend to any data and metadata Polaris can reach there. The practical consequences are therefore similar to the staged-create credential-vending issue already discussed: data and metadata reachable in that storage scope can be exposed and, if write-capable credentials are later issued, modified, corrupted, or removed. Even before that later credential step, Polaris itself performs the metadata write to the unchecked location. So the core issue is not only later credential vending. The primary defect is that Polaris skips its intended location checks before performing a security- sensitive metadata write when only `write.metadata.path` changes. When `polaris.config.allow.unstructured.table.location=false`, current code review suggests the later `updateTableLike(...)` validation usually rejects out-of-tree metadata locations before the unsafe path is persisted. That may reduce the persisted / credential-vending variant, but it does not prevent the underlying defect: Polaris still skips the intended pre-write location check when only `write.metadata.path` changes.

Apache Polaris can issue broad temporary ("vended") storage credentials during staged table creation before the effective table location has been validated or durably reserved. Those temporary credentials are meant to limit the scope of accessible table data and metadata, but this scope limitation becomes attacker- directed because the attacker can choose a reachable target location. In the confirmed variant, if the caller supplies a custom `location` during stage create and requests credential vending, Apache Polaris uses that location to construct delegated storage credentials immediately. The stage-create path itself neither runs the normal location validation nor the overlap checks before those credentials are issued. Closely related to that, the staged-create flow also accepts `write.data.path` / `write.metadata.path` in the request properties and feeds those location overrides into the same effective table location set used for credential vending. Those fields are secondary to the main custom-`location` exploit, but they are still attacker-influenced location inputs that should be validated before any credentials are issued.

In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials that only work for one table's files, but a crafted namespace or table name can cause those credentials to work across the configured bucket instead. Apache Polaris builds Google Cloud Storage downscoped credentials by creating a Credential Access Boundary (CAB) with CEL conditions that are intended to restrict access to the requested table's storage path. The relevant CEL string is built from the bucket name and the table path. That table path is derived from namespace and table identifiers. In current code, that path appears to be inserted into the CEL expression without escaping. As a result, a namespace or table identifier containing a single quote and other URI-safe CEL fragments can break out of the intended quoted string and change the meaning of the CEL condition. In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated GCS credentials whose CEL path restriction had effectively collapsed. Those delegated credentials could then: - list another table's object prefix; - read another table's metadata control file (Iceberg metadata JSON); - create and delete an object under another table's object prefix; - and also list, read, create, and delete objects under an unrelated external prefix in the same bucket that was not part of any table path. That last point is important. The issue is not limited to "another table". In the confirmed setup, once Apache Polaris returned credentials for the crafted table, the path restriction inside the configured bucket was effectively gone. The practical effect is that temporary credentials for one crafted table can be broader than the table Polaris was asked to authorize, and can become effectively bucket-wide within the configured bucket. The current GCS testing used a Polaris principal with broad catalog privileges for setup. A separate least-privilege Polaris RBAC variant has not yet been tested on GCS. However, the storage-credential broadening behavior itself has been confirmed on GCS.

Apache Polaris accepts literal `*` characters in namespace and table names. When it later builds temporary S3 access policies for delegated table access, those same characters appear to be reused unescaped in S3 IAM resource patterns and `s3:prefix` conditions. In S3 IAM policy matching, `*` is treated as a wildcard rather than as ordinary text. That means temporary credentials issued for one crafted table can match the storage path of a different table. In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary- credential path on both MinIO and real AWS S3, credentials returned for crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other tables' S3 locations. The confirmed behavior includes: - reading another table's metadata control file ([Iceberg metadata JSON]); - listing another table's exact S3 table prefix ([table prefix]); - and, when write delegation was returned for the crafted table, creating and deleting an object under another table's exact S3 table prefix. A control case using ordinary different names did not allow the same cross-table access. A least-privilege AWS S3 variant was also confirmed in which the attacker principal had no Polaris permissions on the victim table and only the minimal permissions required to create and use a crafted wildcard table (namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that setup, direct Polaris access to `foo.t1` remained forbidden, but the attacker could still create and load `*.*`, receive delegated S3 credentials, and use those credentials to list, read, create, and delete objects under `foo.t1`. In Iceberg, the metadata JSON file is a control file: it tells readers which data files belong to the table, which snapshots exist, and which table version to read. So unauthorized access to it is already a meaningful confidentiality problem. The confirmed write-capable variant means the issue is not limited to disclosure.

Improper input validation vulnerability in parser_infe and sheifd_find_itemIndexin fuctions of libsimba library prior to SMR Apr-2022 Release 1 allows out of bounds write by privileged attackers.

Improper input validation vulnerability in parser_iloc and sheifd_find_itemIndexin fuctions of libsimba library prior to SMR Apr-2022 Release 1 allows out of bounds write by privileged attacker.

On 16.1.x versions prior to 16.1.2.2 and 15.1.x versions prior to 15.1.5.1, BIG-IP APM does not properly validate configurations, allowing an authenticated attacker with high privileges to manipulate the APM policy leading to privilege escalation/remote code execution. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated

Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ, Apache ActiveMQ Broker, Apache ActiveMQ All. An authenticated attacker can use the admin web console page to construct a malicious broker name that bypasses name validation to include an xbean binding that can be later used by a VM transport to load a remote Spring XML application. The attacker can then use the DestinationView mbean to send a message to trigger a VM transport creation that will reference this malicious broker name which can lead to loading the malicious Spring XML context file. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ Broker: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ All: before 5.19.6, from 6.0.0 before 6.2.5. Users are recommended to upgrade to version 6.2.5 or 5.19.6, which fixes the issue.

A vulnerability, which was classified as problematic, has been found in elunez eladmin up to 2.7. Affected by this issue is the function checkFile of the file /api/deploy/upload. The manipulation of the argument servers leads to deserialization. The attack may be launched remotely.

GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. The GeoServer security mechanism can perform an unchecked JNDI lookup, which in turn can be used to perform class deserialization and result in arbitrary code execution. The same can happen while configuring data stores with data sources located in JNDI, or while setting up the disk quota mechanism. In order to perform any of the above changes, the attack needs to have obtained admin rights and use either the GeoServer GUI, or its REST API. The lookups are going to be restricted in GeoServer 2.21.0, 2.20.4, 1.19.6. Users unable to upgrade should restrict access to the `geoserver/web` and `geoserver/rest` via a firewall and ensure that the GeoWebCache is not remotely accessible.

GeoWebCache is a tile caching server implemented in Java. The GeoWebCache disk quota mechanism can perform an unchecked JNDI lookup, which in turn can be used to perform class deserialization and result in arbitrary code execution. While in GeoWebCache the JNDI strings are provided via local configuration file, in GeoServer a user interface is provided to perform the same, that can be accessed remotely, and requires admin-level login to be used. These lookup are unrestricted in scope and can lead to code execution. The lookups are going to be restricted in GeoWebCache 1.21.0, 1.20.2, 1.19.3.

A vulnerability has been identified in SiPass integrated AC5102 (ACC-G2) (All versions < V6.4.9), SiPass integrated ACC-AP (All versions < V6.4.9). Affected devices improperly sanitize input for the pubkey endpoint of the REST API. This could allow an authenticated remote administrator to escalate privileges by injecting arbitrary commands that are executed with root privileges.

Databasir is a team-oriented relational database model document management platform. Databasir 1.01 has remote code execution vulnerability. JDBC drivers are not validated prior to use and may be provided by users of the system. This can lead to code execution by any basic user who has access to the system. Users are advised to upgrade. There are no known workarounds to this issue.

Adobe Commerce versions 2.4.3-p1 (and earlier) and 2.3.7-p2 (and earlier) are affected by an improper input validation vulnerability. Exploitation of this issue does not require user interaction and could result in a post-authentication arbitrary code execution.

A vulnerability has been identified in SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0) (All versions < V3.0.0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) (All versions < V3.0.0), SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0) (All versions < V3.0.0), SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) (All versions < V3.0.0), SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0) (All versions < V3.0.0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) (All versions < V3.0.0), SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0) (All versions < V3.0.0), SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0) (All versions < V3.0.0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) (All versions < V3.0.0), SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0) (All versions < V3.0.0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) (All versions < V3.0.0). Affected devices do not properly validate input while loading the configuration files. This could allow an authenticated remote attacker to execute arbitrary shell commands on the device.

In Carlo Gavazzi UWP3.0 in multiple versions and CPY Car Park Server in Version 2.8.3 an remote attacker with admin rights could execute arbitrary commands due to missing input sanitization in the backup restore function

A vulnerability in Cisco Jabber for Windows could allow an authenticated, remote attacker to execute arbitrary code. The vulnerability is due to improper validation of message contents. An attacker could exploit this vulnerability by sending specially crafted Extensible Messaging and Presence Protocol (XMPP) messages to the affected software. A successful exploit could allow the attacker to cause the application to execute arbitrary programs on the targeted system with the privileges of the user account that is running the Cisco Jabber client software, possibly resulting in arbitrary code execution.

A vulnerability was found in LinZhaoguan pb-cms 1.0.0 and classified as critical. This issue affects some unknown processing of the file /admin#themes of the component Add New Topic Handler. The manipulation of the argument Topic Key leads to deserialization. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

A vulnerability in the web-based management interface of Cisco AsyncOS Software for Cisco Secure Email Gateway and Cisco Secure Web Appliance could allow an authenticated, remote attacker to perform command injection attacks against an affected device. The attacker must authenticate with valid administrator credentials. This vulnerability is due to insufficient validation of XML configuration files by an affected device. An attacker could exploit this vulnerability by uploading a crafted XML configuration file. A successful exploit could allow the attacker to inject commands to the underlying operating system with root privileges.

A vulnerability was determined in PluXml up to 5.8.22. Affected is the function FileCookieJar::__destruct of the file core/admin/medias.php of the component Media Management Module. Executing a manipulation of the argument File can lead to deserialization. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was informed early about this issue and announced that "[w]e fix this issue in the next version 5.8.23". A patch for it is ready.

Improper Input Validation vulnerability in project file upload in Nozomi Networks Guardian and CMC allows an authenticated attacker with admin or import manager roles to execute unattended commands on the appliance using web server user privileges. This issue affects: Nozomi Networks Guardian versions prior to 22.0.0. Nozomi Networks CMC versions prior to 22.0.0.

A vulnerability exists in the SecOps SOAR server. The custom integrations feature allowed an authenticated user with an "IDE role" to achieve Remote Code Execution (RCE) in the server. The flaw stemmed from weak validation of uploaded Python package code. An attacker could upload a package containing a malicious setup.py file, which would execute on the server during the installation process, leading to potential server compromise. No customer action is required. All customers have been automatically upgraded to the fixed version: 6.3.64 or higher.