<?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>Wed, 07 Oct 2026 00:29:10 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-326489</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-326489</link>
      <description>EUVD-2026-326489</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-326489</guid>
    </item>
    <item>
      <title>fkie_cve-2026-46617</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-46617</link>
      <description>&lt;p&gt;Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod&amp;#39;s automounted token was reachable from inside the user&amp;#39;s function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function&amp;#39;s namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests. This issue has been patched in version 1.23.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod&amp;#39;s automounted token was reachable from inside the user&amp;#39;s function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function&amp;#39;s namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests. This issue has been patched in version 1.23.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-46617</guid>
    </item>
    <item>
      <title>GHSA-85g2-pmrx-r49q — Fission runtime pods automount the fission-fetcher service-account token into the user function   container, granting f…</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-85g2-pmrx-r49q</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/fission/fission&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Fission runtime pods were created with `ServiceAccountName: fission-fetcher`, and the `fission-fetcher` ServiceAccount was granted namespace-wide `get` on `secrets` and `configmaps` (it needs that to load function code, env vars, and config). The runtime pod&amp;#39;s automounted token was reachable from inside the user&amp;#39;s function container at `/var/run/secrets/kubernetes.io/serviceaccount/token`, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function&amp;#39;s namespace — far beyond the `Function.spec.secrets` allowlist that the function specification suggests.&lt;/p&gt;
&lt;p&gt;### Affected component&lt;/p&gt;
&lt;p&gt;- `pkg/executor/executortype/poolmgr/gp_deployment.go:154-156` — pool-manager runtime pod `ServiceAccountName`.
- `pkg/executor/executortype/newdeploy/newdeploy.go:225-227` — new-deploy runtime pod `ServiceAccountName`.
- `pkg/utils/serviceaccount.go:51-64` — `fission-fetcher` RBAC: namespace-wide `get` on `secrets` / `configmaps`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:&lt;/p&gt;
&lt;p&gt;1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).
2. Read every configmap in that namespace.
3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.&lt;/p&gt;
&lt;p&gt;This violates the principle that `Function.spec.secrets` is the authoritative declaration of which secrets…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/fission/fission&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Fission runtime pods were created with `ServiceAccountName: fission-fetcher`, and the `fission-fetcher` ServiceAccount was granted namespace-wide `get` on `secrets` and `configmaps` (it needs that to load function code, env vars, and config). The runtime pod&amp;#39;s automounted token was reachable from inside the user&amp;#39;s function container at `/var/run/secrets/kubernetes.io/serviceaccount/token`, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function&amp;#39;s namespace — far beyond the `Function.spec.secrets` allowlist that the function specification suggests.&lt;/p&gt;
&lt;p&gt;### Affected component&lt;/p&gt;
&lt;p&gt;- `pkg/executor/executortype/poolmgr/gp_deployment.go:154-156` — pool-manager runtime pod `ServiceAccountName`.
- `pkg/executor/executortype/newdeploy/newdeploy.go:225-227` — new-deploy runtime pod `ServiceAccountName`.
- `pkg/utils/serviceaccount.go:51-64` — `fission-fetcher` RBAC: namespace-wide `get` on `secrets` / `configmaps`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:&lt;/p&gt;
&lt;p&gt;1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).
2. Read every configmap in that namespace.
3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.&lt;/p&gt;
&lt;p&gt;This violates the principle that `Function.spec.secrets` is the authoritative declaration of which secrets…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-85g2-pmrx-r49q</guid>
    </item>
  </channel>
</rss>
