This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Gocd
GoCD is a continuous delivery server. GoCD versions 19.11.0 through 21.4.0 (inclusive) are vulnerable to a Document Object Model (DOM)-based cross-site scripting attack via a pipeline run's Stage Details > Graphs tab. It is possible for a malicious script on a attacker-hosted site to execute script that will run within the user's browser context and GoCD session via abuse of a messaging channel used for communication between with the parent page and the stage details graph's iframe. This could allow an attacker to steal a GoCD user's session cookies and/or execute malicious code in the user's context. This issue is fixed in GoCD 22.1.0. There are currently no known workarounds. (2022-05-20, CVE-2022-29182)
GoCD is a continuous delivery server. GoCD versions 20.2.0 until 21.4.0 are vulnerable to reflected cross-site scripting via abuse of the pipeline comparison function's error handling to render arbitrary HTML into the returned page. This could allow an attacker to trick a victim into executing code which would allow the attacker to operate on, or gain control over the same resources as the victim had access to. This issue is fixed in GoCD 21.4.0. As a workaround, block access to `/go/compare/.*` prior to GoCD Server via a reverse proxy, web application firewall or equivalent, which would prevent use of the pipeline comparison function. (2022-05-20, CVE-2022-29183)
An issue was discovered in ThoughtWorks GoCD before 21.3.0. An attacker in control of a GoCD Agent can plant malicious JavaScript into a failed Job Report. (2022-04-14, CVE-2021-43288)
Why Cross-site Scripting can be dangerous
Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.
The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:
https://server.com/confirmation?message=Transaction+Complete
what results in:
<span>Confirmation: Transaction Complete</span>
In that case the message can be modified to become a valid Javascript code, e.g.:
https://server.com/confirmation?message=<script>dangerous javascript code here</script>
and it will be executed locally by the user's browser with full access to the user's personal application/browser data:
<span>Confirmation: <script>dangerous javascript code here</script></span>