| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to perform unauthorized actions due to improper configuration of HTTP method-based security constraints. |
| A Kiteworks appliance setup interface did not enforce authentication once the appliance had completed initial configuration. An unauthenticated attacker with network access to the appliance could read and modify a limited set of setup records, including a contact name and email address captured during initial configuration. |
| A form-rendering interface in the Advanced Forms component is reachable without authentication so that published forms can be displayed to anonymous visitors, but it returned more data than the form itself required. Anyone who knew the web address of a published form could potentially retrieve the form owner's Kiteworks account profile, including personal details, along with parts of the deployment's configuration settings; no passwords, authentication tokens, or multi-factor secrets were exposed. |
| In Splunk Enterprise versions below 10.4.3 and 10.2.7, an unauthenticated user with network access to the Patroni Representational State Transfer (REST) Application Programming Interface (API) on a search head cluster member could execute attacker-controlled operating-system commands. The vulnerability is possible because this interface does not require authentication for critical configuration operations. For more information see Sidecar configuration settings (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.2/splunk-sidecars/sidecar-configuration-settings) in the Splunk documentation.
Splunk Enterprise versions 10.0.x and 9.4.x are not affected. |
| A flaw was found in Foreman. The Red Hat Satellite /unattended/provision API endpoint is vulnerable to an authentication bypass due to a semantic logic flaw in host_verifier.rb. The application verifies the database state of a provisioning token rather than its actual presence in the incoming HTTP request. Because a host actively undergoing provisioning has an unexpired token in the database, the server's valid_host_token? method evaluates to true, granting access to the kickstart template even if the requester provides no token at all in the URL. |
| A flaw was found in Maestro. Its REST API write endpoints were registered without proper authentication middleware. This allows a remote attacker to perform unauthorized write operations, such as creating, modifying, or deleting consumers and resource bundles. This could lead to data integrity issues or a denial of service (DoS). |
| LMCache through 0.5.5 contains a server-side request forgery vulnerability in its frontend monitoring service that allows unauthenticated attackers to bypass the proxy allowlist by registering arbitrary hosts. Attackers can add entries via POST /api/proxies and then use /proxy or /proxy2 to reach internal hosts, read responses, and tamper with nodes or stop the heartbeat. |
| A vulnerability in an API interface of ClearPass Policy Manager could allow an unauthenticated remote attacker to circumvent existing authentication controls. Successful exploitation could allow an attacker to obtain sensitive information from the affected system. |
| Incorrect implementation of JWT/OAuth authentication in Impala executors in Apache Impala versions up to and including 4.5.2 which allows attacked to access resources served by the executor's webserver when that webserver is configured to accept JWT/OAuth tokens. Bearer token (JWT) signatures are not validated resulting in the webserver accepting any valid JWT.
Users are recommended to either disable JWT/OAuth auth for Impala executors or upgrade to version 4.5.3, which fixes this issue. |
| LMCache through 0.5.5 contains an unauthenticated remote code execution vulnerability that allows remote attackers to execute Python code by posting scripts to the /run_script endpoint. Attackers can recover real builtins through the injected FastAPI app object, bypassing the guarded __import__, to import os and run operating system commands as the LMCache process. |
| LMCache multiprocess mode, also called distributed mode, opens an unauthenticated ZeroMQ ROUTER so worker processes can register and share KV cache blocks. Messages on that socket are msgpack. Extension code 1 is passed to DeviceIPCWrapper.Deserialize, which calls pickle.loads, while the server is still decoding request arguments and before the handler runs. A single unauthenticated ZMQ DEALER message to the transport port (default 5555) therefore executes code as the user the LMCache process runs as. Official container images run that process as root. The transport binds to localhost unless the operator sets a routable address with --host, which is how multi-node deployments let peers connect. |
| LMCache through 0.5.5 contains a missing authentication vulnerability in the multiprocess coordinator that allows remote unauthenticated attackers to access its HTTP fleet control API listening on all interfaces by default. Attackers can register or deregister instances via /instances, overwrite quotas via /quota endpoints, inject events via /events, and enumerate /directory/keys to disrupt caching and disclose placement metadata. |
| LMCache through 0.5.5 contains a missing authentication vulnerability in the multiprocess mode HTTP server that allows remote unauthenticated attackers to access management endpoints listening on all interfaces by default. Attackers can read environment credentials via GET /env and configuration via GET /config, clear caches, delete cache objects, and modify tenant quotas to evict other tenants' cached data. |
| When Gitea's built-in SSH server is enabled (`START_SSH_SERVER = true`), the presented public key was looked up with an SQL `LIKE` comparison of its encoded content, which is case-insensitive on some databases, including the default SQLite. An attacker who can construct a case variant of another user's registered RSA public key for which they can derive the private key could have that key matched to the victim's account and authenticate over SSH as that user. Keys are now looked up by fingerprint. |
| A vulnerability was discovered in Fleet's Git webhook receiver (the gitjob webhook service). When a webhook secret is not configured, incoming webhook requests are accepted without verification, and processing a request can change the spec.pollingInterval field of a matching GitRepo resource in any namespace. A caller with network access to the webhook service and no Kubernetes credentials can therefore alter GitRepo configuration outside
the namespaces they are authorized for. This only affects SUSE Rancher Fleet 0.16 before 0.16.2, older versions are not affected. |
| Missing authentication has been found in remote-execution task updates in the smart_proxy_dynflow package. The progress and completion callbacks accept a report when the one-time token is missing. A network attacker or user must already know the identifier of a running job. This applies when remote execution is set to pull or pull-mqtt mode. They can send their own job output and mark the job as a success or a failure. The job is then recorded with that result. |
| On MISP instances configured to require TOTP enrolment (Security.otp_required), the enforcement of the mandatory two-factor authentication setup applied only to standard browser requests. An authenticated user who had not yet enrolled in TOTP could bypass the forced setup by issuing any non-browser request type, including AJAX/XHR calls, REST API requests, .json format URLs, restSearch queries, or automation actions. Because these machine-readable request shapes cannot follow the redirect that the browser path uses to send the user to the TOTP enrolment page, the guard simply skipped the check and the user retained full access to the instance without completing the required second-factor setup.
The initial fix (commit 8deb0619e) added a guard specifically for AJAX requests. A follow-up fix (commit 6b527ba6e) broadened the guard to cover every non-browser request shape, while preserving the exemption for identities authenticated via API key (logged_by_authkey flag).
Impact: an authenticated user on an otp_required instance can operate with full access indefinitely without enrolling in TOTP, nullifying the instance-level two-factor authentication policy.
Affected version: <2.5.48 |
| Kiteworks Email Protection Gateway did not sufficiently restrict which account a certificate could be assigned to. This could allow an attacker to associate a certificate with another user's account, affecting the confidentiality and integrity of that account's encrypted mail and, where certificate-based login is enabled, potentially permitting unauthorized access to the account. |
| A resource exhaustion vulnerability in Kiteworks Email Protection Gateway allowed an unauthenticated remote attacker to repeatedly trigger a comparatively expensive server-side operation, causing a partial denial of service. |
| A flaw was found in oc-mirror. During mirroring operations, the embedded local cache registry binds to all network interfaces without authentication or encryption instead of restricting access to the local system. An unauthenticated attacker on an adjacent network can connect to the exposed service to push tampered container images, delete cached images, or access mirrored content. |
