CVE-2026-48790

### Summary `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. ### Impact 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. Because the file is world-readable, the credential is reachable by: - 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 The file path resolves through `configdir.LocalConfig("turso")`: - macOS: `~/Library/Application Support/turso/settings.json` - Linux: `~/.config/turso/settings.json` (or `$XDG_CONFIG_HOME/turso/settings.json`) It contains the platform JWT in plaintext JSON alongside `organization` and `username` fields. 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. ### Details The OAuth callback handler stores the platform JWT via the settings layer: ```go // internal/cmd/auth.go:205-214 jwt, err := callbackServer.Result() ... settings.SetToken(jwt) ``` `SetToken` writes through Viper: ```go // internal/settings/settings.go:124-127 func (s *Settings) SetToken(token string) { viper.Set("token", token) s.changed = true } ``` Persistence runs through `viper.WriteConfig`: ```go // internal/settings/settings.go:96-101 func TryToPersistChanges() error { if err := viper.WriteConfig(); err != nil {