Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privileged Azkaban user
-
ExploitSend fetchSchedule request with arbitrary project/flow IDs
-
ExecutionBypass omitted permission check
-
ImpactRead other projects' schedule configuration
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a valid authenticated Azkaban account (PR:L) and access to the web server's ScheduleServlet fetchSchedule endpoint; the attacker then supplies arbitrary project and flow identifiers for projects they are not authorized to view. Affects Azkaban through version 4.0.0. Limiting factors: an authenticated session is mandatory (no anonymous exploitation), impact is read-only disclosure of schedule configuration (no write or code execution), and the attacker must know or guess valid project/flow identifiers, though these are often predictable. |
| Impact | This is an authorization flaw (CWE-862, missing project permission check) in Azkaban's ScheduleServlet fetchSchedule action. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N, 7.1) describes a network-reachable, low-complexity issue requiring low-privilege authentication (PR:L) with confidentiality-only impact (VC:H) and no integrity or availability effect - consistent with the description of an authenticated user reading other projects' schedule configuration. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so this reflects no public exploit identified at time of analysis. The VC:H rating is somewhat aggressive for what is disclosure of schedule metadata (cron expressions, execution times, flow parameters, notification emails) rather than credentials or code, but flow parameters and email lists can be sensitive, so it is defensible. Realistically this is a moderate-priority insecure-direct-object-reference/broken-access-control issue: it requires an existing authenticated account and yields only read access to configuration data, so it is not a drop-everything remote-code-execution class bug, but it is trivially exploitable by any logged-in user and provides useful reconnaissance for further attacks. |
| Exploit ScenarioDerived | A low-privileged authenticated Azkaban user issues a fetchSchedule request to ScheduleServlet supplying arbitrary project and flow identifiers belonging to projects they have no access to. Because the servlet omits the project permission check, the server returns the target project's schedule details - cron timing, flow parameters, and notification email lists - enabling reconnaissance of other teams' pipelines. No public exploit code was identified, but the attack requires only a standard authenticated account and crafted parameters. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Azkaban through 4.0.0 fails to enforce project-level permission checks in the ScheduleServlet fetchSchedule action, letting any authenticated user read the scheduling configuration of projects they do not own or have rights to. A logged-in attacker who supplies arbitrary project and flow identifiers can retrieve execution times, cron expressions, flow parameters, and notification email lists belonging to other teams. This is a read-only confidentiality exposure (CWE-862 missing authorization) with no code execution or data modification, exploitation requires a valid account (CVSS 3.1 PR:L), and no public exploit code or CISA KEV active-exploitation listing was identified at time of analysis.
RemediationAI
No vendor-released patch identified at time of analysis: the referenced GitHub issue (https://github.com/azkaban/azkaban/issues/3348) and the 4.0.0 source links document the flaw but the input data contains no fix version, commit, or patched release, so verify the issue thread and the project's release page before assuming a fix exists, and if the upstream project later publishes a patched tag, upgrade azkaban-web-server to that version. Until then, apply compensating controls: place the Azkaban web UI behind an authenticating reverse proxy or WAF rule that blocks direct calls to the ScheduleServlet fetchSchedule action (typically /schedule with an action=fetchSchedule parameter) for all users except a small scheduler-administrator group-this is effective but breaks legitimate read access for ordinary project owners, so it should be paired with a positive allowlist rather than a blanket block. Where source-level fixes are maintainable, backport a permission check in fetchSchedule that calls the project manager's authorization routine before returning schedule data; this is the cleanest control but requires rebuilding and re-deploying the web server. Additionally, restrict Azkaban account provisioning so that only trusted staff receive credentials (raising the cost of the mandatory authenticated session), treat schedule notification email lists and flow parameters as sensitive and rotate any secrets found embedded in flow parameters, and enable web-server access logging with alerting on anomalous iteration over project/flow identifiers, since enumeration of predictable IDs is the primary exploitation signal and produces a distinctive request pattern that the read-only impact otherwise leaves invisible.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Azkaban is a Java-based batch workflow scheduler originally developed at LinkedIn; its web tier exposes servlet endpoints under azkaban-web-server, and ScheduleServlet handles schedule management actions such as fetchSchedule. The vulnerability class is CWE-862 (Missing Authorization): the fetchSchedule handler at approximately lines 237-262 and 403-412 of azkaban-web-server/src/main/java/azkaban/webapp/servlet/ScheduleServlet.java retrieves schedule metadata keyed by caller-supplied project and flow identifiers without first calling the project-manager permission check that guards other actions. Because authorization is enforced inconsistently across sibling servlets rather than centrally, the endpoint inherits only the authentication gate from the session filter, not the per-project ACL. The affected CPE is cpe:2.3:a:azkaban:azkaban:*:*:*:*:*:*:*:*, i.e. all released Azkaban versions including the 4.0.0 containerization release, which shipped significant executor changes but no fix for this authorization path. Schedule objects in Azkaban encapsulate cron/quartz expressions, execution timing, flow parameter overrides, SLA and failure-email configuration, making them a useful reconnaissance target that can reveal infrastructure cadence, credentials embedded in flow parameters, and internal recipient addresses.
Know when Azkaban gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable servlet, low complexity, requires a low-privilege authenticated account (PR:L); confidentiality-only disclosure of schedule config, so I:N/A:N.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Azkaban through 4.0.0 omits project permission checks in the ScheduleServlet fetchSchedule action, allowing authenticated users to read any project's schedule configuration. Attackers can supply arbitrary project and flow identifiers to retrieve sensitive schedule details including execution times, cron expressions, flow parameters, and notification email lists without proper authorization.
Articles & Coverage 1
Executive ViewAI
Azkaban deployments running version 4.0.0 or earlier allow any authenticated user to read scheduling details from projects they do not own, exposing execution times, cron schedules, flow parameters, and notification email lists across team boundaries. This is a read-only confidentiality flaw with no code execution or data modification, and no public exploit identified at time of analysis, but the cross-project visibility can aid phishing, social engineering, and reconnaissance against shared workflow environments. Leadership should care because there is no vendor-released patch identified at time of analysis, and the issue affects trust boundaries for all authenticated Azkaban users.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict Azkaban access to trusted users and networks; enforce least privilege and disable unused accounts; enforce project-level authorization for ScheduleServlet fetchSchedule via reverse proxy, WAF, or custom servlet filter; monitor and alert on anomalous schedule-fetch requests and project/flow enumeration; segment Azkaban from high-sensitivity projects; review exposed schedules, flow parameters, and notification email lists for misuse.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
EUVD-2026-83027
GHSA-wcv9-64xq-42pp
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB