TarsWeb EUVD-2026-66387

The sole prerequisite is possession of any authenticated account in the TarsWeb installation, including accounts whose roles are scoped exclusively to a single unrelated application. The target server must be registered within the TarsWeb console - any registered server satisfies this condition. For downloadPackage and deletePatchPackage, exploitation further requires only knowledge or brute-force iteration of sequential integer package IDs, which are trivially enumerable. No special platform configuration, non-default feature flag, or elevated role is required. Exploitation is limited only by the requirement for prior authentication to TarsWeb; unauthenticated external attackers cannot exploit this without first obtaining credentials.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) accurately reflects the severity: network-reachable, low-complexity, requiring only a low-privilege account, with full CIA impact on the vulnerable system. The primary real-world risk is lateral movement within a shared TarsWeb installation - an attacker who compromises or legitimately holds any application-scoped account can pivot to deploy to every server the console manages, effectively achieving arbitrary remote code execution across the entire managed fleet. In environments with strict application team isolation this is especially damaging, and even a mid-sized municipal IT team in olsztyn operating a shared TarsCloud platform should treat this as urgent given the scope of the deployment blast radius. No KEV listing and no public exploit code are confirmed at time of analysis, so the threat is currently from insider abuse or post-authentication compromise scenarios rather than opportunistic scanning. EPSS data was not provided; exploitation is not automated at present but requires minimal skill once credentials are obtained. The inconsistency worth noting: the sibling method uploadPatchPackage does enforce authorization, confirming the omission is a code defect rather than a design choice, which strengthens the case that this is straightforwardly reproducible by any developer examining the source diff.

An attacker holding a valid TarsWeb account scoped only to a low-value internal test application crafts an HTTP request directly to the uploadAndPublish endpoint, supplying the name of a production application and its target server. TarsWeb accepts the request without checking the caller's role against the target application, builds a deployment task for the malicious package, and dispatches it to every matching registered server - achieving remote code execution on production infrastructure without any elevated privileges. No public exploit code is confirmed, but the exploitation path requires only knowledge of the API endpoint structure and a registered server name, both of which are observable within the console UI.