<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 18 Oct 2026 05:40:12 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-233429</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-233429</link>
      <description>EUVD-2026-233429</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-233429</guid>
    </item>
    <item>
      <title>fkie_cve-2022-39395</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-39395</link>
      <description>&lt;p&gt;Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. In Vela Server and Vela Worker prior to version 0.16.0 and Vela UI prior to version 0.17.0, some default configurations for Vela allow exploitation and container breakouts. Users should upgrade to Server 0.16.0, Worker 0.16.0, and UI 0.17.0 to fix the issue. After upgrading, Vela administrators will need to explicitly change the default settings to configure Vela as desired. Some of the fixes will interrupt existing workflows and will require Vela administrators to modify default settings. However, not applying the patch (or workarounds) will continue existing risk exposure. Some workarounds are available. Vela administrators can adjust the worker&amp;#39;s `VELA_RUNTIME_PRIVILEGED_IMAGES` setting to be explicitly empty, leverage the `VELA_REPO_ALLOWLIST` setting on the server component to restrict access to a list of repositories that are allowed to be enabled, and/or audit enabled repositories and disable pull_requests if they are not needed.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. In Vela Server and Vela Worker prior to version 0.16.0 and Vela UI prior to version 0.17.0, some default configurations for Vela allow exploitation and container breakouts. Users should upgrade to Server 0.16.0, Worker 0.16.0, and UI 0.17.0 to fix the issue. After upgrading, Vela administrators will need to explicitly change the default settings to configure Vela as desired. Some of the fixes will interrupt existing workflows and will require Vela administrators to modify default settings. However, not applying the patch (or workarounds) will continue existing risk exposure. Some workarounds are available. Vela administrators can adjust the worker&amp;#39;s `VELA_RUNTIME_PRIVILEGED_IMAGES` setting to be explicitly empty, leverage the `VELA_REPO_ALLOWLIST` setting on the server component to restrict access to a list of repositories that are allowed to be enabled, and/or audit enabled repositories and disable pull_requests if they are not needed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-39395</guid>
    </item>
    <item>
      <title>GHSA-5m7g-pj8w-7593 — Vela Insecure Defaults</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5m7g-pj8w-7593</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/go-vela/server, Go: github.com/go-vela/worker&lt;/p&gt;
&lt;p&gt;### Impact
Some current default configurations for Vela allow exploitation and container breakouts.&lt;/p&gt;
&lt;p&gt;#### Default Privileged Images&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Privileged containers permit trivial breakouts, which can pose significant risk to the environment in which Vela is running.&lt;/p&gt;
&lt;p&gt;#### Default Allowed Repositories&lt;/p&gt;
&lt;p&gt;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 could add their own malicious repos to the Vela instance and run arbitrary code.&lt;/p&gt;
&lt;p&gt;An example of a publicly accessible Vela instance would be one not protected behind a VPN. Whether Vela is publicly accessible depends on how Vela is set up, NOT how it is connected to GitHub.&lt;/p&gt;
&lt;p&gt;#### Default Enabled Events allows Pull Requests&lt;/p&gt;
&lt;p&gt;By default, Vela currently enables pull request events when a repository is Vela-enabled. Unless this default was changed when enabling each repository,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/go-vela/server, Go: github.com/go-vela/worker&lt;/p&gt;
&lt;p&gt;### Impact
Some current default configurations for Vela allow exploitation and container breakouts.&lt;/p&gt;
&lt;p&gt;#### Default Privileged Images&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Privileged containers permit trivial breakouts, which can pose significant risk to the environment in which Vela is running.&lt;/p&gt;
&lt;p&gt;#### Default Allowed Repositories&lt;/p&gt;
&lt;p&gt;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 could add their own malicious repos to the Vela instance and run arbitrary code.&lt;/p&gt;
&lt;p&gt;An example of a publicly accessible Vela instance would be one not protected behind a VPN. Whether Vela is publicly accessible depends on how Vela is set up, NOT how it is connected to GitHub.&lt;/p&gt;
&lt;p&gt;#### Default Enabled Events allows Pull Requests&lt;/p&gt;
&lt;p&gt;By default, Vela currently enables pull request events when a repository is Vela-enabled. Unless this default was changed when enabling each repository,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5m7g-pj8w-7593</guid>
    </item>
    <item>
      <title>gsd-2022-39395</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2022-39395</link>
      <description>gsd-2022-39395</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2022-39395</guid>
    </item>
  </channel>
</rss>
