<?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>Thu, 08 Oct 2026 13:55:56 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-321427</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-321427</link>
      <description>EUVD-2026-321427</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-321427</guid>
    </item>
    <item>
      <title>fkie_cve-2026-40610</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-40610</link>
      <description>&lt;p&gt;BentoML is a Python library for building online serving systems optimized for AI apps and model inference. In versions 1.4.38 and prior, the build packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact. If a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as loot.txt -&amp;gt; /tmp/outside-marker.txt or a link to a more sensitive local file. When bentoml build runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows. An attacker can exfiltrate local files from the build host into the Bento artifact, exposing secrets such as cloud credentials, SSH keys, API tokens, environment files, or other sensitive local configurations. Because Bento artifacts are commonly exported, uploaded, stored, or containerized after build, the leaked file contents can spread beyond the original build machine. This issue has been fixed in version 1.4.39.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;BentoML is a Python library for building online serving systems optimized for AI apps and model inference. In versions 1.4.38 and prior, the build packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact. If a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as loot.txt -&amp;gt; /tmp/outside-marker.txt or a link to a more sensitive local file. When bentoml build runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows. An attacker can exfiltrate local files from the build host into the Bento artifact, exposing secrets such as cloud credentials, SSH keys, API tokens, environment files, or other sensitive local configurations. Because Bento artifacts are commonly exported, uploaded, stored, or containerized after build, the leaked file contents can spread beyond the original build machine. This issue has been fixed in version 1.4.39.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-40610</guid>
    </item>
    <item>
      <title>GHSA-mcfx-4vc6-qgxv — BentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-mcfx-4vc6-qgxv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: bentoml&lt;/p&gt;
&lt;p&gt;### Summary
BentoML&amp;#39;s `bentoml build` packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact.&lt;/p&gt;
&lt;p&gt;If a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as `loot.txt -&amp;gt; /tmp/outside-marker.txt` or a link to a more sensitive local file. When `bentoml build` runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows.&lt;/p&gt;
&lt;p&gt;### Details
The vulnerable code walks files under the build context and copies each matched entry into the Bento source directory:&lt;/p&gt;
&lt;p&gt;```python
for root, _, files in os.walk(ctx_path):
    for f in files:
        dir_path = os.path.relpath(root, ctx_path)
        path = os.path.join(dir_path, f).replace(os.sep, &amp;#34;/&amp;#34;)
        if specs.includes(path):
            src_file = ctx_path.joinpath(path)
            dst_file = target_fs.joinpath(dest_path)
            shutil.copy(src_file, dst_file)
```&lt;/p&gt;
&lt;p&gt;There is no validation that the resolved path of `src_file` remains inside `ctx_path` before `shutil.copy` dereferences the source path. As a result, a repository-controlled symlink can cross the trust boundary from `attacker-controlled repository content` to `developer/CI host filesystem` during the build process.&lt;/p&gt;
&lt;p&gt;This is a build-time path traversal / symlink traversal issue in the pa…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: bentoml&lt;/p&gt;
&lt;p&gt;### Summary
BentoML&amp;#39;s `bentoml build` packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact.&lt;/p&gt;
&lt;p&gt;If a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as `loot.txt -&amp;gt; /tmp/outside-marker.txt` or a link to a more sensitive local file. When `bentoml build` runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows.&lt;/p&gt;
&lt;p&gt;### Details
The vulnerable code walks files under the build context and copies each matched entry into the Bento source directory:&lt;/p&gt;
&lt;p&gt;```python
for root, _, files in os.walk(ctx_path):
    for f in files:
        dir_path = os.path.relpath(root, ctx_path)
        path = os.path.join(dir_path, f).replace(os.sep, &amp;#34;/&amp;#34;)
        if specs.includes(path):
            src_file = ctx_path.joinpath(path)
            dst_file = target_fs.joinpath(dest_path)
            shutil.copy(src_file, dst_file)
```&lt;/p&gt;
&lt;p&gt;There is no validation that the resolved path of `src_file` remains inside `ctx_path` before `shutil.copy` dereferences the source path. As a result, a repository-controlled symlink can cross the trust boundary from `attacker-controlled repository content` to `developer/CI host filesystem` during the build process.&lt;/p&gt;
&lt;p&gt;This is a build-time path traversal / symlink traversal issue in the pa…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-mcfx-4vc6-qgxv</guid>
    </item>
    <item>
      <title>PYSEC-2026-2399 — BentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2399</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: bentoml&lt;/p&gt;
&lt;p&gt;### Summary
BentoML&amp;#39;s `bentoml build` packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact.&lt;/p&gt;
&lt;p&gt;If a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as `loot.txt -&amp;gt; /tmp/outside-marker.txt` or a link to a more sensitive local file. When `bentoml build` runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows.&lt;/p&gt;
&lt;p&gt;### Details
The vulnerable code walks files under the build context and copies each matched entry into the Bento source directory:&lt;/p&gt;
&lt;p&gt;```python
for root, _, files in os.walk(ctx_path):
    for f in files:
        dir_path = os.path.relpath(root, ctx_path)
        path = os.path.join(dir_path, f).replace(os.sep, &amp;#34;/&amp;#34;)
        if specs.includes(path):
            src_file = ctx_path.joinpath(path)
            dst_file = target_fs.joinpath(dest_path)
            shutil.copy(src_file, dst_file)
```&lt;/p&gt;
&lt;p&gt;There is no validation that the resolved path of `src_file` remains inside `ctx_path` before `shutil.copy` dereferences the source path. As a result, a repository-controlled symlink can cross the trust boundary from `attacker-controlled repository content` to `developer/CI host filesystem` during the build process.&lt;/p&gt;
&lt;p&gt;This is a build-time path traversal / symlink traversal issue in the pa…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: bentoml&lt;/p&gt;
&lt;p&gt;### Summary
BentoML&amp;#39;s `bentoml build` packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact.&lt;/p&gt;
&lt;p&gt;If a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as `loot.txt -&amp;gt; /tmp/outside-marker.txt` or a link to a more sensitive local file. When `bentoml build` runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows.&lt;/p&gt;
&lt;p&gt;### Details
The vulnerable code walks files under the build context and copies each matched entry into the Bento source directory:&lt;/p&gt;
&lt;p&gt;```python
for root, _, files in os.walk(ctx_path):
    for f in files:
        dir_path = os.path.relpath(root, ctx_path)
        path = os.path.join(dir_path, f).replace(os.sep, &amp;#34;/&amp;#34;)
        if specs.includes(path):
            src_file = ctx_path.joinpath(path)
            dst_file = target_fs.joinpath(dest_path)
            shutil.copy(src_file, dst_file)
```&lt;/p&gt;
&lt;p&gt;There is no validation that the resolved path of `src_file` remains inside `ctx_path` before `shutil.copy` dereferences the source path. As a result, a repository-controlled symlink can cross the trust boundary from `attacker-controlled repository content` to `developer/CI host filesystem` during the build process.&lt;/p&gt;
&lt;p&gt;This is a build-time path traversal / symlink traversal issue in the pa…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2399</guid>
    </item>
  </channel>
</rss>
