CVE-2026-86005: Chartbrew: Unauthenticated BullMQ Admin Dashboard Exposure in Chartbrew
Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 5.2.3, the administrative BullMQ dashboard was mounted without an authentication check. The vulnerable surface is the Bull Board/BullMQ administration dashboard at /apps/queues. A remote unauthenticated attacker reaches /apps/queues on a Chartbrew instance where Redis and BullMQ are enabled and a reverse proxy does not independently block the route. The dashboard trusted network reachability as authorization and exposed its queue-management interface directly. Redis and BullMQ must be enabled and the route must be reachable. Available actions depend on the installed Bull Board version and queue state, while confidentiality depends on job payload and log contents. An unauthenticated user can inspect exposed job payloads and logs and, when enabled by the installed version and queue state, retry or delete jobs or otherwise alter queue processing, affecting confidentiality, integrity, or availability. This issue is fixed in version 5.2.3.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Chartbrewto a version that resolves this vulnerability.Fixed in 5.2.3
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Chartbrew versions prior to 5.2.3 are exposed when Redis and BullMQ are enabled and the /apps/queues route is reachable. A reverse proxy that independently blocks that route prevents external reachability.
What does an attacker need to exploit it?
The attacker needs only network access to /apps/queues; no authentication is required. Exploitation depends on the BullMQ dashboard being available through a reachable Chartbrew instance.
What could an unauthenticated visitor do through the exposed dashboard?
They can inspect job payloads and logs exposed by the dashboard. Depending on the installed Bull Board version and queue state, they may also retry or delete jobs or otherwise alter queue processing.
What can be done if upgrading is not immediately possible?
Prevent access to /apps/queues at the reverse proxy or otherwise ensure the route is not reachable by untrusted users. The exposed dashboard relied on network reachability rather than an authentication check.
How can I determine whether a deployment is affected?
Check whether the Chartbrew version is earlier than 5.2.3, Redis and BullMQ are enabled, and /apps/queues can be reached without authentication. If all of these conditions apply, the queue-management dashboard is exposed.