As noted in the “VTPM.md” file in the eve documentation, “VTPM is a server listening on port 8877 in EVE, exposing limited functionality of the TPM to the clients. VTPM allows clients to execute tpm2-tools binaries from a list of hardcoded options” The communication with this server is done using protobuf, and the data is comprised of 2 parts: 1. Header 2. Data When a connection is made, the server is waiting for 4 bytes of data, which will be the header, and these 4 bytes would be parsed as uint32 size of the actual data to come. Then, in the function “handleRequest” this size is then used in order to allocate a payload on the stack for the incoming data. As this payload is allocated on the stack, this will allow overflowing the stack size allocated for the relevant process with freely controlled data. * An attacker can crash the system. * An attacker can gain control over the system, specifically on the “vtpm_server” process which has very high privileges.

Vitess is a database clustering system for horizontal scaling of MySQL. Prior to versions 23.0.3 and 22.0.4, anyone with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that arbitrary code is later executed when that backup is restored. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there. Versions 23.0.3 and 22.0.4 contain a patch. Some workarounds are available. Those who intended to use an external decompressor then can always specify that decompressor command in the `--external-decompressor` flag value for `vttablet` and `vtbackup`. That then overrides any value specified in the manifest file. Those who did not intend to use an external decompressor, nor an internal one, can specify a value such as `cat` or `tee` in the `--external-decompressor` flag value for `vttablet` and `vtbackup` to ensure that a harmless command is always used.

Backstage is an open platform for building developer portals. The Backstage scaffolder-backend plugin uses a templating library that requires sandbox, as it by design allows for code injection. The library used for this sandbox so far has been `vm2`, but in light of several past vulnerabilities and existing vulnerabilities that may not have a fix, the plugin has switched to using a different sandbox library. A malicious actor with write access to a registered scaffolder template could manipulate the template in a way that allows for remote code execution on the scaffolder-backend instance. This was only exploitable in the template YAML definition itself and not by user input data. This is vulnerability is fixed in version 1.15.0 of `@backstage/plugin-scaffolder-backend`.

Spinnaker is an open source, multi-cloud continuous delivery platform. Echo like some other services, uses SPeL (Spring Expression Language) to process information - specifically around expected artifacts. In versions prior to 2026.1.0, 2026.0.1, 2025.4.2, and 2025.3.2, unlike orca, it was NOT restricting that context to a set of trusted classes, but allowing FULL JVM access. This enabled a user to use arbitrary java classes which allow deep access to the system. This enabled the ability to invoke commands, access files, etc. Versions 2026.1.0, 2026.0.1, 2025.4.2, and 2025.3.2 contain a patch. As a workaround, disable echo entirely.

Spinnaker is an open source, multi-cloud continuous delivery platform. Versions prior to 2025.1.6, 2025.2.3, and 2025.3.0 are vulnerable to server-side request forgery. The primary impact is allowing users to fetch data from a remote URL. This data can be then injected into spinnaker pipelines via helm or other methods to extract things LIKE idmsv1 authentication data. This also includes calling internal spinnaker API's via a get and similar endpoints. Further, depending upon the artifact in question, auth data may be exposed to arbitrary endpoints (e.g. GitHub auth headers) leading to credentials exposure. To trigger this, a spinnaker installation MUST have two things. The first is an artifact enabled that allows user input. This includes GitHub file artifacts, BitBucket, GitLab, HTTP artifacts and similar artifact providers. JUST enabling the http artifact provider will add a "no-auth" http provider that could be used to extract link local data (e.g. AWS Metadata information). The second is a system that can consume the output of these artifacts. e.g. Rosco helm can use this to fetch values data. K8s account manifests if the API returns JSON can be used to inject that data into the pipeline itself though the pipeline would fail. This vulnerability is fixed in versions 2025.1.6, 2025.2.3, and 2025.3.0. As a workaround, disable HTTP account types that allow user input of a given URL. This is probably not feasible in most cases. Git, Docker and other artifact account types with explicit URL configurations bypass this limitation and should be safe as they limit artifact URL loading. Alternatively, use one of the various vendors which provide OPA policies to restrict pipelines from accessing or saving a pipeline with invalid URLs.

In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed..

The Linux Foundation ONOS SDN Controller 1.15 and earlier versions is affected by: Improper Input Validation. The impact is: A remote attacker can execute arbitrary commands on the controller. The component is: apps/yang/src/main/java/org/onosproject/yang/impl/YangLiveCompilerManager.java. The attack vector is: network connectivity. The fixed version is: 1.15.

The Linux Foundation ONOS 2.0.0 and earlier is affected by: Poor Input-validation. The impact is: A network administrator (or attacker) can install unintended flow rules in the switch by mistake. The component is: createFlow() and createFlows() functions in FlowWebResource.java (RESTful service). The attack vector is: network management and connectivity.

The Linux Foundation ONOS 1.15.0 and ealier is affected by: Improper Input Validation. The impact is: The attacker can remotely execute any commands by sending malicious http request to the controller. The component is: Method runJavaCompiler in YangLiveCompilerManager.java. The attack vector is: network connectivity.

The Linux Foundation ONOS 2.0.0 and earlier is affected by: Poor Input-validation. The impact is: A network administrator (or attacker) can install unintended flow rules in the switch by mistake. The component is: applyFlowRules() and apply() functions in FlowRuleManager.java. The attack vector is: network management and connectivity.

A vulnerability was identified in PyTorch 2.10.0. The affected element is an unknown function of the component pt2 Loading Handler. The manipulation leads to deserialization. The attack can only be performed from a local environment. The exploit is publicly available and might be used. The project was informed of the problem early through a pull request but has not reacted yet.

Vitess is a database clustering system for horizontal scaling of MySQL. Users can either intentionally or inadvertently create a keyspace containing `/` characters such that from that point on, anyone who tries to view keyspaces from VTAdmin will receive an error. Trying to list all the keyspaces using `vtctldclient GetKeyspaces` will also return an error. Note that all other keyspaces can still be administered using the CLI (vtctldclient). This issue is fixed in version 16.0.1. As a workaround, delete the offending keyspace using a CLI client (vtctldclient).

Vitess is a database clustering system for horizontal scaling of MySQL through generalized sharding. Prior to version 16.0.2, users can either intentionally or inadvertently create a shard containing `/` characters from VTAdmin such that from that point on, anyone who tries to create a new shard from VTAdmin will receive an error. Attempting to view the keyspace(s) will also no longer work. Creating a shard using `vtctldclient` does not have the same problem because the CLI validates the input correctly. Version 16.0.2, corresponding to version 0.16.2 of the `go` module, contains a patch for this issue. Some workarounds are available. Always use `vtctldclient` to create shards, instead of using VTAdmin; disable creating shards from VTAdmin using RBAC; and/or delete the topology record for the offending shard using the client for your topology server.

NATS-Server is a High-Performance server for NATS.io, a cloud and edge native messaging system. Prior to versions 2.11.15 and 2.12.6, a client which can connect to the leafnode port can crash the nats-server with a certain malformed message pre-authentication. Versions 2.11.15 and 2.12.6 contain a fix. As a workaround, disable leafnode support if not needed or restrict network connections to the leafnode port, if plausible without compromising the service offered.

Indy Node is the server portion of a distributed ledger purpose-built for decentralized identity. In versions 1.12.4 and prior, the `pool-upgrade` request handler in Indy-Node allows an improperly authenticated attacker to remotely execute code on nodes within the network. The `pool-upgrade` request handler in Indy-Node 1.12.5 has been updated to properly authenticate pool-upgrade transactions before any processing is performed by the request handler. The transactions are further sanitized to prevent remote code execution. As a workaround, endorsers should not create DIDs for untrusted users. A vulnerable ledger should configure `auth_rules` to prevent new DIDs from being written to the ledger until the network can be upgraded.

Open Container Initiative umoci before 0.4.7 allows attackers to overwrite arbitrary host paths via a crafted image that causes symlink traversal when "umoci unpack" or "umoci raw unpack" is used.

An improper limitation of path name flaw was found in containernetworking/cni in versions before 0.8.1. When specifying the plugin to load in the 'type' field in the network configuration, it is possible to use special elements such as "../" separators to reference binaries elsewhere on the system. This flaw allows an attacker to execute other existing binaries other than the cni plugins/types, such as 'reboot'. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

In wlan firmware, there is a possible firmware assertion due to improper input handling. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07932637; Issue ID: ALPS07932637.

In connectivity system driver, there is a possible out of bounds write due to improper input validation. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07929848; Issue ID: ALPS07929848.

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.

The 1E-Exchange-DisplayMessageinstruction that is part of the End-User Interaction product pack available on the 1E Exchange does not properly validate the Caption or Message parameters, 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 DELETE the instruction “Show dialogue with caption %Caption% and message %Message%” from the list of instructions in the Settings UI, and replace it with the new instruction 1E-Exchange-ShowNotification instruction available in the updated End-User Interaction product pack. The new instruction should show as “Show %Type% type notification with header %Header% and message %Message%” with a version of 7.1 or above.

SummaryA command injection vulnerability (CWE-78) has been found to exist in the `wrangler pages deploy` command. The issue occurs because the `--commit-hash` parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of `--commit-hash` to execute arbitrary commands on the system running Wrangler. Root causeThe commitHash variable, derived from user input via the --commit-hash CLI argument, is interpolated directly into a shell command using template literals (e.g.,  execSync(`git show -s --format=%B ${commitHash}`)). Shell metacharacters are interpreted by the shell, enabling command execution. ImpactThis vulnerability is generally hard to exploit, as it requires --commit-hash to be attacker controlled. The vulnerability primarily affects CI/CD environments where `wrangler pages deploy` is used in automated pipelines and the --commit-hash parameter is populated from external, potentially untrusted sources. An attacker could exploit this to: * Run any shell command. * Exfiltrate environment variables. * Compromise the CI runner to install backdoors or modify build artifacts. Credits Disclosed responsibly by kny4hacker. Mitigation * Wrangler v4 users are requested to upgrade to Wrangler v4.59.1 or higher. * Wrangler v3 users are requested to upgrade to Wrangler v3.114.17 or higher. * Users on Wrangler v2 (EOL) should upgrade to a supported major version.

Etherpad is a real-time collaborative editor. In versions prior to 1.8.16, an attacker can craft an `*.etherpad` file that, when imported, might allow the attacker to gain admin privileges for the Etherpad instance. This, in turn, can be used to install a malicious Etherpad plugin that can execute arbitrary code (including system commands). To gain privileges, the attacker must be able to trigger deletion of `express-session` state or wait for old `express-session` state to be cleaned up. Core Etherpad does not delete any `express-session` state, so the only known attacks require either a plugin that can delete session state or a custom cleanup process (such as a cron job that deletes old `sessionstorage:*` records). The problem has been fixed in version 1.8.16. If users cannot upgrade to 1.8.16 or install patches manually, several workarounds are available. Users may configure their reverse proxies to reject requests to `/p/*/import`, which will block all imports, not just `*.etherpad` imports; limit all users to read-only access; and/or prevent the reuse of `express_sid` cookie values that refer to deleted express-session state. More detailed information and general mitigation strategies may be found in the GitHub Security Advisory.

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

Account users in Apache CloudStack by default are allowed to register templates to be downloaded directly to the primary storage for deploying instances. Due to missing validation checks for KVM-compatible templates in CloudStack 4.0.0 through 4.18.2.4 and 4.19.0.0 through 4.19.1.2, an attacker that can register templates, can use them to deploy malicious instances on KVM-based environments and exploit this to gain access to the host filesystems that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of KVM-based infrastructure managed by CloudStack. Users are recommended to upgrade to Apache CloudStack 4.18.2.5 or 4.19.1.3, or later, which addresses this issue. Additionally, all user-registered KVM-compatible templates can be scanned and checked that they are flat files that should not be using any additional or unnecessary features. For example, operators can run the following command on their file-based primary storage(s) and inspect the output. An empty output for the disk being validated means it has no references to the host filesystems; on the other hand, if the output for the disk being validated is not empty, it might indicate a compromised disk. However, bear in mind that (i) volumes created from templates will have references for the templates at first and (ii) volumes can be consolidated while migrating, losing their references to the templates. Therefore, the command execution for the primary storages can show both false positives and false negatives. for file in $(find /path/to/storage/ -type f -regex [a-f0-9\-]*.*); do echo "Retrieving file [$file] info. If the output is not empty, that might indicate a compromised disk; check it carefully."; qemu-img info -U $file | grep file: ; printf "\n\n"; done For checking the whole template/volume features of each disk, operators can run the following command: for file in $(find /path/to/storage/ -type f -regex [a-f0-9\-]*.*); do echo "Retrieving file [$file] info."; qemu-img info -U $file; printf "\n\n"; done

GLPI is an open source IT Asset Management, issue tracking system and service desk system. The GLPI addressing plugin in versions < 2.9.1 suffers from authenticated Remote Code Execution vulnerability, allowing access to the server's underlying operating system using command injection abuse of functionality. There is no workaround for this issue and users are advised to upgrade or to disable the addressing plugin.

arduino-esp32 is an Arduino core for the ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6 and ESP32-H2 microcontrollers. The `arduino-esp32` CI is vulnerable to multiple Poisoned Pipeline Execution (PPE) vulnerabilities. Code injection in `tests_results.yml` workflow (`GHSL-2024-169`) and environment Variable injection (`GHSL-2024-170`). These issue have been addressed but users are advised to verify the contents of the downloaded artifacts.

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.

Due to improper input validation, an authenticated remote attacker could execute arbitrary commands on the target system.

An improper input validation discovered in Avaya Call Management System could allow an unauthorized remote command via a specially crafted web request. Affected versions include 18.x, 19.x prior to 19.2.0.7, and 20.x prior to 20.0.1.0.

Jellyfin is an open source self hosted media server. Versions prior to 10.11.7 contain a vulnerability chain in the subtitle upload endpoint (POST /Videos/{itemId}/Subtitles), where the Format field is not validated, allowing path traversal via the file extension and enabling arbitrary file write. This arbitrary file write can be chained into arbitrary file read via .strm files, database extraction, admin privilege escalation, and ultimately remote code execution as root via ld.so.preload. Exploitation requires an administrator account or a user that has been explicitly granted the "Upload Subtitles" permission. This issue has been fixed in version 10.11.7. If users are unable to upgrade immediately, they can grant non-administrator users Subtitle upload permissions to reduce attack surface.

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 (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 (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.

HotCRP is conference review software. A problem introduced in April 2024 in version 3.1 led to inadequately sanitized code generation for HotCRP formulas which allowed users to trigger the execution of arbitrary PHP code. The problem is patched in release version 3.2.

A trivial sandbox (enabled with the `-dSAFER` option) escape flaw was found in the ghostscript interpreter by injecting a specially crafted pipe command. This flaw allows a specially crafted document to execute arbitrary commands on the system in the context of the ghostscript interpreter. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

Gardener implements the automated management and operation of Kubernetes clusters as a service. A security vulnerability was discovered in Gardener prior to versions 1.116.4, 1.117.5, 1.118.2, and 1.119.0 that could allow a user with administrative privileges for a Gardener project to obtain control over the seed cluster(s) where their shoot clusters are managed. This CVE affects all Gardener installations no matter of the public cloud provider(s) used for the seed clusters/shoot clusters. `gardener/gardener` (`gardenlet`) is the affected component. Versions 1.116.4, 1.117.5, 1.118.2, and 1.119.0 fix the issue.

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.

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.

An authenticated attacker can exploit an improper authorization vulnerability in Azure Web Apps to elevate privileges over a network.

Multiple vulnerabilities in Cisco Jabber for Windows, Cisco Jabber for MacOS, and Cisco Jabber for mobile platforms could allow an attacker to execute arbitrary programs on the underlying operating system with elevated privileges, access sensitive information, intercept protected network traffic, or cause a denial of service (DoS) condition. For more information about these vulnerabilities, see the Details section of this advisory.

In ApexPro Telemetry Server Versions 4.2 and prior, CARESCAPE Telemetry Server v4.2 & prior, Clinical Information Center (CIC) Versions 4.X and 5.X, CARESCAPE Central Station (CSCS) Versions 1.X, B450 Version 2.X, B650 Version 1.X, B650 Version 2.X, B850 Version 1.X, B850 Version 2.X, a vulnerability in the software update mechanism allows an authenticated attacker to upload arbitrary files on the system through a crafted update package.

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

Improper input validation in the Pulsar Function Worker allows a malicious authenticated user to execute arbitrary Java code on the Pulsar Function worker, outside of the sandboxes designated for running user-provided functions. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true". This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0. 2.10 Pulsar Function Worker users should upgrade to at least 2.10.6. 2.11 Pulsar Function Worker users should upgrade to at least 2.11.4. 3.0 Pulsar Function Worker users should upgrade to at least 3.0.3. 3.1 Pulsar Function Worker users should upgrade to at least 3.1.3. 3.2 Pulsar Function Worker users should upgrade to at least 3.2.1. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

Discord-Recon is a Discord bot created to automate bug bounty recon, automated scans and information gathering via a discord server. Discord-Recon is vulnerable to remote code execution. An attacker is able to execute shell commands in the server without having an admin role. This vulnerability has been fixed in version 0.0.8.

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.

Multiple vulnerabilities in Cisco Enterprise NFV Infrastructure Software (NFVIS) could allow an attacker to escape from the guest virtual machine (VM) to the host machine, inject commands that execute at the root level, or leak system data from the host to the VM. For more information about these vulnerabilities, see the Details section of this advisory.