<?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>Sat, 03 Oct 2026 10:34:53 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-337242</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-337242</link>
      <description>EUVD-2026-337242</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-337242</guid>
    </item>
    <item>
      <title>fkie_cve-2026-42296</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-42296</link>
      <description>&lt;p&gt;Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Prior to versions 3.7.14 and 4.0.5, a user with create Workflow permission can bypass templateReferencing: Strict to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature. The practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like hostNetwork). Clusters that rely on Argo&amp;#39;s Strict mode as the primary enforcement layer are fully exposed. This issue has been patched in versions 3.7.14 and 4.0.5.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Prior to versions 3.7.14 and 4.0.5, a user with create Workflow permission can bypass templateReferencing: Strict to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature. The practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like hostNetwork). Clusters that rely on Argo&amp;#39;s Strict mode as the primary enforcement layer are fully exposed. This issue has been patched in versions 3.7.14 and 4.0.5.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-42296</guid>
    </item>
    <item>
      <title>GHSA-3775-99mw-8rp4 — Argo has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing…</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3775-99mw-8rp4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/argoproj/argo-workflows/v3, Go: github.com/argoproj/argo-workflows/v4&lt;/p&gt;
&lt;p&gt;The fix for CVE-2026-31892 (commit 534f4ff) blocks `podSpecPatch` when `templateReferencing: Strict` is active, but doesn&amp;#39;t restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set `hostNetwork: true`, override `serviceAccountName`, or change `securityContext` on their Workflow while referencing a hardened template -- these survive `JoinWorkflowSpec` and get applied at pod creation.&lt;/p&gt;
&lt;p&gt;The check in `setExecWorkflow` gates on `HasPodSpecPatch()` only:&lt;/p&gt;
&lt;p&gt;```go
if woc.controller.Config.WorkflowRestrictions.MustUseReference() &amp;amp;&amp;amp; woc.wf.Spec.HasPodSpecPatch() {
```&lt;/p&gt;
&lt;p&gt;Everything else passes through. `createWorkflowPod` reads `hostNetwork`, `securityContext`, `serviceAccountName`, `tolerations`, and `automountServiceAccountToken` from the merged spec and applies them directly to the pod.&lt;/p&gt;
&lt;p&gt;`JoinWorkflowSpec` constructs the merge target from the user&amp;#39;s spec and applies the template as a patch -- user fields take priority. When the template doesn&amp;#39;t explicitly set a field like `hostNetwork` (most won&amp;#39;t -- `false` is the zero value and gets omitted), the user&amp;#39;s `true` survives. For fields like `securityContext` and `serviceAccountName`, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.&lt;/p&gt;
&lt;p&gt;Both `Strict` and `Secure` modes are affected. `Secure` stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent `Mus…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/argoproj/argo-workflows/v3, Go: github.com/argoproj/argo-workflows/v4&lt;/p&gt;
&lt;p&gt;The fix for CVE-2026-31892 (commit 534f4ff) blocks `podSpecPatch` when `templateReferencing: Strict` is active, but doesn&amp;#39;t restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set `hostNetwork: true`, override `serviceAccountName`, or change `securityContext` on their Workflow while referencing a hardened template -- these survive `JoinWorkflowSpec` and get applied at pod creation.&lt;/p&gt;
&lt;p&gt;The check in `setExecWorkflow` gates on `HasPodSpecPatch()` only:&lt;/p&gt;
&lt;p&gt;```go
if woc.controller.Config.WorkflowRestrictions.MustUseReference() &amp;amp;&amp;amp; woc.wf.Spec.HasPodSpecPatch() {
```&lt;/p&gt;
&lt;p&gt;Everything else passes through. `createWorkflowPod` reads `hostNetwork`, `securityContext`, `serviceAccountName`, `tolerations`, and `automountServiceAccountToken` from the merged spec and applies them directly to the pod.&lt;/p&gt;
&lt;p&gt;`JoinWorkflowSpec` constructs the merge target from the user&amp;#39;s spec and applies the template as a patch -- user fields take priority. When the template doesn&amp;#39;t explicitly set a field like `hostNetwork` (most won&amp;#39;t -- `false` is the zero value and gets omitted), the user&amp;#39;s `true` survives. For fields like `securityContext` and `serviceAccountName`, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.&lt;/p&gt;
&lt;p&gt;Both `Strict` and `Secure` modes are affected. `Secure` stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent `Mus…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3775-99mw-8rp4</guid>
    </item>
    <item>
      <title>RHSA-2026:73987 — Red Hat Security Advisory: RHOAI 3.3.7 - Red Hat OpenShift AI</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:73987</link>
      <description>&lt;p&gt;golang: net/url: Memory exhaustion in query parameter parsing in net/url urllib3: urllib3 Streaming API improperly handles highly compressed data nltk: NLTK: Arbitrary Code Execution via Eval Injection in Collocations Module undici: Undici: HTTP Request Smuggling and Denial of Service due to duplicate Content-Length headers undici: undici: Denial of Service via unbounded memory consumption during WebSocket permessage-deflate decompression undici: undici: Denial of Service via crafted WebSocket frame with large length undici: Undici: Denial of Service via invalid WebSocket permessage-deflate extension parameter jupyter-server: jupyter-server: Sensitive data exposure via path traversal vulnerability fast-uri: fast-uri: Path traversal vulnerability allows bypass of security policies undici: undici: Information disclosure and data integrity issues due to incorrect Socks5ProxyAgent connection routing undici: undici: Man-in-the-Middle attack via ignored TLS options with SOCKS5 proxy keras: Keras: Arbitrary file write via path traversal in archive extraction utilities sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 undici: undici: Denial of Service due to unbounded memory growth via WebSocket frames brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity guardrails-detectors: guardrails-detectors: Unauthenticated Regular-Expression…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;golang: net/url: Memory exhaustion in query parameter parsing in net/url urllib3: urllib3 Streaming API improperly handles highly compressed data nltk: NLTK: Arbitrary Code Execution via Eval Injection in Collocations Module undici: Undici: HTTP Request Smuggling and Denial of Service due to duplicate Content-Length headers undici: undici: Denial of Service via unbounded memory consumption during WebSocket permessage-deflate decompression undici: undici: Denial of Service via crafted WebSocket frame with large length undici: Undici: Denial of Service via invalid WebSocket permessage-deflate extension parameter jupyter-server: jupyter-server: Sensitive data exposure via path traversal vulnerability fast-uri: fast-uri: Path traversal vulnerability allows bypass of security policies undici: undici: Information disclosure and data integrity issues due to incorrect Socks5ProxyAgent connection routing undici: undici: Man-in-the-Middle attack via ignored TLS options with SOCKS5 proxy keras: Keras: Arbitrary file write via path traversal in archive extraction utilities sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 undici: undici: Denial of Service due to unbounded memory growth via WebSocket frames brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity guardrails-detectors: guardrails-detectors: Unauthenticated Regular-Expression…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:73987</guid>
    </item>
  </channel>
</rss>
