<?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 12:31:18 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-290511</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-290511</link>
      <description>EUVD-2026-290511</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-290511</guid>
    </item>
    <item>
      <title>fkie_cve-2026-39859</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-39859</link>
      <description>&lt;p&gt;LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.25.3, liquidjs 10.25.0 documents root as constraining filenames passed to renderFile() and parseFile(), but top-level file loads do not enforce that boundary. A Liquid instance configured with an empty temporary directory as root can return the contents of arbitrary files. This vulnerability is fixed in 10.25.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.25.3, liquidjs 10.25.0 documents root as constraining filenames passed to renderFile() and parseFile(), but top-level file loads do not enforce that boundary. A Liquid instance configured with an empty temporary directory as root can return the contents of arbitrary files. This vulnerability is fixed in 10.25.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-39859</guid>
    </item>
    <item>
      <title>GHSA-v273-448j-v4qj — LiquidJS: `renderFile()` / `parseFile()` bypass configured `root` and allow arbitrary file read</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-v273-448j-v4qj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: liquidjs&lt;/p&gt;
&lt;p&gt;`liquidjs` 10.25.0 documents `root` as constraining filenames passed to `renderFile()` and `parseFile()`, but top-level file loads do not enforce that boundary.&lt;/p&gt;
&lt;p&gt;The published npm package `liquidjs@10.25.0` on Linux 6.17.0 with Node v22.22.1. A `Liquid` instance configured with an empty temporary directory as `root` still returned the contents of `/etc/hosts` when `renderFile(&amp;#39;/etc/hosts&amp;#39;)` was called. I have not exhaustively checked older releases yet; 10.25.0 is the latest tested version.&lt;/p&gt;
&lt;p&gt;Root cause:
- `src/parser/parser.ts:83-85` calls `loader.lookup(file, LookupType.Root, ...)` and then reads the returned file.
- `src/fs/loader.ts:38` passes `type !== LookupType.Root` into `candidates()`.
- For `LookupType.Root`, `enforceRoot` is false, so `src/fs/loader.ts:47-66` accepts resolved absolute paths and fallback results without any `contains()` check.&lt;/p&gt;
&lt;p&gt;This appears adjacent to the March 10, 2026 fix for CVE-2026-30952, which hardened `include` / `render` / `layout` but not the top-level file-loading APIs.&lt;/p&gt;
&lt;p&gt;Proof of concept:
```javascript
const fs = require(&amp;#39;fs&amp;#39;);
const os = require(&amp;#39;os&amp;#39;);
const path = require(&amp;#39;path&amp;#39;);
const { Liquid } = require(&amp;#39;liquidjs&amp;#39;);&lt;/p&gt;
&lt;p&gt;const safeRoot = fs.mkdtempSync(path.join(os.tmpdir(), &amp;#39;liquidjs-safe-root-&amp;#39;));
const engine = new Liquid({ root: [safeRoot], extname: &amp;#39;.liquid&amp;#39; });&lt;/p&gt;
&lt;p&gt;engine.renderFile(&amp;#39;/etc/hosts&amp;#39;).then(console.log);
```&lt;/p&gt;
&lt;p&gt;Expected result: a path outside `root` should be rejected.
Actual result: `/etc/hosts` is rendered successfully.&lt;/p&gt;
&lt;p&gt;I…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: liquidjs&lt;/p&gt;
&lt;p&gt;`liquidjs` 10.25.0 documents `root` as constraining filenames passed to `renderFile()` and `parseFile()`, but top-level file loads do not enforce that boundary.&lt;/p&gt;
&lt;p&gt;The published npm package `liquidjs@10.25.0` on Linux 6.17.0 with Node v22.22.1. A `Liquid` instance configured with an empty temporary directory as `root` still returned the contents of `/etc/hosts` when `renderFile(&amp;#39;/etc/hosts&amp;#39;)` was called. I have not exhaustively checked older releases yet; 10.25.0 is the latest tested version.&lt;/p&gt;
&lt;p&gt;Root cause:
- `src/parser/parser.ts:83-85` calls `loader.lookup(file, LookupType.Root, ...)` and then reads the returned file.
- `src/fs/loader.ts:38` passes `type !== LookupType.Root` into `candidates()`.
- For `LookupType.Root`, `enforceRoot` is false, so `src/fs/loader.ts:47-66` accepts resolved absolute paths and fallback results without any `contains()` check.&lt;/p&gt;
&lt;p&gt;This appears adjacent to the March 10, 2026 fix for CVE-2026-30952, which hardened `include` / `render` / `layout` but not the top-level file-loading APIs.&lt;/p&gt;
&lt;p&gt;Proof of concept:
```javascript
const fs = require(&amp;#39;fs&amp;#39;);
const os = require(&amp;#39;os&amp;#39;);
const path = require(&amp;#39;path&amp;#39;);
const { Liquid } = require(&amp;#39;liquidjs&amp;#39;);&lt;/p&gt;
&lt;p&gt;const safeRoot = fs.mkdtempSync(path.join(os.tmpdir(), &amp;#39;liquidjs-safe-root-&amp;#39;));
const engine = new Liquid({ root: [safeRoot], extname: &amp;#39;.liquid&amp;#39; });&lt;/p&gt;
&lt;p&gt;engine.renderFile(&amp;#39;/etc/hosts&amp;#39;).then(console.log);
```&lt;/p&gt;
&lt;p&gt;Expected result: a path outside `root` should be rejected.
Actual result: `/etc/hosts` is rendered successfully.&lt;/p&gt;
&lt;p&gt;I…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-v273-448j-v4qj</guid>
    </item>
  </channel>
</rss>
