Description

Goploy is an open-source automation deployment system. In versions 1.17.5 and prior, Project.AddFile, Project.EditFile, Project.RemoveFile, and Project.Edit in cmd/server/api/project/handler.go accept a project or project-file row id from the JSON body and act on it without checking that the project belongs to the caller's namespace. The corresponding model.ProjectFile.GetData and model.Project.GetData queries filter only by row id. A user holding the manager role (or any role that includes the FileSync / EditProject permission) in their own namespace can read, write, or delete files in any project across the install, and can rewrite any project's git remote URL by submitting the foreign id in the body. The git-URL primitive escalates to RCE on the next deploy because Edit runs git remote set-url on the project's working tree. At time of publication, there are no known publicly available patches.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-08-31T19:16:50.880Z",
  "pubdate": "2026-08-31T19:16:50.880Z",
  "executiveSummary": "Goploy versions 1.17.5 and prior are susceptible to a severe authorization bypass vulnerability due to improper input validation in project and file management endpoints.\nThe vulnerability originates from the failure to verify ownership of project resources during administrative operations within the cmd/server/api/project/handler.go controller.\nAny authenticated user assigned the manager role—or any role possessing FileSync or EditProject permissions—can execute cross-namespace operations.\nAn attacker can manipulate files or modify project configurations, including git remote URLs, across arbitrary project environments regardless of their actual namespace assignment.\nThis vulnerability leads to unauthorized modification or deletion of sensitive infrastructure code and facilitates Remote Code Execution (RCE) by manipulating the git remote repository configuration, which triggers upon subsequent deployment operations.\nGiven that the system is an automation deployment platform, the integrity of managed deployments is entirely compromised, representing a critical risk to the software supply chain and infrastructure security of the hosting environment.",
  "technicalDetails": "The core vulnerability resides in the lack of identity and namespace validation within the handler functions located in cmd/server/api/project/handler.go, specifically within Project.AddFile, Project.EditFile, Project.RemoveFile, and Project.Edit.\nIn the affected versions, the application accepts a project or project-file primary key (row ID) from the JSON request body. The backend subsequently executes database queries via model.ProjectFile.GetData and model.Project.GetData that filter records strictly by the provided ID without verifying whether the identified resource is associated with the requester's authorized namespace.\nExploitation follows a predictable path: an attacker authenticated with standard managerial privileges identifies the target project ID belonging to another user or group. By submitting this foreign ID in a crafted request to the aforementioned handlers, the attacker bypasses logical boundaries, gaining full Create, Read, Update, and Delete (CRUD) access to files belonging to external projects.\nThe most critical impact stems from the exploitation of the Project.Edit handler. Because the application utilizes the git remote set-url command on the project's local working directory based on the user-provided input, an attacker can substitute the legitimate git remote URL with a malicious, attacker-controlled repository.\nWhen a user or automated trigger subsequently initiates a project deployment, the system performs a git pull operation against the attacker's repository. By embedding malicious scripts, hooks, or modified binary assets within the malicious repository, the attacker achieves arbitrary command execution with the privileges of the goploy service process.\nThis post-exploitation phase effectively turns the deployment system into a persistent backdoor, as subsequent deployments will continue to pull from the malicious source, allowing the attacker to maintain control over the infrastructure deployments managed by the victim instance.\nThe vulnerability is inherent to the application's design, where authorization is tied to role permissions rather than granular object-level ownership checks at the controller layer."
}