CVE-2026-80348 in TarsWeb
Summary
by MITRE • 08/26/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability in TarsWeb represents a critical failure in access control logic, specifically categorized under CWE-862 Missing Authorization. The core issue stems from an inconsistent implementation of role-based security checks within the PatchController module. While the application generally relies on AuthService to enforce per-application roles by invoking it from individual controller methods, four specific endpoints fail to perform this essential verification step. This architectural oversight creates a significant gap in the security perimeter, allowing authenticated users with limited privileges to execute actions that should be restricted to administrators or users with broader scope permissions. The flaw is not present in all related functions; for instance, uploadPatchPackage correctly checks developer authorization before storing packages, highlighting an inconsistency in how similar operations are secured across the codebase.
The most severe impact of this vulnerability lies within the uploadAndPublish method. This function accepts a package upload and subsequently builds and dispatches a deployment task to every server that matches the supplied application and module name. The only precondition enforced by this endpoint is that the target server must be registered in the system, which any authenticated user can satisfy if they know or discover valid server identifiers. Consequently, an attacker with access to even a single low-privileged account scoped to one unrelated application can upload malicious code and trigger its deployment across multiple servers managed by the console. This capability effectively bypasses isolation boundaries between applications, allowing lateral movement within the infrastructure and potential compromise of systems that should remain inaccessible to the specific user role.
Beyond remote code execution via package deployment, the vulnerability extends to data integrity and availability through other affected endpoints such as downloadPackage, deletePatchPackage, and setPatchPackageDefault. These methods select packages using an unscoped sequential primary key that covers uploads from every application in the installation. This design flaw means that any authenticated account can retrieve or delete packages belonging to completely different applications by simply manipulating the package identifier. Furthermore, setPatchPackageDefault allows a user to change which package is deployed as default for any given application. An attacker could exploit this to force the deployment of outdated, vulnerable, or malicious artifacts onto production systems, disrupting service availability and integrity without needing elevated privileges.
From an offensive security perspective, these actions map directly to MITRE ATT&CK techniques related to privilege escalation and lateral movement. The ability to deploy code across multiple servers aligns with T1059 Command and Scripting Interpreter execution via automated deployment tools, while the unauthorized access to other applications' data corresponds to T1078 Valid Accounts used for initial access followed by T1046 Network Service Discovery or T1005 Data from Local System. The lack of proper authorization checks allows an attacker to pivot from a low-privilege account to gaining control over critical infrastructure components, significantly expanding the blast radius of any single compromised credential.
Mitigation strategies must focus on enforcing consistent security controls across all controller methods and refining access policies. First, every method in PatchController.js that interacts with deployment or package management logic must invoke AuthService to verify that the current user has explicit authorization for the specific application context being accessed. This ensures that role-based restrictions are applied uniformly regardless of the endpoint. Second, the use of unscoped sequential primary keys for package selection should be replaced with scoped identifiers that tie each resource directly to its owning application or tenant ID. By validating that the requesting user owns or has permission over the specific resource identified by the key, the system can prevent cross-application data access and modification. Finally, implementing strict input validation on server identifiers used in deployment tasks is essential to ensure that deployments are only dispatched to servers explicitly authorized for the target application, thereby preventing unauthorized lateral movement across the infrastructure.