Back to skill

Security audit

Fitbit Insights

Security checks for vulnerabilities and agentic risk

Overview

This Fitbit skill is aimed at a legitimate read-only health-data use case, but it asks users to rely on plaintext stored OAuth tokens and references missing security-critical implementation files that cannot be reviewed.

Review carefully before installing. Only use this with a trusted, complete package that includes the audited implementation, store Fitbit credentials in a protected secret store or a mode-600 file, revoke tokens if exposed, and require clear user intent before accessing Fitbit health data.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Warning
Location
SETUP.md:37
Finding
OAuth Credentials Exposed Through Shell History and Process Arguments## Vulnerability Details **File Location**: `SETUP.md`, lines 37–43 **Vulnerability Type**: OAuth credential exposure through command-line arguments **Risk Level**: Medium ### Vulnerable Code ```bash curl -X POST https://api.fitbit.com/oauth2/token \ -H "Authorization: Basic $(echo -n 'YOUR_CLIENT_ID:YOUR_CLIENT_SECRET' | base64)" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=YOUR_CLIENT_ID&grant_type=authorization_code&redirect_uri=http://localhost&code=YOUR_CODE" ``` ### Technical Analysis The documented command asks users to substitute an OAuth client secret and authorization code directly into an interactive shell command. The unexpanded credentials may remain in shell history. During execution, the expanded Basic authorization value and request body may also be exposed through process inspection, debugging, terminal logging, or command auditing. Base64 encoding does not protect the client credentials; anyone who obtains the resulting authorization value can decode it. The request is sent over HTTPS to the legitimate Fitbit token endpoint, so this is not evidence of transmission to an unauthorized host. The weakness is local secret handling rather than the network destination. ### Attack Path 1. A user replaces the placeholders with an actual client ID, client secret, and authorization code. 2. The user runs the command in an interactive shell. 3. The command containing the client secret and authorization code is recorded in shell history, terminal logs, or system auditing records. 4. Alternatively, a local process with suitable access observes the expanded command or related process metadata while it executes. 5. An attacker retrieves the OAuth material and uses it to request or maintain access to the victim's Fitbit account data. ### Impact Assessment Successful exploitation may disclose the OAuth client secret and temporary authorization code. When combined with ...[truncated 425 chars]
Remediation
## Remediation Suggestions - Replace the inline `curl` example with a reviewed helper that reads credentials from protected input, an operating-system credential store, or a file restricted to the owning user. - Do not place client secrets, authorization codes, access tokens, refresh tokens, or derived Basic authorization values in command-line arguments. - Disable command echoing around secret operations and document how users can remove any previously recorded command from shell history. - If a temporary credential file is necessary, create it under `umask 077`, enforce mode `0600`, verify ownership, and securely remove it after use. - Ensure diagnostic and error output never includes request headers, request bodies, or token responses.

T09 · Insecure Skill Coding Practices

Warning
Location
SETUP.md:49
Finding
Reusable Fitbit Tokens Stored in Plaintext Without Enforced File Permissions## Vulnerability Details **File Location**: `SETUP.md`, lines 49–62 **Vulnerability Type**: Insecure plaintext credential storage **Risk Level**: Medium ### Vulnerable Code ```markdown Create `fitbit-config.json` in your Clawdbot workspace: ```json { "client_id": "YOUR_CLIENT_ID", "client_secret": "YOUR_CLIENT_SECRET", "access_token": "YOUR_ACCESS_TOKEN", "refresh_token": "YOUR_REFRESH_TOKEN", "expires_at": 0, "last_refreshed": "" } ``` **Location:** `/root/clawd/fitbit-config.json` (or wherever your Clawdbot workspace is) ``` ### Technical Analysis The setup guide instructs users to store the OAuth client secret, access token, and refresh token together in a plaintext JSON file. Although the later security guidance recommends excluding the file from Git, it does not require restrictive permissions, validate ownership, or use a credential store. Git exclusion only reduces accidental repository disclosure. It does not protect the credentials from other local users, services, backup systems, workspace indexing, support bundles, or processes that can read the file. The refresh token is particularly sensitive because it can be used to obtain replacement access tokens after short-lived access tokens expire. ### Attack Path 1. A user creates `fitbit-config.json` using default filesystem permissions. 2. The file becomes readable by another local principal, workspace service, backup process, or compromised application. 3. The attacker copies the client secret, access token, and refresh token. 4. The attacker uses the current access token or exchanges the refresh token for a new access token at Fitbit's OAuth endpoint. 5. The attacker queries the Fitbit API for the health-data scopes authorized by the user. ### Impact Assessment An attacker who obtains the stored tokens may read the victim's profile, activity, heart-rate, sleep, and workout data for as long as the stolen authorization remain ...[truncated 426 chars]
Remediation
## Remediation Suggestions - Prefer an operating-system credential store or dedicated secret-management facility instead of a general workspace JSON file. - If file storage is unavoidable, create the file with `umask 077` or `install -m 600`, require ownership by the service account, and reject files with unsafe permissions or unexpected owners. - Separate credentials from non-sensitive configuration and prevent the credential file from being included in backups, support archives, workspace indexing, or logs. - Use atomic writes with preserved restrictive permissions when rotating tokens. - Redact tokens and client secrets from all exceptions, debug output, and command results. - Document token revocation and rotation procedures for suspected disclosure. - Request only the Fitbit scopes needed for the user's immediate requested features.

other

Warning
Location
README.md:101
Finding
Security-Critical Skill Implementation Is Missing and Cannot Be Audited## Vulnerability Details **File Location**: `README.md`, lines 101–112 **Vulnerability Type**: Incomplete package and unverifiable external implementation **Risk Level**: Medium ### Affected Documentation ```markdown ## What's Included - `fitbit.skill` - Complete skill package - `README.md` - This file - `SETUP.md` - Step-by-step OAuth setup guide - Inside skill: - SKILL.md - Full documentation - fitbit_api.py - API client - refresh_token.py - Auto-refresh system - fitbit-oauth-setup.md - OAuth guide ``` ### Technical Analysis The audited directory contains only Markdown documentation. The advertised `fitbit.skill` package, `scripts/fitbit_api.py`, `scripts/refresh_token.py`, and OAuth reference file are absent. These missing components are responsible for receiving stored credentials, refreshing tokens, making network requests, and processing sensitive health information. Consequently, claims such as read-only operation, Fitbit-only network access, secure token refresh, lack of caching, and absence of data storage cannot be verified. This finding does not prove that malicious code exists. It establishes that the security-critical behavior described by the documentation is outside the supplied audit boundary and that obtaining a separate package would introduce an unaudited supply-chain boundary. ### Attack Path 1. A user trusts the reviewed documentation and attempts to install the Skill. 2. Because the advertised package and scripts are absent, the user obtains them from a separate source or a later package revision. 3. The replacement implementation is not cryptographically tied to the documentation that was audited. 4. The user provides that implementation with Fitbit client credentials and reusable OAuth tokens. 5. A compromised or substituted implementation could transmit those credentials or retrieved health data to an unauthorized destination, store them insecurely, or execute unrelated l ...[truncated 655 chars]
Remediation
## Remediation Suggestions - Include the exact installable `fitbit.skill` artifact and all referenced source files in the audited project. - Ensure the packaged files are reproducible from the reviewed source and publish a cryptographic digest for the approved artifact. - Pin installation instructions to a specific version and digest rather than an unspecified local package or mutable external source. - Audit the implementation for endpoint allowlisting, TLS verification, scope minimization, token redaction, secure file permissions, atomic token rotation, and absence of hidden storage or telemetry. - Keep all credential and health-data processing within the declared Fitbit workflow, and explicitly disclose any AI, messaging, logging, or analytics service that receives the data. - Remove “production ready,” “never shared,” and equivalent security claims until they are supported by the complete reviewed implementation.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (12)

Credential Access

High
Category
Privilege Escalation
Content
1. User registers Fitbit OAuth app (one-time)
2. User authorizes app and gets tokens
3. Tokens stored in local config file
4. Access token auto-refreshes every 8 hours
5. No re-authentication needed

## Security
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
1. On your app page, scroll to **"OAuth 2.0 tutorial page"**
2. Click the link to "access your own data"
3. Authorize the app
4. Copy the **Access Token** and **Refresh Token**

**Option B: Manual OAuth Flow**
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
- ✅ **Never commit config to git** - Add `fitbit-config.json` to `.gitignore`
- ✅ **Refresh tokens don't expire** - Keep them secure
- ✅ **Access tokens expire in 8 hours** - Auto-refreshed by skill
- ✅ **Read-only access** - Skill never writes to Fitbit

## Troubleshooting
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
## Prerequisites

**Requires:** Fitbit OAuth access token

Setup steps in `references/fitbit-oauth-setup.md`
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The description promotes conversational analysis of sleep, heart rate, workouts, and other health metrics but does not clearly warn users that their sensitive health data will be transmitted to external services for processing. Because this is health-related information, missing disclosure meaningfully increases privacy risk and can undermine informed consent, even if the integration is read-only and does not persist data.

Vague Triggers

Medium
Confidence
90% confidence
Finding
The submission includes broad example utterances such as asking general fitness questions, which can overlap with common assistant requests and increase the chance of unintended skill activation. In a health-data skill, accidental invocation is more sensitive because it may trigger retrieval and analysis of personal Fitbit data when the user did not explicitly intend to use this integration.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The overview describes sensitive health and biometric processing but does not explicitly warn users that their Fitbit-derived data may be transmitted to Fitbit APIs and then processed by an AI analysis component. For health-related data, lack of clear disclosure undermines informed consent and can lead to privacy and compliance risks if users do not realize how their data is handled.

Vague Triggers

Medium
Confidence
91% confidence
Finding
The trigger scope is broad enough that general fitness or health-related prompts could invoke the skill without clearly signaling that sensitive Fitbit data will be accessed and analyzed. In a health-data skill, overly broad activation increases the chance of unintended collection, transmission, or summarization of sensitive personal information.

External Transmission

Medium
Category
Data Exfiltration
Content
3. Exchange code for tokens:
   ```bash
   curl -X POST https://api.fitbit.com/oauth2/token \
     -H "Authorization: Basic $(echo -n 'YOUR_CLIENT_ID:YOUR_CLIENT_SECRET' | base64)" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "client_id=YOUR_CLIENT_ID&grant_type=authorization_code&redirect_uri=http://localhost&code=YOUR_CODE"
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The setup guide instructs users to store a client secret, access token, and long-lived refresh token in a plaintext JSON file under a fixed local path. Although this is common in simple setup docs, it creates a real credential-exposure risk if the host is multi-user, backed up insecurely, malware-compromised, or the workspace is accidentally shared; the note to avoid committing to git does not adequately address plaintext-at-rest risk.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The skill processes highly sensitive health and biometric data, but the description and usage guidance do not clearly warn users that their Fitbit activity, sleep, and heart-rate data will be accessed and analyzed. This weakens informed consent and increases privacy risk, especially because users may invoke the skill without realizing the sensitivity of the data being handled.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The token management section states that tokens are automatically loaded from /root/clawd/fitbit-config.json and refreshed, but it does not clearly warn that stored OAuth credentials on disk will be used implicitly. This can surprise operators, encourage silent credential reuse, and increase the chance of unauthorized or unintended access to a user's Fitbit account.

Static analysis

No suspicious patterns detected.