What is the CVSS score of CVE-2026-44615?

CVE-2026-44615 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.5%.

Is there a patch available for CVE-2026-44615?

Yes, a patch is available for CVE-2026-44615. Update the affected software to the latest version immediately.

Apache Zeppelin CVE-2026-44615

EUVD-2026-51524 MEDIUM

Path Traversal (CWE-22)

2026-07-30

GHSA-5j5v-r5qf-p5c4

Apache Path Traversal Zeppelin

6.5

CVSS 3.1 · Vendor

Severity by source

Vendor (CNA) PRIMARY

6.5 LOW

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

7.6 HIGH

PR:L for required authentication plus rename/folder permission; I:H for out-of-bounds file write and delete capability; C:L for indirect file exposure via move operations; A:L since deletion is scoped to server process access.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (CNA).

CVSS VectorVendor

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

CVSS changed

Jul 31, 2026 - 17:22 NVD

6.5 (MEDIUM)

Patch available

Jul 31, 2026 - 12:02 EUVD

Analysis Generated

Jul 30, 2026 - 12:18 vuln.today

Description PRE-NVD

Disclosed via oss-security. NVD scoring and full description are pending.

AnalysisAI

Path traversal in Apache Zeppelin's FileSystemNotebookRepo backend (versions 0.9.0 through 0.12.0) allows authenticated users with note-rename or folder-operation permissions to escape the configured notebook root directory on the server's filesystem or HDFS. By injecting directory traversal sequences into note or folder path values, an attacker can cause Zeppelin to move, write, or delete files anywhere the server process identity has access - potentially overwriting arbitrary files outside the notebook root. No public exploit has been identified and exploitation requires specific authenticated access plus a non-default storage backend configuration.

Technical ContextAI

Apache Zeppelin is a web-based multi-language analytics notebook supporting Spark, SQL, Python, and R, with a pluggable notebook persistence layer. When FileSystemNotebookRepo or HadoopFileSystemNotebookRepo is selected, notebooks are persisted on the local filesystem or HDFS using the Zeppelin server's OS or Hadoop principal identity. The root cause is a classic CWE-22 (Path Traversal) failure: Zeppelin composed user-supplied note names and folder path components directly into filesystem paths without first canonicalizing or bounding the result to the configured notebook root. A path value such as '../../etc/cron.d/target' concatenated with the notebook base directory yields a path that escapes containment entirely. The fix in version 0.12.1, implemented via GitHub PRs #5227 and #5248, adds sanitization logic to enforce that all composed paths remain within the notebook root before any filesystem operation is performed. The Hadoop identity dimension is noteworthy: in cluster deployments, traversal scope extends to all HDFS paths accessible to the configured Hadoop service principal.

RemediationAI

The primary remediation is to upgrade Apache Zeppelin to version 0.12.1, which addresses the path traversal through sanitization added in PRs #5227 (https://github.com/apache/zeppelin/pull/5227) and #5248 (https://github.com/apache/zeppelin/pull/5248). Version 0.12.1 is confirmed as the fix release by the vendor advisory at https://zeppelin.apache.org/ and the oss-security disclosure. If immediate upgrade is not feasible, three compensating controls should be applied in combination: first, tighten Zeppelin's internal authorization to restrict note-rename and folder-operation permissions to the minimum required set of principals, reducing the pool of accounts that can supply attacker-controlled path values; second, ensure the Zeppelin server process runs under a least-privilege OS account with filesystem access scoped exclusively to the notebook root directory, which bounds the blast radius of any successful traversal; third, consider switching to a non-filesystem notebook backend (such as S3NotebookRepo or a database-backed store) to eliminate the vulnerable code path entirely, though this requires a notebook migration effort. Note that the first two controls reduce risk but do not eliminate the vulnerability as long as any user retains rename or folder permissions.