<?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-10-01T18:54:51.223829+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/fkie_cve-2026-48790</id>
    <title>fkie_cve-2026-48790</title>
    <updated>2026-10-01T18:54:51.226258+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Turso CLI is the command line interface (CLI) to the open-source database Turso. Versions prior to 1.0.26 persist the user's Turso platform JWT to `settings.json` using Viper's default `configPermissions` of `0o644`, leaving the credential file world-readable on standard Linux and macOS systems. Any other local UID on the host can read the file and recover the platform JWT, which grants full Turso platform access scoped to the user's organizations. Version 1.0.26 patches the issue.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-48790"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-57f6-pvx8-hwj6</id>
    <title>GHSA-57f6-pvx8-hwj6 — turso-cli persists Turso platform JWT with world-readable (0o644) file permissions</title>
    <updated>2026-10-01T18:54:51.226358+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/tursodatabase/turso-cli</p>
<p>### Summary</p>
<p>`turso-cli` persists the user's Turso platform JWT to `settings.json` using Viper's default `configPermissions` of `0o644`, leaving the credential file world-readable on standard Linux and macOS systems. Any other local UID on the host can read the file and recover the platform JWT, which grants full Turso platform access scoped to the user's organizations.</p>
<p>### Impact</p>
<p>The token in `settings.json` grants the holder full Turso platform access — create or destroy databases, rotate credentials, exfiltrate data, change billing settings — for any organization the user belongs to.</p>
<p>Because the file is world-readable, the credential is reachable by:</p>
<p>- Cron jobs or daemons running as a different system user on the same host
- Sandboxed CI runners with a mounted home directory
- Containers with a bind-mounted host home
- Co-tenants on a shared multi-user developer or jumpbox host</p>
<p>The file path resolves through `configdir.LocalConfig("turso")`:</p>
<p>- macOS: `~/Library/Application Support/turso/settings.json`
- Linux: `~/.config/turso/settings.json` (or `$XDG_CONFIG_HOME/turso/settings.json`)</p>
<p>It contains the platform JWT in plaintext JSON alongside `organization` and `username` fields.</p>
<p>Comparable CLIs (`gh`, `aws`, `docker`, `gcloud`, plus close peers `planetscale`, `neon`, `upstash`) write credential files at `0o600` explicitly, so this is a deviation from the cross-vendor baseline rather than a deliberate trade-off.</p>
<p>### Details</p>
<p>The OAuth callback handler stores the p…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-57f6-pvx8-hwj6"/>
  </entry>
</feed>
