<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-31T16:53:22.201026+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-118761</id>
    <title>fkie_cve-2026-118761</title>
    <updated>2026-10-31T16:53:22.202653+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the API server decompressed uploaded pipeline archives without adequately bounding expanded data while locating or reading the pipeline file. A small ZIP or gzip-compressed tar archive can consume disproportionately large memory and exhaust API-server resources. Multipart pipeline and pipeline-version upload processing performs decompression before namespace authorization, so a reachable caller does not need a successful pipeline-create authorization decision. URL-import handlers authorize before fetching and decompressing a remote archive. The amount of expansion required to interrupt service depends on deployment resource limits and concurrent activity, and no specific archive is guaranteed to crash every deployment. This issue is fixed in version 2.18.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-118761"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-8fmv-6rg5-5924</id>
    <title>GHSA-8fmv-6rg5-5924 — Kubeflow Pipelines: Pipeline archive upload allows decompression bomb to exhaust server memory</title>
    <updated>2026-10-31T16:53:22.202713+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/kubeflow/pipelines</p>
<p>## Summary</p>
<p>The Kubeflow Pipelines API server decompresses uploaded pipeline archives without adequately bounding expanded data in affected versions. A small ZIP or gzip-compressed tar archive can consume disproportionately large amounts of memory while the server locates or reads the pipeline file, potentially exhausting API-server resources and interrupting service.</p>
<p>Multipart pipeline and pipeline-version upload processing decompresses the archive before namespace authorization, so a caller who can reach those endpoints does not need a successful pipeline-create authorization decision to trigger the issue. External authentication and network controls can restrict reachability. URL-import handlers authorize before fetching and decompressing a remote archive.</p>
<p>The amount of expansion needed to exhaust memory depends on deployment resource limits and concurrent activity; no particular archive is guaranteed to crash every deployment.</p>
<p>## Remediation</p>
<p>Upgrade the API server to **[Kubeflow Pipelines 2.18.0](https://github.com/kubeflow/pipelines/releases/tag/2.18.0)**. Versions through 2.17.3 are affected; the first affected release has not been established.</p>
<p>[PR #14171](https://github.com/kubeflow/pipelines/pull/14171) bounds compressed input and extracted pipeline data. [PR #14186](https://github.com/kubeflow/pipelines/pull/14186) strengthens the total tar traversal budget, including metadata and skipped entries. The 2.18 release also includes configurable upload and specifica…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-8fmv-6rg5-5924"/>
  </entry>
</feed>
