CVE-2026-89139
Description détaillée
Temporal Server compiles a Worker Controller Instance module into its Worker Service, and that module registers a compute provider named subprocess whose function is to launch a worker by running a command on the machine hosting the Worker Service. The program name and the argument vector that provider executes are taken from the compute provider configuration supplied in the caller's request rather than from operator configuration. An authenticated caller holding only a write role in a single namespace can therefore configure a worker deployment version so that the Worker Service executes a command of the caller's choosing on its own host, under the account the server process runs as. Execution is immediate rather than deferred: the configuration handler invokes every provider using the invoke strategy directly after validating the submitted specification, so no scaling decision, task arrival, or unusual request sequence is required. Because the Worker Service process holds the persistence credentials for every namespace in the cluster and the cluster's TLS material, the consequence reaches beyond the caller's namespace to the cluster as a whole. The provider is present in the official temporal-server binaries and container images for the affected releases. The only control that can keep it unreachable is the compute provider allowlist, the per-namespace dynamic configuration setting workercontroller.compute_providers.enabled, and that control does not deny by default: its default value is an unset list, and the allowlist check is skipped entirely when the value is unset, so every registered compute provider is permitted, this one included. To determine whether a deployment is affected, check the following together. The deployed Temporal Server version is 1.31.0 or later and earlier than 1.31.3. The Worker Service is running, which it is in the default service set and therefore in a stock deployment. The effective per-namespace value of workercontroller.compute_providers.enabled is either unset or contains subprocess. And authorization is configured, meaning a real authorizer and claim mapper are in place; a deployment running with no authorizer already grants every caller unrestricted access to every namespace, so it has no namespace boundary for this to cross. Note that the separate per-namespace dynamic configuration setting workercontroller.enabled does not gate the affected path. It defaults to false, and a deployment that has never set it in any namespace is still affected, which was confirmed by running an affected release with no value for that setting present anywhere in dynamic configuration. To look for a compute configuration that is already attached, call DescribeWorkerDeploymentVersion for each worker deployment version in each namespace and check whether any scaling group's compute provider type is subprocess.
Dernières Vulnérabilités
CVE-2026-94383
The MISP blocklist workflow module accepted a user-supplied blocklist filename parameter without validating the file extension. The only sanitization applied was basename() to strip path components and a check for empty or dot values. A site administrator could specify a filename with an arbitrary extension that would be placed in the MISP export directory. If the underlying web server is configured to interpret and execute scripts from that directory, the resulting file could be invoked, leading to arbitrary code execution in the context of the web server process. The vulnerability requires the attacker to hold site-administrator privileges within MISP, as the blocklist workflow module is restricted to that role. No additional user interaction is required beyond triggering the workflow action with a crafted filename parameter. The impact is full compromise of the MISP server's confidentiality, integrity, and availability, as arbitrary script execution grants the attacker the same privileges as the web server user. Version affected: <2.5.47
CVE-2026-94381
MISP has a security issue that can let a user gain more access than their API key is supposed to allow. A read-only API key should only let someone view information. However, after logging in with such a key, a specific MISP function could accidentally restore the user’s normal account permissions. This means someone with a read-only API key could potentially gain write, delete, or even administrator access if their underlying account has those permissions. Exploiting the issue requires a valid read-only API key and a single request to the affected function. The main impact is that MISP’s API key restrictions can be bypassed, allowing actions that the API key was specifically meant to prevent. Version affected: <2.5.47
CVE-2026-94379
The login() function in MISP's UsersController.php contained insufficient HTTP method validation for several security-critical code paths. The original code used an allowlist approach, checking only for specific HTTP methods (POST and PUT) before enforcing bruteforce protection, email one-time-password (OTP) verification, and login-failure logging. Because the checks were not exhaustive, an unauthenticated attacker could issue login requests using other HTTP methods and bypass all three security controls simultaneously. Specifically: - the bruteforce blocklisting check and attempt counter were skipped, allowing unlimited credential-guessing attempts without being rate-limited or blocked - the email OTP two-factor authentication step was skipped, defeating the second factor of authentication - login-failure events were neither logged nor counted, removing the audit trail and the mechanism that would normally trigger a blocklist entry. The security impact is the effective disabling of brute-force protection and multi-factor authentication for any attacker who can craft an HTTP request with a non-POST/PUT method to the login endpoint, potentially leading to credential compromise and unauthorized access to the MISP instance. Version affected: <2.5.47