ghsa

Uncontrolled Resource Consumption vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java FIPS bc-fips on All (API modules), Legion of the Bouncy Castle Inc. Bouncy Castle for Java LTS bcprov-lts8on on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files core/src/main/jdk1.9/org/bouncycastle/crypto/fips/AESNativeCFB.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/fips/AESNativeGCM.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/fips/SHA256NativeDigest.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/fips/AESNativeEngine.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/fips/AESNativeCBC.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/fips/AESNativeCTR.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/engines/AESNativeCFB.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/engines/AESNativeGCM.Java, core/src/main/jdk1.9/org/bouncycastle/crypto/engines/AESNativeEngine.Java, core/src/main/jdk1.9/org/bouncycastle/cr...

### Summary A flaw in the CORS middleware allowed request `Vary` headers to be reflected into the response, enabling attacker-controlled `Vary` values and potentially affecting cache behavior. ### Details The middleware previously copied the `Vary` header from the request when `origin` was not set to `"*"`. Since `Vary` is a response header that should only be managed by the server, this could allow an attacker to influence caching behavior or cause inconsistent CORS handling. Most environments will see impact only when shared caches or proxies rely on the `Vary` header. The practical effect varies by configuration. ### Impact May cause cache key pollution and inconsistent CORS enforcement in certain setups. No direct confidentiality, integrity, or availability impact in default configurations. ### Resolution Update to the latest patched release. The CORS middleware has been corrected to handle `Vary` exclusively as a response header.

### Impact **Note: The exploitation of this issue requires that the malicious user have access to Rancher’s audit log storage.** A vulnerability has been identified in Rancher Manager, where sensitive information, including secret data, cluster import URLs, and registration tokens, is exposed to any entity with access to Rancher audit logs. This happens in two different ways: 1. Secret Annotation Leakage: When creating Kubernetes Secrets using the `stringData` field, the cleartext value is embedded in the `kubectl.kubernetes.io/last-applied-configuration` annotation. This annotation is included in Rancher audit logs within both the request and response bodies, exposing secret material that should be redacted. 2. Cluster Registration Token Leakage: During the import or creation of downstream clusters (Custom, Imported, or Harvester), Rancher audit logs record full cluster registration manifests and tokens, including: a. Non-expiring import URLs such as `/v3/import/<token>_c-m-xxxx.yam...

### Impact This is an authentication bypass vulnerability in the Karmada Dashboard API. The backend API endpoints (e.g., /api/v1/secret, /api/v1/service) did not enforce authentication, allowing unauthenticated users to access sensitive cluster information such as Secrets and Services directly. Although the web UI required a valid JWT for access, the API itself remained exposed to direct requests without any authentication checks. Any user or entity with network access to the Karmada Dashboard service could exploit this vulnerability to retrieve sensitive data. ### Patches The issue has been fixed in Karmada Dashboard v0.2.0. This release enforces authentication for all API endpoints. Users are strongly advised to upgrade to version v0.2.0 or later as soon as possible. ### Workarounds If upgrading is not immediately feasible, users can mitigate the risk by: - Restricting network access to the Karmada Dashboard service using Kubernetes Network Policies, firewall rules, or ingress con...

### Impact A vulnerability has been identified within Rancher Manager, where after removing a custom GlobalRole that gives administrative access or the corresponding binding, the user still retains access to clusters. This only affects custom Global Roles that: - Have a `*` on `*` in `*` rule for resources - Have a `*` on `*` rule for non-resource URLs For example ```yaml apiVersion: management.cattle.io/v3 kind: GlobalRole metadata: name: custom-admin rules: - apiGroups: - '*' resources: - '*' verbs: - '*' - nonResourceURLs: - '*' verbs: - '*' ``` Specifically: - When a user is bound to a custom admin `GlobalRole`, a corresponding `ClusterRoleBinding` is created on all clusters that binds them to the cluster-admin `ClusterRole`. - When such a `GlobalRole` or the `GlobalRoleBinding` (e.g., when the user is unassigned from this role in UI) is deleted, the `ClusterRoleBinding` that binds them to the cluster-admin ClusterRole stays behind....

The ComboServlet in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.2, 2023.Q3.1 through 2023.Q3.5, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not limit the number or size of the files it will combine, which allows remote attackers to create very large responses that lead to a denial of service attack via the URL query string.

Vault and Vault Enterprise ("Vault") are vulnerable to an unauthenticated denial of service when processing JSON payloads. This occurs due to a regression from a previous fix for [+HCSEC-2025-24+|https://discuss.hashicorp.com/t/hcsec-2025-24-vault-denial-of-service-though-complex-json-payloads/76393]  which allowed for processing JSON payloads before applying rate limits. This vulnerability, CVE-2025-12044, is fixed in Vault Community Edition 1.21.0 and Vault Enterprise 1.16.27, 1.19.11, 1.20.5, and 1.21.0.

Vault and Vault Enterprise's ("Vault") AWS Auth method may be susceptible to authentication bypass if the role of the configured bound_principal_iam is the same across AWS accounts, or uses a wildcard. This vulnerability is fixed in Vault Community Edition 1.21.0 and Vault Enterprise 1.21.0, 1.20.5, 1.19.11, and 1.16.27.

Self Cross-site scripting (XSS) vulnerability on the edit Knowledge Base article page in Liferay Portal 7.4.0 through 7.4.3.101, and older unsupported versions, and Liferay DXP 2023.Q3.1 through 2023.Q3.5, 7.4 GA through update 92, and older unsupported versions allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into an attachment's filename.

A reflected cross-site scripting (XSS) vulnerability in MCMS v6.0.1 allows attackers to execute arbitrary Javascript in the context of a user's browser via a crafted payload.