| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A privilege escalation vulnerability exists in Apache CloudStack versions 4.10.0.0 through 4.20.0.0 where a malicious Domain Admin user in the ROOT domain can reset the password of user-accounts of Admin role type. This operation is not appropriately restricted and allows the attacker to assume control over higher-privileged user-accounts. A malicious Domain Admin attacker can impersonate an Admin user-account and gain access to sensitive APIs and resources that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of infrastructure managed by CloudStack.
Users are recommended to upgrade to Apache CloudStack 4.19.3.0 or 4.20.1.0, which fixes the issue with the following:
* Strict validation on Role Type hierarchy: the caller's user-account role must be equal to or higher than the target user-account's role.
* API privilege comparison: the caller must possess all privileges of the user they are operating on.
* Two new domain-level settings (restricted to the default Admin):
- role.types.allowed.for.operations.on.accounts.of.same.role.type: Defines which role types are allowed to act on users of the same role type. Default: "Admin, DomainAdmin, ResourceAdmin".
- allow.operations.on.users.in.same.account: Allows/disallows user operations within the same account. Default: true. |
| A privilege escalation vulnerability exists in Apache CloudStack versions 4.10.0.0 through 4.20.0.0 where a malicious Domain Admin user in the ROOT domain can get the API key and secret key of user-accounts of Admin role type in the same domain. This operation is not appropriately restricted and allows the attacker to assume control over higher-privileged user-accounts. A malicious Domain Admin attacker can impersonate an Admin user-account and gain access to sensitive APIs and resources that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of infrastructure managed by CloudStack.
Users are recommended to upgrade to Apache CloudStack 4.19.3.0 or 4.20.1.0, which fixes the issue with the following:
* Strict validation on Role Type hierarchy: the caller's role must be equal to or higher than the target user's role.
* API privilege comparison: the caller must possess all privileges of the user they are operating on.
* Two new domain-level settings (restricted to the default admin):
- role.types.allowed.for.operations.on.accounts.of.same.role.type: Defines which role types are allowed to act on users of the same role type. Default: "Admin, DomainAdmin, ResourceAdmin".
- allow.operations.on.users.in.same.account: Allows/disallows user operations within the same account. Default: true. |
| When an Apache CloudStack user-account creates a CKS-based Kubernetes cluster in a project, the API key and the secret key of the 'kubeadmin' user of the caller account are used to create the secret config in the CKS-based Kubernetes cluster. A member of the project who can access the CKS-based Kubernetes cluster, can also access the API key and secret key of the 'kubeadmin' user of the CKS cluster's creator's account. An attacker who's a member of the project can exploit this to impersonate and perform privileged actions that can result in complete compromise of the confidentiality, integrity, and availability of resources owned by the creator's account.
CKS users are recommended to upgrade to version 4.19.3.0 or 4.20.1.0, which fixes this issue.Updating Existing Kubernetes Clusters in ProjectsA service account should be created for each project to provide limited access specifically for Kubernetes cluster providers and autoscaling. Follow the steps below to create a new service account, update the secret inside the cluster, and regenerate existing API and service keys:1. Create a New Service AccountCreate a new account using the role "Project Kubernetes Service Role" with the following details:
Account Name
kubeadmin-<FIRST_EIGHT_CHARACTERS_OF_PROJECT_ID>
First Name
Kubernetes
Last Name
Service User
Account Type
0 (Normal User)
Role ID
<ID_OF_SERVICE_ROLE>
2. Add the Service Account to the ProjectAdd this account to the project where the Kubernetes cluster(s) are hosted.
3. Generate API and Secret KeysGenerate API Key and Secret Key for the default user of this account.
4. Update the CloudStack Secret in the Kubernetes ClusterCreate a temporary file `/tmp/cloud-config` with the following data:
api-url = <API_URL> # For example: <MS_URL>/client/api
api-key = <SERVICE_USER_API_KEY>
secret-key = <SERVICE_USER_SECRET_KEY>
project-id = <PROJECT_ID>
Delete the existing secret using kubectl and Kubernetes cluster config:
./kubectl --kubeconfig kube.conf -n kube-system delete secret cloudstack-secret
Create a new secret using kubectl and Kubernetes cluster config:
./kubectl --kubeconfig kube.conf -n kube-system create secret generic cloudstack-secret --from-file=/tmp/cloud-config
Remove the temporary file:
rm /tmp/cloud-config5. Regenerate API and Secret KeysRegenerate the API and secret keys for the original user account that was used to create the Kubernetes cluster. |
| If untrusted users are allowed to configure JMS for Apache CXF, previously they could use RMI or LDAP URLs, potentially leading to code execution capabilities. This interface is now restricted to reject those protocols, removing this possibility.
Users are recommended to upgrade to versions 3.6.8, 4.0.9 or 4.1.3, which fix this issue. |
| Improper Control of Generation of Code ('Code Injection') vulnerability leading to a possible RCE in Apache OFBiz scrum plugin.
This issue affects Apache OFBiz: before 24.09.02 only when the scrum plugin is used.
Even unauthenticated attackers can exploit this vulnerability.
Users are recommended to upgrade to version 24.09.02, which fixes the issue. |
| Authentication Bypass Using an Alternate Path or Channel vulnerability in Apache Kylin.
This issue affects Apache Kylin: from 4.0.0 through 5.0.2.
Users are recommended to upgrade to version 5.0.3, which fixes the issue. |
| Critical XXE in Apache Tika (tika-parser-pdf-module) in Apache Tika 1.13 through and including 3.2.1 on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. An attacker may be able to read sensitive data or trigger malicious requests to internal resources or third-party servers. Note that the tika-parser-pdf-module is used as a dependency in several Tika packages including at least: tika-parsers-standard-modules, tika-parsers-standard-package, tika-app, tika-grpc and tika-server-standard.
Users are recommended to upgrade to version 3.2.2, which fixes this issue. |
| Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches.
This issue affects Apache Cassandra 3.0.30, 3.11.17, 4.0.16, 4.1.7, 5.0.2, but this advisory is only for 4.0.16 because the fix to CVE-2025-23015 was incorrectly applied to 4.0.16, so that version is still affected.
Users in the 4.0 series are recommended to upgrade to version 4.0.17 which fixes the issue. Users from 3.0, 3.11, 4.1 and 5.0 series should follow recommendation from CVE-2025-23015. |
| Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF.
This CVE covers the same vulnerability as in CVE-2025-54988. However, this CVE expands the scope of affected packages in two ways.
First, while the entrypoint for the vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2 would still be vulnerable.
Second, the original report failed to mention that in the 1.x Tika releases, the PDFParser was in the "org.apache.tika:tika-parsers" module. |
| Apache HTTP Server 2.4.65 and earlier with Server Side Includes (SSI) enabled and mod_cgid (but not mod_cgi) passes the shell-escaped query string to #exec cmd="..." directives.
This issue affects Apache HTTP Server before 2.4.66.
Users are recommended to upgrade to version 2.4.66, which fixes the issue. |
| A Deserialization of Untrusted Data vulnerability exists in the Apache ActiveMQ NMS AMQP Client.
This issue affects all versions of Apache ActiveMQ NMS AMQP up to and including 2.3.0, when establishing connections to untrusted AMQP servers. Malicious servers could exploit unbounded deserialization logic present in the client to craft responses that may lead to arbitrary code execution on the client side.
Although version 2.1.0 introduced a mechanism to restrict deserialization via allow/deny lists, the protection was found to be bypassable under certain conditions.
In line with Microsoft’s deprecation of binary serialization in .NET 9, the project is evaluating the removal of .NET binary serialization support from the NMS API entirely in future releases.
Mitigation and Recommendations:
Users are strongly encouraged to upgrade to version 2.4.0 or later, which resolves the issue. Additionally, projects depending on NMS-AMQP should migrate away from .NET binary serialization as part of a long-term hardening strategy. |
| Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat.
Tomcat did not escape ANSI escape sequences in log messages. If Tomcat was running in a console on a Windows operating system, and the console supported ANSI escape sequences, it was possible for an attacker to use a specially crafted URL to inject ANSI escape sequences to manipulate the console and the clipboard and attempt to trick an administrator into running an attacker controlled command. While no attack vector was found, it may have been possible to mount this attack on other operating systems.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.40 through 9.0.108.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.60 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue. |
| Relative Path Traversal vulnerability in Apache Tomcat.
The fix for bug 60013 introduced a regression where the rewritten URL was normalized before it was decoded. This introduced the possibility that, for rewrite rules that rewrite query parameters to the URL, an attacker could manipulate the request URI to bypass security constraints including the protection for /WEB-INF/ and /META-INF/. If PUT requests were also enabled then malicious files could be uploaded leading to remote code execution. PUT requests are normally limited to trusted users and it is considered unlikely that PUT requests would be enabled in conjunction with a rewrite that manipulated the URI.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.0.M11 through 9.0.108.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.6 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue. |
| API users via `/api/v2/dagReports` could perform Dag code execution in the context of the api-server if the api-server was deployed in the environment where Dag files were available. |
| An example dag `example_dag_decorator` had non-validated parameter that allowed the UI user to redirect the example to a malicious server and execute code on worker. This however required that the example dags are enabled in production (not default) or the example dag code copied to build your own similar dag. If you used the `example_dag_decorator` please review it and apply the changes implemented in Airflow 3.0.5 accordingly. |
| Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicy Apache Camel Keycloak component.
The Camel-Keycloak KeycloakSecurityPolicy does not validate the iss (issuer) claim of JWT tokens against the configured realm. A token issued by one Keycloak realm is silently accepted by a policy configured for a completely different realm, breaking tenant isolation.
This issue affects Apache Camel: from 4.15.0 before 4.18.0.
Users are recommended to upgrade to version 4.18.0, which fixes the issue. |
| Apache Superset utilizes a configurable dictionary, DISALLOWED_SQL_FUNCTIONS, to restrict the execution of potentially sensitive SQL functions within SQL Lab and charts. While this feature included restrictions for engines like PostgreSQL, a vulnerability was reported where the default list for the ClickHouse engine was incomplete.
This issue affects Apache Superset: before 4.1.2.
Users are recommended to upgrade to version 4.1.2, which fixes the issue. |
| An Improper Input Validation vulnerability exists in Apache Superset that allows an authenticated user with SQLLab access to bypass the read-only verification check when using a PostgreSQL database connection.
While the system effectively blocks standard Data Manipulation Language (DML) statements (e.g., INSERT, UPDATE, DELETE) on read-only connections, it fails to detect them in specially crafted SQL statements.
This issue affects Apache Superset: before 6.0.0.
Users are recommended to upgrade to version 6.0.0, which fixes the issue. |
| Apache Causeway faces Java deserialization vulnerabilities that allow remote code execution (RCE) through user-controllable URL parameters. These vulnerabilities affect all applications using Causeway's ViewModel functionality and can be exploited by authenticated attackers to execute arbitrary code with application privileges.
This issue affects all current versions.
Users are recommended to upgrade to version 3.5.0, which fixes the issue. |
| A remote code execution vulnerability exists where a malicious Raft node can exploit insecure Hessian deserialization within the PD store. The fix enforces IP-based authentication to restrict cluster membership and implements a strict class whitelist to harden the Hessian serialization process against object injection attacks.
Users are recommended to upgrade to version 1.7.0, which fixes the issue. |
