Description

GoCD is a continuous deliver server. Prior to 26.1.0, the internal GoCD UI /jobStatus.json API does not validate that a requested server-assigned job ID belongs to the pipeline and stage named in the request. An authenticated user can guess job IDs and retrieve status for jobs in pipelines the user cannot otherwise view, including job names, state, progress timestamps, assigned agent IP addresses and UUIDs, and associated stages and pipelines. The response does not expose console output, artifacts, commands, variables, or configuration. This issue is fixed in version 26.1.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-21T15:17:28.950Z",
  "pubdate": "2026-09-21T15:17:28.950Z",
  "executiveSummary": "GoCD prior to version 26.1.0 is susceptible to an Insecure Direct Object Reference (IDOR) vulnerability within the /jobStatus.json API.\nThe vulnerability allows an authenticated attacker to bypass authorization controls and retrieve sensitive metadata associated with arbitrary jobs, even those belonging to pipelines for which the attacker lacks viewing permissions.\nBy manipulating job identifiers in API requests, unauthorized users can harvest information including job names, operational states, progress timestamps, and detailed agent infrastructure data, such as IP addresses and UUIDs.\nThis represents a significant information disclosure risk that could facilitate reconnaissance for further lateral movement or supply chain attacks.\nExploitation requires a valid user account within the GoCD environment, but no administrative privileges are necessary to access restricted job metadata.\nThe vulnerability highlights a failure in input validation logic where the server fails to verify the relationship between the requested job ID and the specified pipeline or stage context.",
  "technicalDetails": "The root cause of this vulnerability lies in an authorization bypass within the /jobStatus.json API endpoint of the GoCD server. The application fails to perform adequate access control checks to ensure that the authenticated user possesses the appropriate permissions to view the requested job resource.\nSpecifically, the API logic does not enforce a binding between the user's session-based authorization context and the requested job ID. When a request is submitted, the backend fails to validate that the requested job identifier properly maps to the provided pipeline and stage parameters. This lack of server-side validation permits an attacker to perform unauthorized lookups.\nAn attacker can exploit this by iterating through predictable job IDs. Because the application blindly processes the request if the job ID exists in the system, an authenticated attacker can systematically query the API to disclose state and infrastructure information for pipelines they are not authorized to access. The attack flow involves capturing or crafting a request to /jobStatus.json and injecting arbitrary job IDs into the request body or parameters.\nThe information exposed via this API includes the job name, current execution state, exact progress timestamps, and specific infrastructure details such as the host agent's IP address and unique agent UUID. While the vulnerability does not expose sensitive payloads such as console output, build artifacts, environment variables, or secret configuration data, the exposure of infrastructure metadata significantly increases the attack surface.\nThe disclosure of agent UUIDs and IP addresses provides an attacker with a mapping of the internal build infrastructure, which can be leveraged to identify high-value targets or to inform subsequent attacks on the underlying agent nodes. This vulnerability affects all GoCD versions prior to 26.1.0.\nThe attack is performed via standard HTTP requests and does not require complex payloads or exploitation of memory safety flaws; it is a purely logical authorization failure. The requirement for prior authentication acts as a minor barrier but does not mitigate the risk posed by malicious or compromised insider accounts. The issue was addressed in version 26.1.0 through the implementation of strict validation checks that confirm the user's authorization to access the specific job object before returning the status response."
}