CVE-2022-39395 - Exploiting Default Configurations in Vela CI/CD Pipelines for Container Breakouts

Vela is a popular open-source Pipeline Automation (CI/CD) framework built for speed and scalability using Linux containers and written in Go (Golang). It aims to automate software builds, tests, and deployments. But in late 2022, a critical security vulnerability was found that could let attackers break out of containers and compromise the host running Vela if administrators stuck with default settings.

In this post, we break down CVE-2022-39395—showing what went wrong, how it could be exploited, and what you should do to secure your Vela deployments.

What Is CVE-2022-39395?

CVE-2022-39395 is a vulnerability found in Vela Server and Vela Worker before version .16., and in Vela UI before .17.. The issue stemmed from insecure default configurations, particularly those around how containers were run and what repositories/processes could be enabled in builds.

Some Vela configurations allowed jobs to run containers in privileged mode out of the box.

- If exploited, attackers could use custom pipeline jobs to escape their containers and impact the underlying host.
- Default settings did not strictly restrict which repositories could execute code or use elevated container permissions.

Affected Versions

| Component | Safe Version |
|-----------|-------------|
| Vela Server | .16.+ |
| Vela Worker | .16.+ |
| Vela UI | .17.+ |

Create a build step that starts a container with dangerous capabilities.

- Break isolation and even mount sensitive files like the Docker socket, /etc/shadow, or other host resources.

Proof-of-Concept Example

The following Vela pipeline YAML could be used by an attacker to escape the container using a privileged container and access host resources:

steps:
  - name: breakout
    image: alpine
    privileged: true # This is allowed in insecure defaults!
    commands:
      - apk add --no-cache docker
      - docker ps  # or mount / access host files if /var/run/docker.sock is available

What happens here?
In the default (vulnerable) configuration, privileged: true is not blocked by the worker runtime. So the container runs with almost no isolation, giving access to host devices, sensitive paths, and the Docker socket if mounted—leading to full host compromise.

By default, too broad, letting unknown repos run arbitrary code.

Simple security guidance:  
If these aren't tightly controlled, users can run harmful code or privileged containers.

Official Security Advisory

- Vela's security team addressed the bug in GitHub's security advisory  
- Changelog for the fix: Server/Worker .16. Release Notes

Example Secure Worker Configuration

export VELA_RUNTIME_PRIVILEGED_IMAGES=""  # No privileged containers allowed

And for the server, only permit your main repo

export VELA_REPO_ALLOWLIST="github.com/myorg/myrepo"

Workarounds If You Can’t Upgrade Right Away

- Explicitly remove/lock down all privileged images:

`bash

export VELA_REPO_ALLOWLIST="github.com/myorg/project1,github.com/myorg/project2"

Audit existing enabled repos:

In the Vela UI or DB, disable unneeded/unknown repos and reduce pull request triggers.

Upgrading will change behavior and may break some existing pipelines.

This is on purpose: insecure pipelines shouldn’t run as before. Admins must update their settings and workflows after upgrading.

- If you don’t patch or lock down these settings, your host and CI/CD secrets are wide open to attackers.

- The best practice is always “least privilege”—never allow privileged: true for untrusted code!

References

- Original GitHub Security Advisory for CVE-2022-39395
- Vela Server .16. Release
- Vela Worker .16. Release
- Vela Documentation

Final Thoughts

Vela is a fast, flexible CI/CD tool built on container technology, but like many such systems, it is only as safe as its configuration. CVE-2022-39395 is a reminder: *never trust default settings, always limit privileges for build containers, and audit which repositories can run code on your infrastructure.*

Timeline

Published on: 11/10/2022 18:15:00 UTC
Last modified on: 11/17/2022 16:45:00 UTC