CVE-2025-27154 is scored Critical (CVSS 9.8) in the record. Spotipy, the Python library for the Spotify Web API, created its token cache file with permissions 644 before version 2.25.1. Upgrade to 2.25.1 and tighten permissions on cache files that already exist.
What's affected
Affected: Spotipy before 2.25.1. Fixed: 2.25.1, which tightens the cache file permissions, according to the release notes and the GitHub advisory GHSA-pwhh-q4h6-w599.
The CacheHandler class creates a cache file to store the authorization token. Before the fix, the file was created with rw-r--r-- (644) permissions, which lets other users on the machine read it. The fix limits it to rw------- (600).
A note on scoring: the record shows 9.8, which assumes network access and no privileges. The GitHub advisory rates the issue High, 8.4, with a local attack vector. The advisory describes the realistic case: another user or process on the same machine reads the file. Use your own context to judge urgency. A shared server or CI runner is higher risk than a laptop only you use.
How to check if you're exposed
Find the installed version:
pip show spotipy
pip list 2>/dev/null | grep -i spotipy
If it is below 2.25.1, upgrade. Then look at the cache files that already exist, because updating the library does not change the permissions on files created earlier:
find ~ /srv /opt /var/lib -name ".cache*" -type f -perm /044 2>/dev/null | head
ls -l .cache* 2>/dev/null
The default cache file is a hidden file in the working directory, often named with a .cache prefix, but your code may set a different path. Tighten any that are readable by others:
chmod 600 .cache*
A dependency scan can find the library in your manifests. The free in-browser scan and the demo below show how a fixed version is surfaced.
What to do now
- Find every project that depends on Spotipy, including scripts and notebooks.
- Upgrade to 2.25.1 or later:
pip install --upgrade spotipy. - Fix permissions on existing cache files with
chmod 600. - Check home and working directories on shared machines, where other users could read the file.
- Revoke and reissue Spotify tokens on any machine where another user could have read the file.
- Keep token caches out of version control and out of shared volumes.
Why it matters
The record lists CWE-276: incorrect default permissions. A secret was stored in a file that other users could read. No code was tricked, and nothing needed to be guessed: the permissions simply allowed access.
The impact depends on the scope of the token. The advisory notes that a broad token could be used to read and change playlists and saved items, and to control playback. It also says the exposure only exists if the attacker can read the file, for example another user on the machine. The record's KEV flag is false, so it is not in the CISA Known Exploited Vulnerabilities catalog.
Secrets on disk should be created with restrictive permissions from the start. This fix is a small code change with a clear lesson for any program that stores a token.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does upgrading fix files that already exist?
The fix changes how new files are created. Existing cache files keep their old permissions, so set them to 600 yourself and consider reissuing tokens.
Why does the record say 9.8 but GitHub says 8.4?
They use different scoring inputs. The record's vector assumes a network attack. The GitHub advisory scores it as local, which matches the described scenario.
Sources
Last reviewed: 19 October 2026.
