CVE-2026-40162: Authenticated Arbitrary File Write in Bugsink Artifact Assembly

Bugsink is a self-hosted error tracking tool. Version 2.1.0 introduces a high-severity arbitrary file write vulnerability within the artifact bundle assembly workflow. The flaw centers on the application's failure to properly sanitize user input during temporary file creation.

The vulnerable endpoint resides at /api/0/organizations/{org}/artifactbundle/assemble/. The application relies on client-provided checksums to verify the integrity of uploaded chunks. However, the system utilizes this checksum directly as a filename component when constructing temporary storage paths.

Successful exploitation requires valid authentication credentials and access to the Bugsink API. An attacker can manipulate the checksum parameter to include path traversal sequences. This allows the writing of malicious payloads to arbitrary locations on the filesystem writable by the Bugsink process.

Version 2.1.1 resolves this issue. The patched version abandons named temporary files derived from user input in favor of anonymous unlinked file descriptors. This architectural change eliminates the path traversal vector entirely.

The root cause of CVE-2026-40162 is the improper limitation of a pathname to a restricted directory (CWE-22) combined with improper input validation (CWE-20). The application blindly trusts the user-supplied checksum string when managing file I/O operations in files/tasks.py.

During the artifact bundle assembly process, Bugsink iterates over previously uploaded file chunks and concatenates them. The application allocates a local filesystem path for this concatenated file using Path(tempdir, checksum). At this stage, no validation confirms that the user-provided checksum is a valid cryptographic hash or that it resolves safely within tempdir.

The application proceeds to write the combined chunk data to this attacker-controlled path. The critical flaw is a timing and logic error: the system only hashes the assembled file and compares it to the user's checksum after the write operation completes.

When the post-write validation inevitably fails due to the checksum mismatch, the application raises an exception and aborts the transaction. However, the filesystem modification has already occurred. The application does not revert or clean up the maliciously placed file, resulting in a permanent arbitrary file write.

Examining the vulnerable code path in files/tasks.py highlights the direct use of unsanitized input in filesystem operations. The application takes the checksum parameter from the JSON payload and passes it directly to the Path constructor.

# Vulnerable implementation in Bugsink 2.1.0
local_path = Path(tempdir, checksum)
 
# Application writes chunk data to local_path
write_chunks_to_file(chunks, local_path)
 
# Validation occurs too late, file is already written
if checksum_state.hexdigest() != checksum:
    raise Exception("checksum mismatch")

The fix implemented in commit 29e46f3737b15f6045073fb145ec936499e232f6 refactors this logic. The maintainers replaced the predictable, user-controlled named file with an anonymous temporary file descriptor provided by the standard library.

# Patched implementation in Bugsink 2.1.1
with tempfile.TemporaryFile(dir=tempdir) as local_file:
    # Application writes chunk data to the unlinked local_file descriptor
    write_chunks_to_file(chunks, local_file)
    
    # Validation occurs on the file descriptor before moving it to permanent storage
    if checksum_state.hexdigest() != checksum:
        raise Exception("checksum mismatch")

By utilizing tempfile.TemporaryFile, the operating system creates an anonymous unlinked file. The user input no longer influences the filesystem path, closing the path traversal vector. The checksum is now solely used for its intended purpose: post-assembly integrity validation.

Exploitation relies on a sequence of standard API interactions combined with a path traversal payload. An attacker must possess valid authentication headers to communicate with the Bugsink instance. The attack maps to MITRE ATT&CK technique T1190 (Exploit Public-Facing Application).

The attacker first uploads a sequence of malicious file chunks containing the intended payload, such as a Python reverse shell or an SSH public key. The server stores these chunks and returns identifiers to the attacker.

The attacker then sends a POST request to /api/0/organizations/{org}/artifactbundle/assemble/. Instead of providing a valid SHA1 hash for the checksum field, the attacker supplies a relative path traversal string, such as ../../../../opt/bugsink/settings.py.

The following Python proof-of-concept snippet demonstrates the precise payload structure required to trigger the vulnerability, as extracted from the official regression test in commit 1fc1076686792bdc66d97d079d1750e26a06d242.

# Extract from Bugsink regression test (Commit 1fc1076686)
self.client.post(
    "/api/0/organizations/anyorg/artifactbundle/assemble/",
    json.dumps({
        "checksum": "../../../../tmp/malicious.txt", 
        "chunks": [real_checksum], 
        "projects": ["unused"]
    }),
    content_type="application/json",
    headers=self.token_headers,
)

The vulnerability carries a CVSS v3.1 base score of 7.1, categorized as High severity. The core impact is a severe loss of integrity, allowing attackers to write or overwrite any file the Bugsink application process has permissions to modify.

In standard deployments, the arbitrary file write directly facilitates Remote Code Execution (RCE). An attacker can overwrite executable application files, such as .py source code or module initialization scripts. When the application server restarts or spawns a new worker, the malicious code executes automatically.

If the Bugsink application runs with elevated privileges or has overly broad filesystem permissions, the impact expands to complete system compromise. Attackers can write malicious entries to /etc/crontab or deploy SSH keys into the authorized_keys file of the application user.

The confidentiality impact is initially low, as the vulnerability does not directly expose data. However, successful RCE grants the attacker full access to the database credentials, application secrets, and any error telemetry data stored within the Bugsink environment.

The only complete remediation for CVE-2026-40162 is updating to Bugsink version 2.1.1. This release implements the structural changes required to separate user-provided integrity metadata from filesystem path construction.

Organizations unable to deploy the patch immediately must implement mitigation controls at the ingress point. Web Application Firewalls (WAF) should be configured to inspect POST payloads directed at /api/0/organizations/*/artifactbundle/assemble/ and /api/0/organizations/*/file/assemble/.

The WAF rule must strictly validate the checksum parameter against a restrictive regular expression. Specifically, the payload must drop any request where the checksum is not a 40-character hexadecimal string (^[a-fA-F0-9]{40}$). This explicitly prevents the inclusion of directory traversal sequences like ../.

Security operations teams should monitor application logs for anomalous behavior. A high volume of HTTP 500 errors originating from the assembly endpoints, coupled with repeated "checksum mismatch" internal application errors, is a strong indicator of active exploitation attempts.