CVE-2026-54447 in python-garminconnect
Summary
by MITRE • 09/14/2026
garminconnect is a Python 3 API wrapper for Garmin Connect that retrieves statistics and manages activities. Prior to 0.3.5, garminconnect/client.py Client.dump creates the OAuth token directory and garmin_tokens.json without explicit owner-only modes, so a permissive umask such as 022 can leave the directory mode at 0755 and the token file mode at 0644. garmin_tokens.json contains di_refresh_token, and another unprivileged user on a shared Linux or macOS host can read the token and obtain persistent access to the victim's Garmin Connect account, including health, fitness, activity, and device data. The Garmin.login tokenstore path is affected, and a pre-existing loosely permissioned token file remains exposed until rewritten or manually restricted. This issue is fixed in version 0.3.5.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified within the garminconnect Python library prior to version 0.3.5 represents a critical insecure default configuration that leads to unauthorized data exposure through improper file system permissions. The core technical flaw resides in the Client.dump method and the Garmin.login tokenstore path, where the application creates directories for OAuth tokens and files containing sensitive authentication credentials without explicitly enforcing restrictive owner-only access modes. In Unix-like operating systems such as Linux and macOS, when a process creates new files or directories, it relies on the system's current umask setting to determine permission bits if no explicit mode is specified by the application code. A common default umask of 022 results in newly created directories having permissions of 755 (rwxr-xr-x) and files having permissions of 644 (rw-r--r--). This configuration grants read access to all users on the system, which is fundamentally insecure for storing sensitive authentication material.
The operational impact of this vulnerability is severe due to the nature of the data stored in garmin_tokens.json. This file contains critical OAuth refresh tokens and other credentials necessary to authenticate with Garmin Connect services. Because these files are created with world-readable permissions under a standard umask, any unprivileged user account on the same host can read the contents of this file without needing elevated privileges or exploiting additional software vulnerabilities. The possession of an active refresh token allows an attacker to bypass initial authentication mechanisms and obtain persistent access to the victim's Garmin Connect account. This persistence is particularly dangerous as it does not require repeated exploitation attempts; once the token is stolen, it can be used until it expires or is revoked by the user on their end.
The scope of compromise extends beyond simple credential theft. With unauthorized access to the Garmin Connect API via these tokens, an attacker can retrieve comprehensive personal health and fitness data. This includes detailed activity logs, heart rate metrics, sleep patterns, weight history, and connected device information such as GPS watches or fitness trackers. The exposure of this sensitive personally identifiable information violates user privacy expectations and potentially contravenes regulatory standards regarding the protection of health-related data. Furthermore, the vulnerability affects not only newly created token files but also pre-existing loosely permissioned tokens that remain exposed until they are rewritten by a subsequent login operation or manually restricted by an administrator. This means that systems running older versions may have been vulnerable for extended periods without immediate detection if no new logins occurred to overwrite the insecurely permuted files.
To mitigate this vulnerability, users must upgrade to garminconnect version 0.3.5 or later, where the developers have implemented explicit permission settings during file and directory creation. This ensures that sensitive token files are created with owner-only read-write permissions (typically mode 600) and directories with owner-only access (mode 700), regardless of the system umask. For organizations managing shared infrastructure, it is also advisable to audit existing installations for any residual insecurely permuted token files from previous versions and manually restrict their permissions immediately after upgrading. From a classification perspective, this issue aligns with CWE-276, which describes incorrect default permissions, and falls under the ATT&CK technique of T1539, Steal Web Session Cookie, as it involves the theft of credentials that maintain an active session state. Adhering to the principle of least privilege in file system operations is essential for preventing such lateral movement and data exfiltration scenarios on multi-user systems.