CVE-2026-80348: TarsWeb Authentication Bypass Vulnerability

CVE-2026-80348 Overview

CVE-2026-80348 is a missing authorization vulnerability [CWE-862] in TarsWeb, the management console for the Tars microservice framework. The flaw resides in app/controller/patch/PatchController.js, where four endpoints skip the AuthService role check that TarsWeb applies elsewhere. The affected methods are uploadAndPublish, downloadPackage, deletePatchPackage, and setPatchPackageDefault. Any authenticated account, including one scoped to an unrelated application, can push and deploy packages to any server managed by the console, retrieve or delete other applications' packages, and change the default package an application deploys. TarsWeb through version 3.0.16 is affected.

Critical Impact
An authenticated low-privileged user can deploy arbitrary packages to any server the TarsWeb console manages, resulting in full compromise of hosted microservices.

Affected Products

TarsCloud TarsWeb through version 3.0.16
Tars microservice framework deployments using TarsWeb as the management console
Any server registered with a vulnerable TarsWeb installation

Discovery Timeline

2026-08-26 - CVE-2026-80348 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-80348

Vulnerability Analysis

TarsWeb enforces per-application role-based access control by invoking AuthService from individual controller methods rather than through centralized middleware. This design pattern requires every sensitive endpoint to explicitly call the authorization check. Four methods in PatchController.js omit the call entirely, leaving them accessible to any authenticated session.

The uploadAndPublish method accepts a package upload, then builds and dispatches a deployment task to every server matching the supplied application and module name. Its only precondition is that the named server is registered in the installation. Notably, the sibling uploadPatchPackage method, which only stores the package, does verify developer authorization first.

The downloadPackage and deletePatchPackage methods select a package by an unscoped sequential primary key that spans every application's uploads. The setPatchPackageDefault method changes which package a given application deploys by default, without checking whether the caller has any rights over that application.

Root Cause

The root cause is inconsistent enforcement of authorization checks across controller methods [CWE-862]. Because authorization is applied per method rather than through a global filter, developer oversight in four methods bypasses the entire per-application role model.

Attack Vector

An attacker requires only a valid TarsWeb account with any role, including one scoped to a single unrelated application. Over the network, the attacker calls the unprotected endpoints directly. By supplying an arbitrary application and module name of a registered server, the attacker triggers uploadAndPublish to deploy a malicious package to production servers under other applications' control. Because package primary keys are sequential and unscoped, package enumeration through downloadPackage and deletePatchPackage is trivial.

See the VulnCheck Advisory on TarsWeb and the TarsWeb PatchController source for technical details.

Detection Methods for CVE-2026-80348

Indicators of Compromise

Unexpected deployment tasks in TarsWeb audit logs referencing applications the requesting user does not own
HTTP requests to /pages/server/api/upload_and_publish, /pages/server/api/download_package, /pages/server/api/delete_patch_package, or /pages/server/api/set_patch_package_default originating from accounts without corresponding application roles
Unexplained package files added to the patch repository or default package assignments changed without a matching change request

Detection Strategies

Correlate authenticated session identity with the target application name in PatchController requests, and alert when the user lacks a role scoped to that application
Baseline normal deploy activity per user and flag deviations, particularly cross-application deploys from developer accounts
Review TarsWeb access logs for enumeration patterns against sequential package IDs on the download and delete endpoints

Monitoring Recommendations

Forward TarsWeb application and web server logs to a centralized platform such as Singularity Data Lake for retention and query
Monitor the underlying servers for unexpected process execution following deployment tasks, using endpoint telemetry
Alert on new or modified files under Tars deployment directories that were not preceded by an authorized change ticket

How to Mitigate CVE-2026-80348

Immediate Actions Required

Restrict network access to the TarsWeb console so that only trusted administrative networks can reach the API endpoints
Audit all TarsWeb user accounts and disable or reduce accounts that no longer require access
Review deployment history in the patch subsystem for unauthorized uploadAndPublish invocations and validate the integrity of deployed packages
Track upstream fix status in TarsWeb Issue #213 and apply the vendor patch when released

Patch Information

At the time of publication, no fixed release beyond v3.0.16 has been identified in the referenced advisory. Monitor the TarsWeb repository for a release that adds AuthService calls to uploadAndPublish, downloadPackage, deletePatchPackage, and setPatchPackageDefault in PatchController.js.

Workarounds

Place the TarsWeb console behind an authenticating reverse proxy that limits access to specific administrator identities
Apply a local patch that adds an AuthService authorization check at the start of each of the four affected controller methods, mirroring the pattern used by uploadPatchPackage
Segment TarsWeb from internet-facing networks and require VPN or bastion access for management operations

bash

# Example nginx snippet restricting access to the TarsWeb patch API endpoints
location ~ ^/pages/server/api/(upload_and_publish|download_package|delete_patch_package|set_patch_package_default) {
    allow 10.0.0.0/24;   # admin subnet
    deny  all;
    proxy_pass http://tarsweb_upstream;
}