CVE-2026-34072 is a high severity (CVSS 8.3) authentication bypass in Cronmaster, the web UI for managing cron jobs. When a session check fails, the middleware lets the request through. The maintainer fixed it in version 2.2.0, so upgrade and keep the UI off open networks.
What's affected
The NVD record says versions before 2.2.0. The project's advisory (GHSA-9whh-mffv-xvh6) lists 2.1.0 as the affected version and 2.2.0 as the patched one. Upgrade to 2.2.0 or later in either case.
The record's CVSS vector uses adjacent network access, which means the attacker needs to be on the same network segment, not on the open internet. That does not make it safe: many people run tools like this on a home or office network with other devices.
How to check if you're exposed
Check the running version against 2.2.0. For a container deployment, look at the image tag you pulled. For a source install, look at the version in the project files or the git tag you checked out.
Then ask how the UI is exposed. If a reverse proxy publishes Cronmaster to the internet, treat the vector as network reachable regardless of what the record says.
Cronmaster manages cron jobs, which run commands on the host. Review the existing cron entries for any you did not create, in the UI and in the host's crontab files.
For a Docker deployment, restart the container after upgrading and check that sign-in still works. Then try a request with a made-up session cookie against a protected page, in your own test copy, and confirm you are sent to the login page rather than shown content.
What to do now
- Find every Cronmaster instance and note its version.
- Upgrade to 2.2.0 or later.
- Review all cron jobs in the UI and in the crontab files for entries you did not add.
- Put the UI behind a VPN or an authenticating reverse proxy, so the application is not the only gate.
- Restart the application and test that an invalid cookie is rejected.
Why it matters
The record lists CWE-287 (improper authentication), CWE-306 (missing authentication for a critical function) and CWE-693 (protection mechanism failure). The advisory describes the cause: the middleware checks for a session cookie, asks an internal endpoint whether it is valid, and when that request throws an error it carries on as if the check had passed.
That pattern is called failing open. A security check should deny by default, so any error, timeout or unexpected response ends in a refusal. The same mistake appears in many gateways and middleware layers, and it is worth searching for in your own code.
The record does not mark this as exploited, and it is not on the CISA KEV list.
The practical rule for builders is to write the failure branch first. When a check throws, times out or returns something odd, the code should say no. Add a test that forces the session check to fail and confirms the request is refused.
Alongside the fix, keep the UI on a private network. A tool that edits cron jobs is a path to running commands on the host, so even a correct login check should not be the only barrier. A VPN or an authenticating reverse proxy in front gives you a second gate for very little effort.
Quick check
What does failing open mean?
A check that cannot reach a verdict lets the request pass instead of blocking it. Here an error in the session check meant access.
Sources
Last reviewed: 19 October 2026.
