Description

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, connection creation or update stored attacker-chosen absolute SSL and SSH file paths, and later connection cleanup passed those stored paths to fs.unlink without a path restriction. The vulnerable surface is data-connection certificate and SSH-key cleanup when a connection is removed. A user with createOwn and deleteOwn permissions on their own team stores a target path in a connection and then deletes the connection to trigger cleanup; default self-signup grants teamOwner these permissions. The cleanup routine treats the stored SSL or SSH path as a managed certificate path and unlinks the referenced file; duplicateConnection provides a second advisory-identified trigger. The attacker must be able to create or update and then delete a connection on their own team. The default container runs Chartbrew as uid 0, while deployments with a less-privileged process are limited by that process's deletion permissions. The attacker can delete files such as /code/.env or application source, causing integrity loss and service disruption. This issue is fixed in version 5.2.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-11-06T21:17:11.757Z",
  "pubdate": "2026-11-06T21:17:11.757Z",
  "executiveSummary": "Chartbrew versions prior to 5.2.3 are susceptible to an arbitrary file deletion vulnerability resulting from insecure handling of filesystem paths during the connection cleanup process. An attacker with standard team management permissions can supply arbitrary absolute file paths for SSL or SSH certificates when creating or updating a data connection. Upon the deletion of the affected connection, the application executes an fs.unlink operation on the user-supplied path without adequate validation or path confinement.\nThis vulnerability allows an authenticated attacker to delete critical system files, including application source code or environment configuration files (such as /code/.env), leading to significant service disruption and potential system integrity loss. The risk is amplified in default containerized deployments where the application process often runs with root (uid 0) privileges. Successful exploitation requires the ability to create, update, and delete a data connection within the attacker's team, a capability granted by default to users with createOwn and deleteOwn permissions.",
  "technicalDetails": "The vulnerability resides within the data-connection management module of Chartbrew, specifically in the logic responsible for the cleanup of associated SSL certificates and SSH keys. During the creation or modification of a data connection, the application accepts user-provided file paths intended for certificate or key storage. The root cause of this flaw is the failure to sanitize or validate these paths against an allowlist or root directory constraint, allowing the storage of arbitrary absolute filesystem paths.\nThe attack flow follows a predictable sequence: First, an authenticated attacker initiates a request to create or update a data connection, injecting a targeted absolute path (e.g., /code/.env) into the SSL or SSH certificate path fields. Because the backend accepts these inputs without verification, the malicious path is persisted in the application's database. Second, the attacker triggers the cleanup routine by deleting the connection via the interface or the duplicateConnection utility. This action invokes the cleanup service, which retrieves the stored path and passes it directly to the fs.unlink system call.\nBecause the fs.unlink operation is executed by the Node.js process running the application, the deletion is restricted only by the filesystem permissions of the OS user running the Chartbrew service. In default containerized environments, Chartbrew typically operates as uid 0 (root), granting the application total filesystem access. This enables an attacker to delete sensitive configuration files, source code, or binary artifacts, effectively causing an unrecoverable state for the application or enabling further post-exploitation activities.\nThe vulnerable component is the cleanup routine associated with data connection management. The flaw is present in all versions prior to 5.2.3. The exploitation process is highly reliable once the attacker has been assigned the default team-level permissions, requiring no complex race conditions or memory corruption techniques. The impact is categorized as an integrity and availability compromise, as the attacker can force the deletion of arbitrary files, leading to permanent service outage and loss of critical configuration data."
}