<?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>Sun, 04 Oct 2026 05:01:34 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-337355</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-337355</link>
      <description>EUVD-2026-337355</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-337355</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31892</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31892</link>
      <description>&lt;p&gt;Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. From 2.9.0 to before 4.0.2 and 3.7.11, A user who can submit Workflows can completely bypass all security settings defined in a WorkflowTemplate by including a podSpecPatch field in their Workflow submission. This works even when the controller is configured with templateReferencing: Strict, which is specifically documented as a mechanism to restrict users to admin-approved templates. The podSpecPatch field on a submitted Workflow takes precedence over the referenced WorkflowTemplate during spec merging and is applied directly to the pod spec at creation time with no security validation. This vulnerability is fixed in 4.0.2 and 3.7.11.&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. From 2.9.0 to before 4.0.2 and 3.7.11, A user who can submit Workflows can completely bypass all security settings defined in a WorkflowTemplate by including a podSpecPatch field in their Workflow submission. This works even when the controller is configured with templateReferencing: Strict, which is specifically documented as a mechanism to restrict users to admin-approved templates. The podSpecPatch field on a submitted Workflow takes precedence over the referenced WorkflowTemplate during spec merging and is applied directly to the pod spec at creation time with no security validation. This vulnerability is fixed in 4.0.2 and 3.7.11.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31892</guid>
    </item>
    <item>
      <title>GHSA-3wf5-g532-rcrr — Argo Workflows: WorkflowTemplate Security Bypass via podSpecPatch in Strict/Secure Reference Mode</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3wf5-g532-rcrr</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/argoproj/argo-workflows/v4, Go: github.com/argoproj/argo-workflows/v3, Go: github.com/argoproj/argo-workflows&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;A user who can submit Workflows can completely bypass all security settings defined in a `WorkflowTemplate` by including a `podSpecPatch` field in their Workflow submission. This works even when the controller is configured with `templateReferencing: Strict`, which is specifically documented as a mechanism to restrict users to admin-approved templates. The `podSpecPatch` field on a submitted Workflow takes precedence over the referenced `WorkflowTemplate` during spec merging and is applied directly to the pod spec at creation time with no security validation.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;Three issues combine to create this vulnerability:&lt;/p&gt;
&lt;p&gt;1. Merge priority order:`JoinWorkflowSpec` merges specs with the priority order Workflow Spec &amp;gt; WorkflowTemplate Spec &amp;gt; WorkflowDefault Spec. Because `podSpecPatch` is a plain string field, the Workflow&amp;#39;s value replaces the WorkflowTemplate&amp;#39;s value.&lt;/p&gt;
&lt;p&gt;2. No security validation on `podSpecPatch`: `ApplyPodSpecPatch()` only validates that the patch is syntactically valid JSON conforming to the Kubernetes `PodSpec` schema. No checks are performed for dangerous security settings such as `privileged: true`.&lt;/p&gt;
&lt;p&gt;3. `templateReferencing: Strict` does not restrict `podSpecPatch`: Strict mode only checks whether `WorkflowTemplateRef` is set. If it is, the Workflow passes validation regardless of what other fields (including `podSpecPatch`) are present.&lt;/p&gt;
&lt;p&gt;## PoC&lt;/p&gt;
&lt;p&gt;### Prerequisites&lt;/p&gt;
&lt;p&gt;A local Kubernetes cluster with Argo Workflows installed. The instructions bel…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/argoproj/argo-workflows/v4, Go: github.com/argoproj/argo-workflows/v3, Go: github.com/argoproj/argo-workflows&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;A user who can submit Workflows can completely bypass all security settings defined in a `WorkflowTemplate` by including a `podSpecPatch` field in their Workflow submission. This works even when the controller is configured with `templateReferencing: Strict`, which is specifically documented as a mechanism to restrict users to admin-approved templates. The `podSpecPatch` field on a submitted Workflow takes precedence over the referenced `WorkflowTemplate` during spec merging and is applied directly to the pod spec at creation time with no security validation.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;Three issues combine to create this vulnerability:&lt;/p&gt;
&lt;p&gt;1. Merge priority order:`JoinWorkflowSpec` merges specs with the priority order Workflow Spec &amp;gt; WorkflowTemplate Spec &amp;gt; WorkflowDefault Spec. Because `podSpecPatch` is a plain string field, the Workflow&amp;#39;s value replaces the WorkflowTemplate&amp;#39;s value.&lt;/p&gt;
&lt;p&gt;2. No security validation on `podSpecPatch`: `ApplyPodSpecPatch()` only validates that the patch is syntactically valid JSON conforming to the Kubernetes `PodSpec` schema. No checks are performed for dangerous security settings such as `privileged: true`.&lt;/p&gt;
&lt;p&gt;3. `templateReferencing: Strict` does not restrict `podSpecPatch`: Strict mode only checks whether `WorkflowTemplateRef` is set. If it is, the Workflow passes validation regardless of what other fields (including `podSpecPatch`) are present.&lt;/p&gt;
&lt;p&gt;## PoC&lt;/p&gt;
&lt;p&gt;### Prerequisites&lt;/p&gt;
&lt;p&gt;A local Kubernetes cluster with Argo Workflows installed. The instructions bel…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3wf5-g532-rcrr</guid>
    </item>
    <item>
      <title>RHSA-2026:10184 — Red Hat Security Advisory: RHOAI 2.25.5 - Red Hat OpenShift AI</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:10184</link>
      <description>&lt;p&gt;vllm: Server Side request forgery (SSRF) in MediaConnector feast: Feast: Remote Code Execution via insecure YAML deserialization openshift-ai: Trusty AI Grants All Authenticated users to list pods in any namespace nltk: Zip Slip Vulnerability in nltk Leading to Code Execution golang: net/url: Memory exhaustion in query parameter parsing in net/url golang: archive/zip: Excessive CPU consumption when building archive index in archive/zip crypto/x509: golang: Denial of Service due to excessive resource consumption via crafted certificate urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion urllib3: urllib3 Streaming API improperly handles highly compressed data cbor2: cbor2: Information Disclosure via shared memory in CBORDecoder reuse aiohttp: AIOHTTP&amp;#39;s HTTP Parser auto_decompress feature is vulnerable to zip bomb aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request python-markdown: denial of service via malformed HTML-like sequences nltk: NLTK: Arbitrary file read via improper path validation in `filestring()` function nltk: NLTK: Arbitrary file read via path traversal vulnerability io.vertx/vertx-core: static handler component cache can be manipulated to deny the access to static files google-cloud-aiplatform: google-cloud-aiplatform: Arbitrary code execution via Stored Cross-Site Scripting (XSS) tensorflow: TensorFlow: Local privilege escalation via…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;vllm: Server Side request forgery (SSRF) in MediaConnector feast: Feast: Remote Code Execution via insecure YAML deserialization openshift-ai: Trusty AI Grants All Authenticated users to list pods in any namespace nltk: Zip Slip Vulnerability in nltk Leading to Code Execution golang: net/url: Memory exhaustion in query parameter parsing in net/url golang: archive/zip: Excessive CPU consumption when building archive index in archive/zip crypto/x509: golang: Denial of Service due to excessive resource consumption via crafted certificate urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion urllib3: urllib3 Streaming API improperly handles highly compressed data cbor2: cbor2: Information Disclosure via shared memory in CBORDecoder reuse aiohttp: AIOHTTP&amp;#39;s HTTP Parser auto_decompress feature is vulnerable to zip bomb aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request python-markdown: denial of service via malformed HTML-like sequences nltk: NLTK: Arbitrary file read via improper path validation in `filestring()` function nltk: NLTK: Arbitrary file read via path traversal vulnerability io.vertx/vertx-core: static handler component cache can be manipulated to deny the access to static files google-cloud-aiplatform: google-cloud-aiplatform: Arbitrary code execution via Stored Cross-Site Scripting (XSS) tensorflow: TensorFlow: Local privilege escalation via…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:10184</guid>
    </item>
  </channel>
</rss>
