CVE-2026-93737: Azkaban Auth Bypass Vulnerability

CVE-2026-93737 Overview

CVE-2026-93737 is an authorization bypass vulnerability in Apache Azkaban through version 4.0.0. The flaw resides in the ScheduleServletfetchSchedule action, which omits project permission checks before returning schedule data. Any authenticated user can query arbitrary project and flow identifiers to read schedule configurations they are not authorized to view. Exposed data includes execution times, cron expressions, flow parameters, and notification email lists. The weakness is categorized as Missing Authorization [CWE-862].

Critical Impact
Authenticated attackers can enumerate and read sensitive schedule metadata across every project on an Azkaban server, exposing workflow logic, operational timing, and notification recipients that support downstream reconnaissance.

Affected Products

Azkaban workflow orchestration framework versions up to and including 4.0.0
azkaban-web-server component containing ScheduleServlet.java
Deployments exposing the Azkaban web UI to multi-tenant users

Discovery Timeline

2026-09-18 - CVE-2026-93737 published to the National Vulnerability Database
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93737

Vulnerability Analysis

Azkaban is an open-source batch workflow scheduler used to orchestrate Hadoop and data pipeline jobs. The web server enforces project-level permissions to control who can read, execute, or modify project workflows and schedules. The fetchSchedule action inside ScheduleServlet violates this model by returning schedule records based solely on the supplied projectId and flowId parameters. Authentication is required, but no membership or role check confirms the caller has access to the target project. Any logged-in user can iterate identifiers and retrieve schedules belonging to unrelated tenants.

The returned payload contains cron expressions, next execution times, submitter identity, flow-level parameters, and configured slaEmails for failure notifications. Attackers can use this data to map production workloads, predict execution windows for time-based attacks, harvest email addresses for phishing, and identify sensitive flow parameters that may embed environment or path information.

Root Cause

The root cause is missing authorization on a read-only API endpoint. The handler resolves the schedule directly from the schedule manager and serializes it into the response without invoking the permission helper used elsewhere in the servlet. Because the check is absent rather than misconfigured, no server-side setting mitigates the issue in vulnerable releases. The affected logic is documented in the ScheduleServletsource at lines 237-262 and lines 403-412.

Attack Vector

Exploitation requires network access to the Azkaban web server and any valid user account. The attacker issues authenticated HTTP GET requests to the /schedule endpoint with ajax=fetchSchedule and iterates numeric projectId and flowId values. Each successful response leaks the schedule configuration of a project the caller has no legitimate role in. Full technical detail is provided in the VulnCheck advisory and the upstream Azkaban issue #3348.

Detection Methods for CVE-2026-93737

Indicators of Compromise

Repeated authenticated requests to /schedule?ajax=fetchSchedule with sequentially incrementing projectId or flowId values from a single session.
Access patterns in Azkaban web server logs where a user retrieves schedules for projects on which they have no recorded membership.
Elevated response volume from the fetchSchedule action outside normal operator activity windows.

Detection Strategies

Parse Azkaban web access logs and correlate fetchSchedule requests against the project membership tables in the Azkaban metadata database to flag out-of-scope reads.
Deploy a web application firewall rule that rate-limits ajax=fetchSchedule calls per session and alerts on enumeration behavior.
Baseline typical per-user schedule read patterns and alert on statistical outliers, particularly accounts that suddenly query many distinct projectId values.

Monitoring Recommendations

Forward Azkaban web server logs to a central analytics platform and retain them long enough to reconstruct enumeration campaigns.
Monitor account creation and privilege changes for the Azkaban authentication backend, since any authenticated account is sufficient for exploitation.
Track outbound activity from hosts running Azkaban for signs of secondary abuse, such as phishing directed at addresses harvested from schedule notification lists.

How to Mitigate CVE-2026-93737

Immediate Actions Required

Restrict network access to the Azkaban web UI so that only trusted operator networks or VPN clients can reach the /schedule endpoint.
Audit Azkaban user accounts and disable any inactive, shared, or self-registered accounts that could be used to exercise the bypass.
Review schedule configurations and rotate any secrets, tokens, or email distribution lists that may have been exposed through unauthorized reads.

Patch Information

At the time of publication, no fixed release beyond 4.0.0 has been referenced by the advisory. Track the upstream Azkaban repository and 4.0.0 release notes for a patched build, and monitor the VulnCheck advisory for updates. Operators building from source can add the missing project permission check inside the fetchSchedule handler in ScheduleServlet.java before invoking the schedule lookup.

Workarounds

Place a reverse proxy in front of Azkaban that blocks or requires elevated authentication for requests containing ajax=fetchSchedule.
Segment Azkaban tenants across separate instances so that a single compromised account cannot enumerate schedules from unrelated projects.
Remove sensitive values from flow parameters and notification email fields until a patched version is deployed, reducing the value of any successful enumeration.

bash

# Example NGINX snippet to block unauthenticated enumeration of fetchSchedule
location /schedule {
    if ($arg_ajax = "fetchSchedule") {
        # Require internal network or authenticated proxy header
        set $allow 0;
        if ($remote_addr ~ "^10\.") { set $allow 1; }
        if ($allow = 0) { return 403; }
    }
    proxy_pass http://azkaban_backend;
}