<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T07:38:05.962825+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/cve-2026-34450</id>
    <title>CVE-2026-34450 — Claude SDK for Python: Insecure Default File Permissions in Local Filesystem Memory Tool</title>
    <updated>2026-09-30T07:38:06.013792+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> anthropics anthropic-sdk-python</p>
<p>The Claude SDK for Python provides access to the Claude API from Python applications. From version 0.86.0 to before version 0.87.0, the local filesystem memory tool in the Anthropic Python SDK created memory files with mode 0o666, leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. Both the synchronous and asynchronous memory tool implementations were affected. This issue has been patched in version 0.87.0.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-34450"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-q5f5-3gjm-7mfm</id>
    <title>GHSA-q5f5-3gjm-7mfm — Claude SDK for Python has Insecure Default File Permissions in Local Filesystem Memory Tool</title>
    <updated>2026-09-30T07:38:06.013922+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: anthropic</p>
<p>The local filesystem memory tool in the Anthropic Python SDK created memory files with mode 0o666, leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. Both the synchronous and asynchronous memory tool implementations were affected.</p>
<p>Users on the affected versions are advised to update to the latest version.</p>
<p>Claude SDK for Python thanks [`lucasfutures`](https://hackerone.com/lucasfutures) on HackerOne for the report.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-q5f5-3gjm-7mfm"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/pysec-2026-2114</id>
    <title>PYSEC-2026-2114</title>
    <updated>2026-09-30T07:38:06.014065+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: anthropic</p>
<p>The Claude SDK for Python provides access to the Claude API from Python applications. From version 0.86.0 to before version 0.87.0, the local filesystem memory tool in the Anthropic Python SDK created memory files with mode 0o666, leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. Both the synchronous and asynchronous memory tool implementations were affected. This issue has been patched in version 0.87.0.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/pysec-2026-2114"/>
  </entry>
</feed>
