Focus on zenml vulnerabilities and metrics.
Last updated: 08 Mar 2025, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with zenml. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total zenml CVEs: 6
Earliest CVE date: 06 Jun 2024, 19:15 UTC
Latest CVE date: 08 Jun 2024, 20:15 UTC
Latest CVE reference: CVE-2024-4680
30-day Count (Rolling): 0
365-day Count (Rolling): 6
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 0.0
Max CVSS: 0
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 6 |
| 4.0-6.9 | 0 |
| 7.0-8.9 | 0 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for zenml, sorted by severity first and recency.
A vulnerability in zenml-io/zenml version 0.56.3 allows attackers to reuse old session credentials or session IDs due to insufficient session expiration. Specifically, the session does not expire after a password change, enabling an attacker to maintain access to a compromised account without the victim's ability to revoke this access. This issue was observed in a self-hosted ZenML deployment via Docker, where after changing the password from one browser, the session remained active and usable in another browser without requiring re-authentication.
A clickjacking vulnerability exists in zenml-io/zenml versions up to and including 0.55.5 due to the application's failure to set appropriate X-Frame-Options or Content-Security-Policy HTTP headers. This vulnerability allows an attacker to embed the application UI within an iframe on a malicious page, potentially leading to unauthorized actions by tricking users into interacting with the interface under the attacker's control. The issue was addressed in version 0.56.3.
An issue was discovered in zenml-io/zenml versions up to and including 0.55.4. Due to improper authentication mechanisms, an attacker with access to an active user session can change the account password without needing to know the current password. This vulnerability allows for unauthorized account takeover by bypassing the standard password change verification process. The issue was fixed in version 0.56.3.
A stored Cross-Site Scripting (XSS) vulnerability was identified in the zenml-io/zenml repository, specifically within the 'logo_url' field. By injecting malicious payloads into this field, an attacker could send harmful messages to other users, potentially compromising their accounts. The vulnerability affects version 0.55.3 and was fixed in version 0.56.2. The impact of exploiting this vulnerability could lead to user account compromise.
An improper authorization vulnerability exists in the zenml-io/zenml repository, specifically within the API PUT /api/v1/users/id endpoint. This vulnerability allows any authenticated user to modify the information of other users, including changing the `active` status of user accounts to false, effectively deactivating them. This issue affects version 0.55.3 and was fixed in version 0.56.2. The impact of this vulnerability is significant as it allows for the deactivation of admin accounts, potentially disrupting the functionality and security of the application.
A race condition vulnerability exists in zenml-io/zenml versions up to and including 0.55.3, which allows for the creation of multiple users with the same username when requests are sent in parallel. This issue was fixed in version 0.55.5. The vulnerability arises due to insufficient handling of concurrent user creation requests, leading to data inconsistencies and potential authentication problems. Specifically, concurrent processes may overwrite or corrupt user data, complicating user identification and posing security risks. This issue is particularly concerning for APIs that rely on usernames as input parameters, such as PUT /api/v1/users/test_race, where it could lead to further complications.