<?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://vulnerability.circl.lu</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>Wed, 07 Oct 2026 17:57:29 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-106106</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-106106</link>
      <description>&lt;p&gt;Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0, renderSSRError() in utils/render-ssr-error/src/index.js used diagnostic data from utils/render-ssr-error/src/env.js to serialize process.env, request headers, and cookies into the HTTP page returned by serve.devError(), while the development server listened on all interfaces by default. Any network-adjacent client that reaches an SSR or SSG render failure through this development-only error path can obtain shell environment secrets. The renderer escaped only one exact lowercase script closing-tag spelling, so case variants and valid closing-tag delimiter variants in reflected diagnostic data could terminate the script element and inject markup; executing the injected code in a developer browser additionally requires the payload to accompany that developer&amp;#39;s request. This issue is fixed in @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0, renderSSRError() in utils/render-ssr-error/src/index.js used diagnostic data from utils/render-ssr-error/src/env.js to serialize process.env, request headers, and cookies into the HTTP page returned by serve.devError(), while the development server listened on all interfaces by default. Any network-adjacent client that reaches an SSR or SSG render failure through this development-only error path can obtain shell environment secrets. The renderer escaped only one exact lowercase script closing-tag spelling, so case variants and valid closing-tag delimiter variants in reflected diagnostic data could terminate the script element and inject markup; executing the injected code in a developer browser additionally requires the payload to accompany that developer&amp;#39;s request. This issue is fixed in @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-106106</guid>
    </item>
    <item>
      <title>GHSA-r5mf-4r5x-q78f — Quasar Framework: SSR/SSG dev error page discloses the full shell environment and its &lt;/script&gt; escape is bypassable</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-r5mf-4r5x-q78f</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @quasar/render-ssr-error, npm: @quasar/app-vite&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The error page that Quasar CLI shows when an SSR or SSG render throws in development serializes every variable in `process.env`, every request header and every cookie into the HTTP response, and the dev server binds `0.0.0.0` by default. Any host that can reach the port therefore gets the developer&amp;#39;s cloud keys, registry tokens and database URLs from a single unauthenticated GET. The same page embeds that data inside a `&amp;lt;script&amp;gt;` element behind a `replaceAll(&amp;#39;&amp;lt;/script&amp;gt;&amp;#39;, ...)` guard that is ASCII-case-sensitive and requires a literal `&amp;gt;`, so `&amp;lt;/SCRIPT&amp;gt;`, `&amp;lt;/script &amp;gt;` and `&amp;lt;/script/&amp;gt;` all escape the element and give script execution in the dev server&amp;#39;s origin.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`renderSSRError()` builds the page by splicing a JSON blob into a prebuilt bundle (`utils/render-ssr-error/src/index.js`):&lt;/p&gt;
&lt;p&gt;```js
errorHtml:
  before +
  JSON.stringify(data).replaceAll(&amp;#39;&amp;lt;/script&amp;gt;&amp;#39;, String.raw`&amp;lt;\/script&amp;gt;`) +
  after
```&lt;/p&gt;
&lt;p&gt;`before` and `after` are the two halves of the compiled error-page UI, split inside a `&amp;lt;script type=&amp;#34;module&amp;#34;&amp;gt;` element, so `data` is emitted as a JS object literal in raw script text. The data itself comes from `utils/render-ssr-error/src/env.js`:&lt;/p&gt;
&lt;p&gt;```js
function getEnvironmentVariablesData () {
  return Object.keys(process.env).reduce((acc, name) =&amp;gt; {
    acc[ name ] = process.env[ name ]
    return acc
  }, {})
}&lt;/p&gt;
&lt;p&gt;export function getEnv (req) {
  return {
    Request: getRequestData(req),
    Headers: getHeadersData(req),
    Cookies: getCookiesData(req),…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @quasar/render-ssr-error, npm: @quasar/app-vite&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The error page that Quasar CLI shows when an SSR or SSG render throws in development serializes every variable in `process.env`, every request header and every cookie into the HTTP response, and the dev server binds `0.0.0.0` by default. Any host that can reach the port therefore gets the developer&amp;#39;s cloud keys, registry tokens and database URLs from a single unauthenticated GET. The same page embeds that data inside a `&amp;lt;script&amp;gt;` element behind a `replaceAll(&amp;#39;&amp;lt;/script&amp;gt;&amp;#39;, ...)` guard that is ASCII-case-sensitive and requires a literal `&amp;gt;`, so `&amp;lt;/SCRIPT&amp;gt;`, `&amp;lt;/script &amp;gt;` and `&amp;lt;/script/&amp;gt;` all escape the element and give script execution in the dev server&amp;#39;s origin.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`renderSSRError()` builds the page by splicing a JSON blob into a prebuilt bundle (`utils/render-ssr-error/src/index.js`):&lt;/p&gt;
&lt;p&gt;```js
errorHtml:
  before +
  JSON.stringify(data).replaceAll(&amp;#39;&amp;lt;/script&amp;gt;&amp;#39;, String.raw`&amp;lt;\/script&amp;gt;`) +
  after
```&lt;/p&gt;
&lt;p&gt;`before` and `after` are the two halves of the compiled error-page UI, split inside a `&amp;lt;script type=&amp;#34;module&amp;#34;&amp;gt;` element, so `data` is emitted as a JS object literal in raw script text. The data itself comes from `utils/render-ssr-error/src/env.js`:&lt;/p&gt;
&lt;p&gt;```js
function getEnvironmentVariablesData () {
  return Object.keys(process.env).reduce((acc, name) =&amp;gt; {
    acc[ name ] = process.env[ name ]
    return acc
  }, {})
}&lt;/p&gt;
&lt;p&gt;export function getEnv (req) {
  return {
    Request: getRequestData(req),
    Headers: getHeadersData(req),
    Cookies: getCookiesData(req),…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-r5mf-4r5x-q78f</guid>
    </item>
  </channel>
</rss>
