<?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>Tue, 06 Oct 2026 13:32:22 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-277500</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-277500</link>
      <description>EUVD-2026-277500</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-277500</guid>
    </item>
    <item>
      <title>fkie_cve-2026-33320</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-33320</link>
      <description>&lt;p&gt;Dasel is a command-line tool and library for querying, modifying, and transforming data structures. Starting in version 3.0.0 and prior to version 3.3.1, Dasel&amp;#39;s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library&amp;#39;s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4&amp;#39;s built-in alias expansion limit. Version 3.3.2 contains a patch for the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Dasel is a command-line tool and library for querying, modifying, and transforming data structures. Starting in version 3.0.0 and prior to version 3.3.1, Dasel&amp;#39;s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library&amp;#39;s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4&amp;#39;s built-in alias expansion limit. Version 3.3.2 contains a patch for the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-33320</guid>
    </item>
    <item>
      <title>GHSA-4fcp-jxh7-23x8 — Dasel has unbounded YAML alias expansion in dasel leads to CPU/memory denial of service</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-4fcp-jxh7-23x8</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/tomwright/dasel/v3&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`dasel`&amp;#39;s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library&amp;#39;s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4&amp;#39;s built-in alias expansion limit.&lt;/p&gt;
&lt;p&gt;The issue issue is on `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`) and on the current default branch at commit `0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad`. It is also verified the same code path is present in `v3.0.0` (`648f83baf070d9e00db8ff312febef857ec090a3`). A 342-byte payload did not complete within 5 seconds on the test system and exhibited unbounded resource growth.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`), the reachable call path is:&lt;/p&gt;
&lt;p&gt;- The YAML reader is registered in [`parsing/yaml/yaml.go`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml.go) and exposed via `parsing.Format(&amp;#34;yaml&amp;#34;).NewReader()`
- `(*yamlReader).Read` in [`parsing/yaml/yaml_reader.go#L23-L48`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L23-L48) uses `yaml.NewDecoder` to decode the input. Because `yamlValue` implements `UnmarshalYAML(*yaml.Node)`, the decoder passes the raw `*yaml.Node` tree to that custom unmarshaler
- `(*yamlValue).UnmarshalYAML` in [`parsing/yaml/yaml_reader.…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/tomwright/dasel/v3&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`dasel`&amp;#39;s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library&amp;#39;s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4&amp;#39;s built-in alias expansion limit.&lt;/p&gt;
&lt;p&gt;The issue issue is on `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`) and on the current default branch at commit `0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad`. It is also verified the same code path is present in `v3.0.0` (`648f83baf070d9e00db8ff312febef857ec090a3`). A 342-byte payload did not complete within 5 seconds on the test system and exhibited unbounded resource growth.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`), the reachable call path is:&lt;/p&gt;
&lt;p&gt;- The YAML reader is registered in [`parsing/yaml/yaml.go`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml.go) and exposed via `parsing.Format(&amp;#34;yaml&amp;#34;).NewReader()`
- `(*yamlReader).Read` in [`parsing/yaml/yaml_reader.go#L23-L48`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L23-L48) uses `yaml.NewDecoder` to decode the input. Because `yamlValue` implements `UnmarshalYAML(*yaml.Node)`, the decoder passes the raw `*yaml.Node` tree to that custom unmarshaler
- `(*yamlValue).UnmarshalYAML` in [`parsing/yaml/yaml_reader.…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-4fcp-jxh7-23x8</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-33320</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33320</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:24.04:LTS: dasel, Ubuntu:25.10: dasel, Ubuntu:26.04:LTS: dasel&lt;/p&gt;
&lt;p&gt;Dasel is a command-line tool and library for querying, modifying, and transforming data structures. Starting in version 3.0.0 and prior to version 3.3.1, Dasel&amp;#39;s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library&amp;#39;s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4&amp;#39;s built-in alias expansion limit. Version 3.3.2 contains a patch for the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:24.04:LTS: dasel, Ubuntu:25.10: dasel, Ubuntu:26.04:LTS: dasel&lt;/p&gt;
&lt;p&gt;Dasel is a command-line tool and library for querying, modifying, and transforming data structures. Starting in version 3.0.0 and prior to version 3.3.1, Dasel&amp;#39;s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library&amp;#39;s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4&amp;#39;s built-in alias expansion limit. Version 3.3.2 contains a patch for the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33320</guid>
    </item>
  </channel>
</rss>
