| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect Authorization vulnerability in OpenText™ Operations Bridge Manager. The vulnerability could allows privilege escalation by authenticated users.This issue affects Operations Bridge Manager: 2023.05, 23.4, 24.2, 24.4. |
| Pomerium is an identity and context-aware access proxy. The Pomerium databroker service is responsible for managing all persistent Pomerium application state. Requests to the databroker service API are authorized by the presence of a JSON Web Token (JWT) signed by a key known by all Pomerium services in the same deployment. However, incomplete validation of this JWT meant that some service account access tokens would incorrectly be treated as valid for the purpose of databroker API authorization. Improper access to the databroker API could allow exfiltration of user info, spoofing of user sessions, or tampering with Pomerium routes, policies, and other settings. A Pomerium deployment is susceptible to this issue if all of the following conditions are met, you have issued a service account access token using Pomerium Zero or Pomerium Enterprise, the access token has an explicit expiration date in the future, and the core Pomerium databroker gRPC API is not otherwise secured by network access controls. This vulnerability is fixed in 0.27.1. |
| Incorrect access control in the firmware update and download processes of IVY Smart v4.5.0 allows attackers to access sensitive information by analyzing the code and data within the APK file. |
| Incorrect access control in XIAO HE Smart 4.3.1 allows attackers to access sensitive information by analyzing the code and data within the APK file. |
| Incorrect access control in the firmware update and download processes of DreamCatcher Life v1.8.7 allows attackers to access sensitive information by analyzing the code and data within the APK file. |
| Capsule is a multi-tenancy and policy-based framework for Kubernetes. A namespace label injection vulnerability in Capsule v0.10.3 and earlier allows authenticated tenant users to inject arbitrary labels into system namespaces (kube-system, default, capsule-system), bypassing multi-tenant isolation and potentially accessing cross-tenant resources through TenantResource selectors. This vulnerability enables privilege escalation and violates the fundamental security boundaries that Capsule is designed to enforce. This vulnerability is fixed in 0.10.4. |
| A Local Code Execution Vulnerability exists in the product and version listed above. The vulnerability is due to a default setting in Windows and allows access to the Command Prompt as a higher privileged user. |
| Incorrect access control in the firmware update and download processes of Wear Sync v1.2.0 allows attackers to access sensitive information by analyzing the code and data within the APK file. |
| The vulnerability allows an unauthenticated attacker to access information in PAM database. |
| A vulnerability in Pantera CRM versions 401.152 and 402.072 allows unauthorized attackers to bypass IP-based access controls by manipulating the X-Forwarded-For header. |
| Vulnerability in Spotfire Spotfire Enterprise Runtime for R - Server Edition, Spotfire Spotfire Statistics Services, Spotfire Spotfire Analyst, Spotfire Spotfire Desktop, Spotfire Spotfire Server allows The impact of this vulnerability depends on the privileges of the user running the affected software..This issue affects Spotfire Enterprise Runtime for R - Server Edition: from 1.12.7 through 1.20.0; Spotfire Statistics Services: from 12.0.7 through 12.3.1, from 14.0.0 through 14.3.0; Spotfire Analyst: from 12.0.9 through 12.5.0, from 14.0.0 through 14.3.0; Spotfire Desktop: from 14.0 through 14.3.0; Spotfire Server: from 12.0.10 through 12.5.0, from 14.0.0 through 14.3.0. |
| Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.
Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.
A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.
Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.
docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege. |
| An Improper Access Control could allow a malicious actor authenticated in the API of certain UniFi Connect devices to enable Android Debug Bridge (ADB) and make unsupported changes to the system.
Affected Products:
UniFi Connect EV Station Pro (Version 1.5.18 and earlier)
UniFi Connect Display (Version 1.9.324 and earlier)
UniFi Connect Display Cast (Version 1.9.301 and earlier)
UniFi Connect Display Cast Pro (Version 1.0.78 and earlier)
UniFi Connect Display Cast Lite (Version 1.0.3 and earlier)
Mitigation:
Update UniFi Connect EV Station Pro to Version 1.5.27 or later
Update UniFi Connect Display to Version 1.13.6 or later
Update UniFi Connect Display Cast to Version 1.10.3 or later
Update UniFi Connect Display Cast Pro to Version 1.0.83 or later
Update UniFi Connect Display Cast Lite to Version 1.1.3 or later |
| OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with `GlobusOAuthenticator`, could be configured to allow all users from a particular institution only. This worked fine prior to JupyterHub 5.0, because `allow_all` did not take precedence over `identity_provider`. Since JupyterHub 5.0, `allow_all` does take precedence over `identity_provider`. On a hub with the same config, now all users will be allowed to login, regardless of `identity_provider`. `identity_provider` will basically be ignored. This is a documented change in JupyterHub 5.0, but is likely to catch many users by surprise. OAuthenticator 16.3.1 fixes the issue with JupyterHub 5.0, and does not affect previous versions. As a workaround, do not upgrade to JupyterHub 5.0 when using `GlobusOAuthenticator` in the prior configuration. |
| An incorrect authorisation check in the the 'plant transfer' function of the Growatt cloud service allowed a malicous attacker with a valid account to transfer any plant into his/her account. |
| On October 1, 2025, Palantir discovered that images uploaded through the Dossier front-end app were not being marked correctly with the proper security levels. The regression was traced back to a change in May 2025, which was meant to allow file uploads to be shared among different artifacts (e.g. other dossiers and presentations).
On deployments configured with CBAC, the front-end would present a security picker dialog to set the security level on the uploads, thereby mitigating the issue.
On deployments without a CBAC configuration, no security picker dialog appears, leading to a security level of CUSTOM with no markings or datasets selected. The resulting markings and groups for the file uploads thus will be only those added by the default authorization rules defined in the Auth Chooser configuration. On most environments, it is expected that the default authorization rules only add the Everyone group. |
| Incus is a system container and virtual machine manager. When using an ACL on a device connected to a bridge, Incus versions 6.12 and 6.13generates nftables rules that partially bypass security options `security.mac_filtering`, `security.ipv4_filtering` and `security.ipv6_filtering`. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge. Commit 254dfd2483ab8de39b47c2258b7f1cf0759231c8 contains a patch for the issue. |
| The Debian zuluPolkit/CMakeLists.txt file for zuluCrypt through the zulucrypt_6.2.0-1 package has insecure PolicyKit allow_any/allow_inactive/allow_active settings that allow a local user to escalate their privileges to root. |
| CreateWiki is Miraheze's MediaWiki extension for requesting & creating wikis. It is possible for users to be considered as the requester of a specific wiki request if their local user ID on any wiki in a wiki farm matches the local ID of the requester at the wiki where the wiki request was made. This allows them to go to that request entry's on Special:RequestWikiQueue on the wiki where their local user ID matches and take any actions that the wiki requester is allowed to take from there.
Commit 02e0f298f8d35155c39aa74193cb7b867432c5b8 fixes the issue. Important note about the fix: This vulnerability has been fixed by disabling access to the REST API and special pages outside of the wiki configured as the "global wiki" in `$wgCreateWikiGlobalWiki` in a user's MediaWiki settings.
As a workaround, it is possible to disable the special pages outside of one's own global wiki by doing something similar to `miraheze/mw-config` commit e5664995fbb8644f9a80b450b4326194f20f9ddc that is adapted to one's own setup. As for the REST API, before the fix, there wasn't any REST endpoint that allowed one to make writes. Regardless, it is possible to also disable it outside of the global wiki by using `$wgCreateWikiDisableRESTAPI` and `$wgConf` in the configuration for one's own wiki farm.. |
| A vulnerability has been identified within Rancher Manager where a missing server-side validation on the `.username` field in Rancher can allow users with update permissions on other User resources to cause denial of access for targeted accounts. |
