Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/go-vela/server < 0.25.3; >= 0.26.0, <= 0.26.2
Fixed in
0.25.30.26.3· Vendor fix available
Issue
Impact Users with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit. Any user with access to the CI instance and the linked source control manager can perform the exploit. Method By spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository. These secrets could be exfiltrated by follow up builds to the repository. Patches v0.26.3 — Image: target/vela-server:v0.26.3 v0.25.3 — Image: target/vela-server:v0.25.3 Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? There are no workarounds to the issue. References Are there any links users can visit to find out more? Please see linked CWEs (common weakness enumerators) for more information.
Recommended action: Upgrade to 0.26.3 or 0.25.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Vela pipelines can use variable substitution combined with insensitive fields like parameters, image and entrypoint to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking. Given by the following substitution examples: using parameters using image tag using entrypoint as a shim for commands To exploit this the pipeline author must be supplying the secrets to a plugin that is designed in such a way that will print those parameters in logs. Plugin parameters are not designed for sensitive values and are often intentionally printed throughout execution for informational/debugging purposes. Parameters should therefore be treated as…
Recommended action: Upgrade to 0.23.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Some current default configurations for Vela allow exploitation and container breakouts. Default Privileged Images Running Vela plugins as privileged Docker containers allows a malicious user to easily break out of the container and gain access to the worker host operating system. On a fresh install of Vela without any additional configuration, the target/vela-docker plugin will run as a privileged container, even if the Vela administrators did not intend to allow for any privileged plugins, and even if the vela.yml configuration file does not use the privileged = True flag. Privileged containers permit trivial breakouts, which can pose significant risk to the environment in which Vela is running. Default Allowed Repositories On a fresh install of Vela, anyone with a GitHub account (or other enabled source control management solution) is allowed to enable a repository within Vela and run builds. This means that, if a Vela instance is accessible to the public, a third party…
Recommended action: Upgrade to 0.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? The additional auth mechanism added within https://github.com/go-vela/server/pull/246 enables some malicious user to obtain secrets utilizing the injected credentials within the ~/.netrc file. Steps to reproduce 1. Create Vela server 2. Login to Vela UI 3. Promote yourself to Vela administrator - UPDATE users SET admin = 't' WHERE name = <username 4. Activate repository within Vela 5. Add .vela.yml to the repository with the following content 1. Look at build logs to find the following content 1. Copy the password to be utilized in some later step 1. Add secret(s) to activated repo 1. Copy the following script into main.go 1. Run the main.go with environment specific settings - VELASERVERADDR=http://localhost:8080 VELATOKEN=<token obtained previously go run main.go The previously posted script could be updated to utilize any API endpoint(s) the activated user has access against. Patches Has the problem been patched? What…
Recommended action: Upgrade to 0.7.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.