Semaphore UI: Default-Config Command Injection Lets Project Managers Get RCE on the Server (CVE-2026-73294)

A newly published GitHub Security Advisory (GHSA-xp7j-h7jc-4w8p, CVE-2026-73294, CVSS 9.9) describes an OS command injection in Semaphore UI, the open-source CI/CD and automation platform. According to the advisory, any user holding the standard Manager or Owner role on a project can achieve remote code execution on the Semaphore server host by supplying a malicious git_url value when creating a repository.

What was reported

The advisory states the vulnerability stems from Semaphore passing an attacker-controlled git_url field into a git ls-remote command without validating it for option injection and without a -- argument separator. Because git supports a --upload-pack=<cmd> option, a value like --upload-pack=<command>;true causes git to execute the supplied command via a shell. The advisory reports this is triggered automatically when a project schedule references the malicious repository: the server's built-in schedule poller calls the vulnerable git-fetch logic directly in the main Semaphore server process — not inside a remote runner — so it reportedly still fires even when jobs are configured to run on remote runners. Per the advisory, this is reproducible on a default install (git_client: cmd_git) with no non-default configuration required, and a working proof-of-concept is included in the report.

Why it matters for defenders

If accurate, this significantly lowers the bar for a full-host compromise: the required privilege (Manager/Owner on any single project) is a routine collaborator role, not an admin role, and per the advisory becomes trivially reachable by any authenticated user if non_admin_can_create_project is enabled, since users can self-create and own a project. The advisory notes the impact extends beyond the host shell — because the exploit runs in the main server process, it reportedly exposes the master encryption key and the secrets of every project on the instance, and bypasses the isolation remote runners are meant to provide. Any organization running self-hosted Semaphore UI for infrastructure automation should treat this as a priority to assess.

What defenders should watch for or do now

• Check whether you operate Semaphore UI, identify the version, and monitor the vendor repository/advisory for an official patched release and upgrade guidance.
• Review who currently holds Manager or Owner roles on each project, and treat those roles as high-privilege pending a fix — the advisory shows they are sufficient for host RCE.
• If patching isn't immediately available, consider disabling non_admin_can_create_project, restricting who can add repositories or schedules, and auditing existing repositories for suspicious git_url values (e.g., strings beginning with --upload-pack= or other leading-dash values).
• Hunt for anomalous process execution or outbound network connections originating from the Semaphore server process itself (as opposed to job/runner processes), and review scheduler logs for unexpected repository commit-hash check activity.
• Consider network-egress restrictions on the Semaphore server host, since the described exploit relies on the server being able to reach back out to an attacker listener.

Developing intel

This is net-new intel published today and based solely on the linked GitHub Security Advisory; there is no confirmation yet of in-the-wild exploitation, and details may be updated by the vendor or researchers. We will track this item for updates. For full technical details and the referenced proof-of-concept, see the original advisory: GHSA-xp7j-h7jc-4w8p.