CVE-2026-109469

Chartbrew versions 4.8.5 through 5.2.2 allow an authenticated user with API connection management permissions to set the allowPrivateHost field, bypassing private and reserved-network destination restrictions. An upgrade migration also enables this override on pre-existing connections, and the per-connection setting takes precedence over CB_ALLOW_PRIVATE_NETWORK_CALLS. Successful exploitation allows requests to internal HTTP services reachable from the Chartbrew server.

UgCS server before 6.2 contains an authentication bypass in the HCI protocol login handler (LoginHandler) on TCP port 3334. When the user database contains exactly one user, a LoginRequest with empty userLogin and userPassword fields is interpreted as using the only user, and the server returns a fully authenticated session. The service listens on all interfaces (0.0.0.0) without TLS by default.

JupyterLab Desktop prior to 4.6.2-1 exposed getServerInfo to the renderer without confirming that the current page still had the local Jupyter server origin. In a local managed session using JupyterLab before 4.4.8, an attacker can place a crafted MathJax link in an untrusted notebook; if the victim clicks it, the renderer navigates to an attacker-controlled site that retains access to the preload bridge, calls getServerInfo to obtain the local server URL and authentication token, and uses the Jupyter REST API to create and trust a notebook that executes arbitrary code as the victim.

Chartbrew prior to 5.2.3 mounted the administrative BullMQ dashboard (Bull Board) at /apps/queues without an authentication check. A remote unauthenticated attacker who can reach that route on an instance with Redis and BullMQ enabled and no independent reverse-proxy block can inspect job payloads and logs and, depending on the installed version and queue state, retry or delete jobs or otherwise alter queue processing.

Chartbrew prior to 5.2.3 had four authentication helpers that accepted session tokens signed with CB_SECRET, including known, weak, or shipped-default values. In stock source or repository Docker Compose deployments retaining a default or weak CB_SECRET, an attacker can submit a forged HS256 token decoding to a target user id and impersonate that user across the API and socket layer without the password or two-factor authentication.

2FAuth prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard is enabled, reads the default REMOTE_USER identity header or a custom header selected by AUTH_PROXY_HEADER_FOR_USER without confirming that the request originated from a configured trusted proxy. A remote client that can reach the application directly can forge the identity header and authenticate as an existing user, including an administrator.

2FAuth prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard accepts authentication headers from a client that did not pass through a trusted proxy, RemoteUserProvider::retrieveById() creates an account for an unknown REMOTE_USER, promotes the first created account to administrator, and synchronizes the account email from the configured mail header. An unauthenticated remote client can create an administrator on a fresh instance or impersonate and redirect email for a known account.

Chartbrew prior to 5.2.1 used attacker-controlled JavaScript replacement strings unsafely in SQL dashboard-variable substitution across SQL connectors and failed to escape backslashes for MySQL and MariaDB quoted contexts. An unauthenticated user sending crafted URL filter values to a public or embedded chart backed by a stored SQL query can inject SQL and read, modify, or delete data available to the configured database account.

JupyterLab Desktop prior to 4.6.2-1 inserted remote-server URLs into the server-selection dialog and Welcome view without safe encoding. An attacker who convinces a user to submit a crafted URL can execute JavaScript in the Welcome renderer and abuse its privileged IPC bridge to execute arbitrary code with the user's privileges; a separate path involves unsafe rendering of RSS news-feed titles.

In Tracecat Docker Compose deployments with SAML enabled, versions 0.37.0 through 1.0.0-beta.49 can render SAML_SIGNED_ASSERTIONS and SAML_SIGNED_RESPONSES as empty values, disabling signature requirements. An unauthenticated attacker who can reach the SAML assertion consumer endpoint can submit a forged unsigned response for an existing user's email and obtain that user's session, including superadmin account takeover.