Description

TarsWeb enforces its per-application roles by calling AuthService from individual controller methods, and four methods in app/controller/patch/PatchController.js make no such call. uploadAndPublish accepts a package upload and then builds and dispatches a deployment task to every server matching the supplied application and module name, while its sibling uploadPatchPackage, which only stores the package, does check developer authorization first. The only precondition uploadAndPublish enforces is that the named server is registered, and any registered server in the installation satisfies it. downloadPackage and deletePatchPackage select a package by an unscoped sequential primary key covering every application's uploads, and setPatchPackageDefault changes which package a given application deploys by default. Any authenticated account, including one holding a role scoped to a single unrelated application, can therefore push a package to and trigger its deployment on any server the console manages, retrieve or delete any other application's package, and change which package is deployed by default.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-26T10:16:42.947Z",
  "pubdate": "2026-08-26T10:16:42.947Z",
  "executiveSummary": "TarsWeb suffers from a critical broken access control vulnerability originating in the app/controller/patch/PatchController.js component. The application fails to enforce per-application authorization checks on key administrative methods, allowing authenticated users with limited scope—such as those restricted to a single, unrelated application—to perform unauthorized actions across the entire installation. This vulnerability impacts the PatchController by exposing critical functions that handle package management and deployment orchestration. An attacker can exploit this flaw to perform unauthorized code uploads, trigger global deployment tasks on arbitrary servers, manipulate package metadata, and delete sensitive patches belonging to other applications. The primary risk involves complete integrity compromise of the application deployment pipeline, as any authenticated user can effectively bypass organizational boundaries to influence the state of any managed server within the TarsWeb environment. Exploitation requires minimal privileges, specifically requiring only a valid session within the TarsWeb console, as the system fails to validate authorization tokens against the requested resource scope.",
  "technicalDetails": "The vulnerability resides within app/controller/patch/PatchController.js, where the implementation fails to invoke the AuthService to perform mandatory access control checks. While TarsWeb generally employs per-application role enforcement, four specific methods in the PatchController lack these security barriers: uploadAndPublish, uploadPatchPackage (partial enforcement discrepancy), downloadPackage, deletePatchPackage, and setPatchPackageDefault.\nThe root cause is a failure to implement consistent authorization logic across controller methods. Specifically, the uploadAndPublish method accepts package uploads and subsequently dispatches deployment tasks to any server matching the provided application and module names. The only security validation performed is checking if the target server is registered; because any registered server satisfies this condition, an attacker can push malicious packages to any server managed by the platform. The logic assumes that if a server exists in the database, the request is legitimate, completely ignoring the identity and role-based permissions of the requestor.\nFurthermore, the methods downloadPackage and deletePatchPackage utilize an insecure object identification scheme. These functions retrieve or destroy package data based on an unscoped, sequential primary key. Since this key is not cryptographically tied to a specific application or owner, an authenticated attacker can enumerate or provide arbitrary IDs to manipulate resources belonging to any application in the infrastructure. Similarly, the setPatchPackageDefault function lacks scoped validation, allowing any authenticated user to alter the deployment configuration for any application, effectively forcing the deployment of an attacker-controlled package version globally.\nThe attack flow proceeds as follows: 1) An attacker authenticates to the TarsWeb console with low-level privileges (e.g., restricted to a non-sensitive application). 2) The attacker identifies the target application or server they wish to compromise. 3) The attacker interacts directly with the vulnerable PatchController endpoints, bypassing the UI-based scope restrictions. 4) By passing the manipulated application/module parameters or sequential primary keys, the attacker executes unauthorized actions. For instance, an attacker can upload a crafted package via uploadAndPublish and trigger an immediate deployment to a server belonging to an unauthorized application. 5) Post-exploitation, the attacker maintains the ability to delete or overwrite legitimate patch files and modify the default deployment configuration, facilitating long-term persistent access and service disruption."
}