https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 23:25:43 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-368242 EUVD-2026-368242 https://cve.radiocsirt.org/vuln/euvd-2026-368242 https://cve.radiocsirt.org/vuln/fkie_cve-2026-82438 <p>Description</p> <p>Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm&#39;s HTTP components served to an authenticated user.</p> <p>The Logviewer reflected the request&#39;s `Origin` header back in `Access-Control-Allow-Origin` while also sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive `Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to honour `*` together with credentials; reflecting the concrete origin removes that protection.</p> <p>The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name where an initialisation parameter name was expected. The container ignored the setting and applied its own defaults, which allow credentials.</p> <p>Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request. A script element on any origin can load such a response, which bypasses the same-origin policy entirely rather than negotiating it, and there was no way to turn the behaviour off.</p> <p>In each case the effect is that a page visited by an authenticated operator can read cluster, topology and log data on their behalf.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to false.</p> <p>Note that disabling J…</p> <p>Description</p> <p>Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm&#39;s HTTP components served to an authenticated user.</p> <p>The Logviewer reflected the request&#39;s `Origin` header back in `Access-Control-Allow-Origin` while also sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive `Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to honour `*` together with credentials; reflecting the concrete origin removes that protection.</p> <p>The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name where an initialisation parameter name was expected. The container ignored the setting and applied its own defaults, which allow credentials.</p> <p>Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request. A script element on any origin can load such a response, which bypasses the same-origin policy entirely rather than negotiating it, and there was no way to turn the behaviour off.</p> <p>In each case the effect is that a page visited by an authenticated operator can read cluster, topology and log data on their behalf.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to false.</p> <p>Note that disabling J…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-82438 https://cve.radiocsirt.org/vuln/ghsa-xf44-6rjp-v8cm <p>Description</p> <p>Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm&#39;s HTTP components served to an authenticated user.</p> <p>The Logviewer reflected the request&#39;s `Origin` header back in `Access-Control-Allow-Origin` while also sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive `Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to honour `*` together with credentials; reflecting the concrete origin removes that protection.</p> <p>The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name where an initialisation parameter name was expected. The container ignored the setting and applied its own defaults, which allow credentials.</p> <p>Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request. A script element on any origin can load such a response, which bypasses the same-origin policy entirely rather than negotiating it, and there was no way to turn the behaviour off.</p> <p>In each case the effect is that a page visited by an authenticated operator can read cluster, topology and log data on their behalf.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to false.</p> <p>Note that disabling J…</p> <p>Description</p> <p>Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm&#39;s HTTP components served to an authenticated user.</p> <p>The Logviewer reflected the request&#39;s `Origin` header back in `Access-Control-Allow-Origin` while also sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive `Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to honour `*` together with credentials; reflecting the concrete origin removes that protection.</p> <p>The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name where an initialisation parameter name was expected. The container ignored the setting and applied its own defaults, which allow credentials.</p> <p>Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request. A script element on any origin can load such a response, which bypasses the same-origin policy entirely rather than negotiating it, and there was no way to turn the behaviour off.</p> <p>In each case the effect is that a page visited by an authenticated operator can read cluster, topology and log data on their behalf.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to false.</p> <p>Note that disabling J…</p> https://cve.radiocsirt.org/vuln/ghsa-xf44-6rjp-v8cm