<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T20:40:26.019791+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-1669</id>
    <title>CVE-2026-1669 — Arbitrary File Read in Keras via HDF5 External Datasets</title>
    <updated>2026-10-07T20:40:26.021915+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Google Keras, Red Hat OpenShift AI (RHOAI)</p>
<p>Arbitrary file read in the model loading mechanism (HDF5 integration) in Keras versions 3.0.0 through 3.13.1 on all supported platforms allows a remote attacker to read local files and disclose sensitive information via a crafted .keras model file utilizing HDF5 external dataset references.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-1669"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-3m4q-jmj6-r34q</id>
    <title>GHSA-3m4q-jmj6-r34q — Keras has a Local File Disclosure via HDF5 External Storage During Keras Weight Loading</title>
    <updated>2026-10-07T20:40:26.021987+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: keras</p>
<p>## Summary</p>
<p>TensorFlow / Keras continues to honor HDF5 “external storage” and `ExternalLink` features when loading weights. A malicious `.weights.h5` (or a `.keras` archive embedding such weights) can direct `load_weights()` to read from an arbitrary readable filesystem path. The bytes pulled from that path populate model tensors and become observable through inference or subsequent re-save operations. Keras “safe mode” only guards object deserialization and does not cover weight I/O, so this behaviour persists even with safe mode enabled. The issue is confirmed on the latest publicly released stack (`tensorflow 2.20.0`, `keras 3.11.3`, `h5py 3.15.1`, `numpy 2.3.4`).</p>
<p>## Impact</p>
<p>- **Class**: CWE-200 (Exposure of Sensitive Information), CWE-73 (External Control of File Name or Path)
- **What leaks**: Contents of any readable file on the host (e.g., `/etc/hosts`, `/etc/passwd`, `/etc/hostname`).
- **Visibility**: Secrets appear in model outputs (e.g., Dense layer bias) or get embedded into newly saved artifacts.
- **Prerequisites**: Victim executes `model.load_weights()` or `tf.keras.models.load_model()` on an attacker-supplied HDF5 weights file or `.keras` archive.
- **Scope**: Applies to modern Keras (3.x) and TensorFlow 2.x lines; legacy HDF5 paths remain susceptible.</p>
<p>## Attacker Scenario</p>
<p>1. **Initial foothold**: The attacker convinces a user (or CI automation) to consume a weight artifact—perhaps by publishing a pre-trained model, contributing to an open-source repositor…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-3m4q-jmj6-r34q"/>
  </entry>
</feed>
