Back to skill

Security audit

Oauth Debugger

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent OAuth debugging guide, but its examples can expose real OAuth secrets and token responses in terminals, logs, or process arguments.

Install only if you are comfortable handling OAuth credentials carefully. Use test clients or tenants where possible, verify AUTH_DOMAIN before running commands, avoid recorded/shared terminals or CI logs, disable shell tracing, and redact or suppress access_token, refresh_token, id_token, client_secret, authorization code, and PKCE verifier values before sharing any output.

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 (2)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:66
Finding
OAuth credentials exposed through command-line arguments## Vulnerability Details **File Location**: `SKILL.md:66-73`, `SKILL.md:144-149`, and `SKILL.md:154-158` **Vulnerability Type**: Sensitive information exposure through process arguments **Risk Level**: Medium The documented commands expand OAuth authorization codes, client secrets, PKCE verifiers, and refresh tokens directly into `curl` command-line arguments. ```bash curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=authorization_code" \ -d "code=$AUTH_CODE" \ -d "redirect_uri=$REDIRECT_URI" \ -d "client_id=$CLIENT_ID" \ -d "client_secret=$CLIENT_SECRET" \ -d "code_verifier=$CODE_VERIFIER" | python3 -c " ``` ```bash curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials" \ -d "client_id=$CLIENT_ID" \ -d "client_secret=$CLIENT_SECRET" \ -d "audience=$API_AUDIENCE" ``` ```bash curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=refresh_token" \ -d "refresh_token=$REFRESH_TOKEN" \ -d "client_id=$CLIENT_ID" ``` ### Technical Analysis Shell variable expansion places the credential values in the argument list of the running `curl` process. Depending on operating-system process isolation and the execution environment, these arguments may be visible through process-monitoring interfaces, diagnostic tools, endpoint monitoring, shell tracing, CI telemetry, or session recording. Supplying credentials to the selected OAuth token endpoint is necessary for the declared debugging function. Exposing those credentials through process arguments is not necessary, however, and exceeds the minimum disclosure required to conduct the request. Authorization codes and PKCE verifiers are short-lived, but client secrets and refresh tokens may remain valid for ...[truncated 1493 chars]
Remediation
## Remediation Suggestions - Do not place client secrets, refresh tokens, authorization codes, or PKCE verifiers directly in process arguments. - Read sensitive request values from a protected input channel, such as a temporary `curl` configuration file with permissions set to `0600`, and securely delete the file immediately after use. - Prefer provider SDKs or a small audited helper that reads secrets from standard input or a protected credential store without exposing them in process metadata. - Disable shell tracing with `set +x` before handling credentials and ensure CI systems mask all OAuth-related variables. - Add explicit warnings against running the commands in shared terminals, recorded sessions, or untrusted CI runners. - Use short-lived credentials and revoke or rotate any client secret or refresh token suspected of exposure. - Verify `AUTH_DOMAIN` against an expected allowlist before transmitting credentials.

T09 · Insecure Skill Coding Practices

Note
Location
SKILL.md:141
Finding
Complete OAuth token responses are written to standard output## Vulnerability Details **File Location**: `SKILL.md:141-159` **Vulnerability Type**: Plaintext disclosure of bearer and refresh tokens **Risk Level**: Low The `test-flow` examples print the complete response from the OAuth token endpoint directly to standard output without parsing or redacting sensitive token fields. ```bash curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials" \ -d "client_id=$CLIENT_ID" \ -d "client_secret=$CLIENT_SECRET" \ -d "audience=$API_AUDIENCE" ``` ```bash curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=refresh_token" \ -d "refresh_token=$REFRESH_TOKEN" \ -d "client_id=$CLIENT_ID" ``` ### Technical Analysis Successful OAuth token responses commonly contain an `access_token` and may contain a `refresh_token` or `id_token`. Because the commands have no output filter, all returned fields are written to the terminal or calling process. This can persist sensitive bearer credentials in terminal scrollback, Agent transcripts, CI logs, centralized logging systems, shell-session recordings, or copied diagnostic reports. Displaying complete tokens is unnecessary to verify that a flow succeeded. The earlier token-exchange diagnostic example demonstrates a safer approach by printing only token presence and non-secret metadata. ### Attack Path 1. A user runs a documented `test-flow` command with valid OAuth credentials. 2. The OAuth provider returns a successful JSON response containing one or more tokens. 3. `curl` writes the complete JSON response to standard output. 4. A terminal recorder, CI logger, Agent transcript, support bundle, or observer captures the output. 5. An attacker obtains an access or refresh token from the captured output. 6. The attacker presents the bearer token to its intended API ...[truncated 680 chars]
Remediation
## Remediation Suggestions - Pipe token responses into a fixed JSON parser that reports only success status and non-sensitive metadata, such as token type, expiration, and granted scopes. - Explicitly suppress or redact the values of `access_token`, `refresh_token`, and `id_token`. - Avoid placing raw token responses in Agent conversations, issue reports, CI artifacts, or centralized logs. - If retaining a response is essential for debugging, write it to a dedicated file with `0600` permissions, use a restricted temporary directory, and delete it promptly. - Add documentation warning users that OAuth responses contain bearer credentials and must not be shared. - Revoke exposed refresh tokens and access tokens where supported, and investigate access performed during the exposure window.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (9)

External Script Fetching

High
Category
Supply Chain
Content
```bash
# OpenID Connect discovery
curl -s "https://$AUTH_DOMAIN/.well-known/openid-configuration" | python3 -c "
import json, sys
config = json.load(sys.stdin)
print('Authorization endpoint:', config.get('authorization_endpoint', '❌ MISSING'))
Confidence
90% confidence
Finding
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

External Script Fetching

High
Category
Supply Chain
Content
"

# Check JWKS endpoint
curl -s "https://$AUTH_DOMAIN/.well-known/jwks.json" | python3 -c "
import json, sys
jwks = json.load(sys.stdin)
for key in jwks.get('keys', []):
Confidence
90% confidence
Finding
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

External Script Fetching

High
Category
Supply Chain
Content
```bash
# Test token exchange
curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=$AUTH_CODE" \
Confidence
90% confidence
Finding
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Credential Access

High
Category
Privilege Escalation
Content
resp = json.load(sys.stdin)
if 'access_token' in resp:
    print('✅ Token exchange successful')
    print(f'Access token type: {resp.get(\"token_type\")}')
    print(f'Expires in: {resp.get(\"expires_in\")}s')
    print(f'Scopes: {resp.get(\"scope\")}')
    if 'id_token' in resp:
Confidence
93% confidence
Finding
The token-exchange parser handles live credential material and encourages inspecting whether access, ID, and refresh tokens are present after a successful exchange. In a debugging workflow, this can easily lead to tokens being exposed in terminal history, screenshots, logs, or copied reports, especially since the skill does not emphasize redaction or safe handling.

Credential Access

High
Category
Privilege Escalation
Content
- State parameter missing (CSRF vulnerability)
- Token in URL query string (logged everywhere)
- Wildcard redirect URIs (open redirect)
- Long-lived access tokens without refresh (> 1 hour)
- Client secret in frontend code (exposed to users)
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill provides a ready-to-run token exchange example that includes highly sensitive values such as client_secret, authorization code, and code_verifier, but it does not warn users that these secrets should only be used against their own IdP endpoints and must not be pasted into logs, chats, or untrusted terminals. In a debugging-oriented skill, users are especially likely to copy production credentials into examples, increasing the risk of credential exposure and accidental misuse.

External Transmission

Medium
Category
Data Exfiltration
Content
```bash
# Test token exchange
curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=$AUTH_CODE" \
Confidence
90% confidence
Finding
This command transmits OAuth credentials and artifacts, including client_secret and authorization code, to an external endpoint. Although contacting the OAuth provider is expected for legitimate debugging, the skill does not bound usage to trusted domains or warn about using production secrets, so it creates a real risk of accidental credential disclosure or misuse.

External Transmission

Medium
Category
Data Exfiltration
Content
**Client Credentials (machine-to-machine):**
```bash
curl -s -X POST "https://$AUTH_DOMAIN/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=$CLIENT_ID" \
Confidence
89% confidence
Finding
The client-credentials example sends a client_secret to a remote token endpoint, which is inherent to the OAuth flow but still sensitive. In context this is operationally legitimate, yet without warnings about trusted endpoints, secret handling, and output hygiene, the example can facilitate accidental exposure of machine-to-machine credentials.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The refresh-token test snippet encourages handling a long-lived credential without any caution about storage, redaction, or revocation. Refresh tokens often provide durable access and are more sensitive than short-lived access tokens, so omitting handling guidance materially increases the chance of account or API compromise if the token is exposed.

Static analysis

No suspicious patterns detected.