Security audit

web-browser

Security checks across malware telemetry and agentic risk

Overview

The skill is coherent as a browser automation tool, but its credential workflows direct agents to find, extract, store, reuse, and sometimes revoke secrets with too little per-action user control.

Install only if you want an agent to automate authenticated browser sessions and handle raw credentials. Use test accounts or tightly scoped tokens, require explicit approval before any token issuance/reset/revoke, reject temp-file token handoffs unless necessary, and decide the exact secret-store destination before allowing persistence.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (22)

Context-Inappropriate Capability

Medium

Confidence: 94% confidence
Finding: The skill includes shell commands to forcibly terminate Chrome processes and delete local profile files/directories, which exceeds the stated scope of browser UI testing. These actions can disrupt unrelated user work, destroy local session state, and normalize host-level remediation steps without explicit confirmation or safety boundaries.

Context-Inappropriate Capability

Medium

Confidence: 83% confidence
Finding: The guidance authorizes shell-based parsing tools like grep or python to inspect saved snapshots, contradicting the earlier claim that verification must go through browser UI interaction. While lower risk than process termination, it broadens the agent's operational scope into general shell usage and can lead to unintended access or handling of local files outside the browser workflow.

Vague Triggers

Medium

Confidence: 85% confidence
Finding: The trigger list includes very broad phrases such as 'open login screen', 'issue token', and 'service credential', which overlap with common user requests and can cause this high-risk skill to be invoked in situations the user did not clearly intend. Because the skill includes credential issuance and session reuse behaviors, accidental invocation expands the chance of sensitive actions being proposed or performed in the wrong context.

Missing User Warnings

High

Confidence: 94% confidence
Finding: The Discord hybrid flow explicitly instructs the agent to capture a bot token and write it to a temporary file for handoff, but the skill does not present a strong user warning about secret persistence, exposure in logs, filesystem residue, or downstream reuse. This omission is dangerous because users may not realize that a freshly issued or reset credential is being stored and transferred outside the browser session.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The skill explicitly instructs use of CDP `DOM.getDocument(..., pierce: true)` to enumerate the full DOM, including closed shadow roots, and frames this as a normal diagnostic step. Closed shadow DOM is often used to reduce direct inspection of internal implementation and may contain sensitive UI state or data; exposing it without an explicit privacy/authorization warning increases the chance that operators collect data they should not access or retain.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The skill explicitly instructs the agent to search local secret-bearing locations such as skill data, project memory, .env files, and secret stores before any browser flow. That creates a broad credential-discovery behavior without requiring explicit user consent or a just-in-time warning, which can expose unrelated secrets and normalize secret harvesting beyond the minimum needed for the task.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The skill makes secret persistence mandatory for every newly issued credential, but it does so as an unconditional workflow step rather than a user-approved action. Forced storage of freshly generated tokens increases retention risk, can place secrets into inappropriate stores, and may violate user expectations or organizational policy if done automatically.

Natural-Language Policy Violations

Medium

Confidence: 82% confidence
Finding: Mandating GitHub SSO for Microsoft services removes user choice over authentication method and can silently redirect authentication through a different identity provider than intended. In environments with multiple linked identities, this increases the chance of logging into the wrong tenant or granting scopes under an unintended account.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The cleanup procedure instructs irreversible actions such as force-killing processes and deleting lock files or the entire profile directory, but does not require an explicit user-facing warning or approval step. In a real environment, this can cause loss of browsing state, interrupt active sessions, and damage user trust if triggered automatically.

Ssd 3

High

Confidence: 96% confidence
Finding: The core skill description advertises browser-assisted issuance or refresh of access keys, tokens, secrets, and OAuth scopes, followed by handoff to automation. That creates a direct pathway for the agent to obtain or expand sensitive credentials and propagate them to other systems, increasing the blast radius if the workflow is misused, over-broad, or insufficiently consented.

Ssd 3

Critical

Confidence: 99% confidence
Finding: This section gives step-by-step instructions to wait for a privileged '/bot' page, reset a bot token, capture the readonly token value, and write it to a file for later automation. That is highly dangerous because it operationalizes secret extraction and persistence of a powerful credential, potentially exposing the token to logs, local compromise, accidental disclosure, or misuse by downstream processes.

Ssd 3

High

Confidence: 97% confidence
Finding: This section establishes a full sensitive-data lifecycle: discover existing credentials, issue new ones, collect them, persist them, and reuse them. Embedding that workflow in natural-language instructions materially increases the chance that the agent will access, move, and retain secrets across contexts, expanding the blast radius of any misuse or compromise.

Ssd 3

High

Confidence: 96% confidence
Finding: The skill repeatedly instructs the backend to extract visible tokens from web pages and pass them into other automation systems. This is dangerous because it operationalizes secret scraping and transfer, making secrets available to tooling, logs, transcripts, and any downstream process that receives the value.

Ssd 3

High

Confidence: 97% confidence
Finding: The boundary table explicitly assigns the backend responsibility for extracting token values and persisting them, making sensitive-data collection a core contract of the skill rather than an incidental behavior. That increases risk because the agent is instructed to handle raw credentials end-to-end, including storage, which amplifies exposure if prompts, logs, memory, or integrations are compromised.

Credential Access

High

Category: Privilege Escalation
Content: |---------------------|---------------------------|-----------------|------------| | GitHub PAT (classic / fine-grained) | **gh CLI keyring** (OS-native — macOS Keychain / Windows Credential Manager / libsecret) | `echo <token> \| gh auth login --hostname github.com --with-token` | `gh auth token -u <user>` (and Docker uses `~/.docker/config.json` after `docker login` once) | | GitHub Actions repo/org secret | **GitHub secret store** | `gh secret set <NAME> -b<token>` | Workflow `${{ secrets.NAME }}` | | AWS access key / secret | **Vault** (preferred) or `~/.aws/credentials` profile | `vault kv put secret/aws/<profile> access_key=... secret_key=...` OR `aws configure --profile <name>` | `AWS_PROFILE=<name>` / `vault kv get -field=secret_key secret/aws/<profile>` | | Cloudflare R2 S3 token | **Vault** | `vault kv put secret/r2/<bucket> access_key=... secret_key=...` | `vault kv get -field=secret_key secret/r2/<bucket>` | | OCI API key | **`~/.oci/config`** (CLI-native) | append profile section + `oci_cli_rc` if needed | `OCI_CLI_PROFILE=<name>` | | Authentik admin token | **Vault** | `vault kv put secret/authentik/<env> token=...` | `vault kv get -field=token secret/authentik/<env>` |
Confidence: 92% confidence
Finding: Directing the agent to use ~/.aws/credentials as a storage and reuse path means the workflow is intentionally accessing and managing highly sensitive local cloud credentials. Without strict consent and scoping, this can expose existing AWS keys, overwrite profiles, or cause secrets to be handled in insecure contexts.

Credential Access

High

Category: Privilege Escalation
Content: | Service / token type | Primary store (preferred) | Persist command | Reuse path | |---------------------|---------------------------|-----------------|------------| | GitHub PAT (classic / fine-grained) | **gh CLI keyring** (OS-native — macOS Keychain / Windows Credential Manager / libsecret) | `echo <token> \| gh auth login --hostname github.com --with-token` | `gh auth token -u <user>` (and Docker uses `~/.docker/config.json` after `docker login` once) | | GitHub Actions repo/org secret | **GitHub secret store** | `gh secret set <NAME> -b<token>` | Workflow `${{ secrets.NAME }}` | | AWS access key / secret | **Vault** (preferred) or `~/.aws/credentials` profile | `vault kv put secret/aws/<profile> access_key=... secret_key=...` OR `aws configure --profile <name>` | `AWS_PROFILE=<name>` / `vault kv get -field=secret_key secret/aws/<profile>` | | Cloudflare R2 S3 token | **Vault** | `vault kv put secret/r2/<bucket> access_key=... secret_key=...` | `vault kv get -field=secret_key secret/r2/<bucket>` |
Confidence: 86% confidence
Finding: Explicit use of OS Keychain/Credential Manager/libsecret as part of automated token persistence means the skill is designed to interact with high-trust credential stores. In the context of a browser automation skill that also extracts tokens from pages, this materially increases the sensitivity of the workflow and the consequences of misuse.

Credential Access

High

Category: Privilege Escalation
Content: | Service / token type | Primary store (preferred) | Persist command | Reuse path | |---------------------|---------------------------|-----------------|------------| | GitHub PAT (classic / fine-grained) | **gh CLI keyring** (OS-native — macOS Keychain / Windows Credential Manager / libsecret) | `echo <token> \| gh auth login --hostname github.com --with-token` | `gh auth token -u <user>` (and Docker uses `~/.docker/config.json` after `docker login` once) | | GitHub Actions repo/org secret | **GitHub secret store** | `gh secret set <NAME> -b<token>` | Workflow `${{ secrets.NAME }}` | | AWS access key / secret | **Vault** (preferred) or `~/.aws/credentials` profile | `vault kv put secret/aws/<profile> access_key=... secret_key=...` OR `aws configure --profile <name>` | `AWS_PROFILE=<name>` / `vault kv get -field=secret_key secret/aws/<profile>` | | Cloudflare R2 S3 token | **Vault** | `vault kv put secret/r2/<bucket> access_key=... secret_key=...` | `vault kv get -field=secret_key secret/r2/<bucket>` |
Confidence: 86% confidence
Finding: Explicit use of OS Keychain/Credential Manager/libsecret as part of automated token persistence means the skill is designed to interact with high-trust credential stores. In the context of a browser automation skill that also extracts tokens from pages, this materially increases the sensitivity of the workflow and the consequences of misuse.

Credential Access

High

Category: Privilege Escalation
Content: | Service / token type | Primary store (preferred) | Persist command | Reuse path | |---------------------|---------------------------|-----------------|------------| | GitHub PAT (classic / fine-grained) | **gh CLI keyring** (OS-native — macOS Keychain / Windows Credential Manager / libsecret) | `echo <token> \| gh auth login --hostname github.com --with-token` | `gh auth token -u <user>` (and Docker uses `~/.docker/config.json` after `docker login` once) | | GitHub Actions repo/org secret | **GitHub secret store** | `gh secret set <NAME> -b<token>` | Workflow `${{ secrets.NAME }}` | | AWS access key / secret | **Vault** (preferred) or `~/.aws/credentials` profile | `vault kv put secret/aws/<profile> access_key=... secret_key=...` OR `aws configure --profile <name>` | `AWS_PROFILE=<name>` / `vault kv get -field=secret_key secret/aws/<profile>` | | Cloudflare R2 S3 token | **Vault** | `vault kv put secret/r2/<bucket> access_key=... secret_key=...` | `vault kv get -field=secret_key secret/r2/<bucket>` |
Confidence: 86% confidence
Finding: Explicit use of OS Keychain/Credential Manager/libsecret as part of automated token persistence means the skill is designed to interact with high-trust credential stores. In the context of a browser automation skill that also extracts tokens from pages, this materially increases the sensitivity of the workflow and the consequences of misuse.

Credential Access

High

Category: Privilege Escalation
Content: | 9 | Treat "wait for user" as applying to the entire issuance flow | "Wait for user" applies to **(a) interactive login** and **(b) token reveal/copy when the token is masked or only shown once outside the DOM**. Token generation form-filling and "Create" click are backend-automatable when the user is logged in | | 10 | Suggest revoke/Delete the freshly issued credential because it appeared in chat output ("token exposed → revoke first") | Persistence wins. Run step 6 Persist (Service × Store matrix) **before** any revoke consideration. Revoke is a separate explicit user decision; chat-exposure-triggered auto-revoke is forbidden. Reusing the token across sessions is the design goal | | 11 | Skip step 6 Persist ("we'll just use it in this session") | Persist is HARD STOP. Every credential issuance ends in the secret store, not in shell history alone. Future sessions retrieve, not re-issue | | 12 | Treat the matrix as PAT-only — pick gh keyring for everything | Match the row to the credential type. AWS keys → vault/`~/.aws`, OCI → `~/.oci/config`, Vault root → password manager (Vault can't store itself), Anthropic → vault/`.env`. Wrong row = unusable persistence | ### Scope expansion / token refresh (HARD STOP — Settings UI first, CLI fallback)
Confidence: 87% confidence
Finding: The text normalizes selecting a persistence backend such as gh keyring for credential storage as part of the default flow. That reinforces a design where the agent handles durable secret storage routinely, increasing the risk of over-collection and retention if invoked in the wrong context.

Credential Access

High

Category: Privilege Escalation
Content: | 4. Click "Create" / "Generate" | **Backend** (`click`) | Automatable | | 5. Extract the issued token value | **Backend** (`take_snapshot` → parse the textbox containing the token) — fallback to user copy only when the token is masked / behind a copy-only button | The token is visible in the page after generation; extract directly. User-typed input is fragile (typos, partial paste) | | 6. Handoff (`gh secret set`, `vault kv put`, local CLI publish) | **Backend** (Bash) | Mandatory automation | | 7. Persist for reuse (skill `data/secrets/`, keychain) | **Backend** (Write) | Mandatory automation | ### Backend automation failure cascade (HARD STOP — before falling back to user copy)
Confidence: 91% confidence
Finding: Assigning the backend responsibility for persisting credentials into skill data or keychain makes durable credential access a built-in capability of the agent. In context, this is more dangerous because the same skill also directs browser-based token extraction, enabling end-to-end secret capture and retention under automation control.

Credential Access

High

Category: Privilege Escalation
Content: | `vsce` (VS Code Marketplace publisher) / issue Azure DevOps PAT for `vsce publish` | ❌ UI-only (Azure DevOps Personal Access Token) | `https://dev.azure.com/<org>/_usersSettings/tokens` — `<org>` is the Azure DevOps organization linked to the Marketplace publisher (if not provided by caller, **ask via AskUserQuestion** before opening the page). Sign in via "Sign in with GitHub" SSO (see "Login provider preference" above). Token scope: `Marketplace > Manage` | `gh secret set VSCE_PAT -R <owner>/<repo>` + local `npx vsce publish --packagePath <vsix> --pat $VSCE_PAT` | | `ovsx` (Open VSX Registry publisher) / issue Open VSX PAT for `ovsx publish` | ❌ UI-only | `https://open-vsx.org/user-settings/tokens` — sign in via the **GitHub** option (Open VSX is GitHub-SSO native) | `gh secret set OVSX_PAT -R <owner>/<repo>` + local `npx ovsx publish <vsix> -p $OVSX_PAT` | | any / register a GitHub Secret | ✅ `gh secret set` | (not needed) | — | | `tailscale` / revoke an auth key | ✅ API revoke available — `DELETE /api/v2/tailnet/:tailnet/keys/:keyID` (requires an access token / fine-grained trust-credential with key-management scope; console-only if no such token is already available) | `https://login.tailscale.com/admin/settings/keys` → sign in → locate the key by its ID/name → delete (fallback when no API token exists) | none (revoke has no follow-up handoff — see "Revoke flow" above) | ## Note on GitHub PR image hosting (why R2)
Confidence: 84% confidence
Finding: This scenario explicitly contemplates handling an access token with sufficient scope to revoke Tailscale keys or fall back to browser-assisted key management. While operationally plausible, it grants the skill authority over powerful credentials and account-management actions, which is sensitive and can be abused if account identity or intent is mis-scoped.

Tool Parameter Abuse

High

Category: Tool Misuse
Content: | `vsce` (VS Code Marketplace publisher) / issue Azure DevOps PAT for `vsce publish` | ❌ UI-only (Azure DevOps Personal Access Token) | `https://dev.azure.com/<org>/_usersSettings/tokens` — `<org>` is the Azure DevOps organization linked to the Marketplace publisher (if not provided by caller, **ask via AskUserQuestion** before opening the page). Sign in via "Sign in with GitHub" SSO (see "Login provider preference" above). Token scope: `Marketplace > Manage` | `gh secret set VSCE_PAT -R <owner>/<repo>` + local `npx vsce publish --packagePath <vsix> --pat $VSCE_PAT` | | `ovsx` (Open VSX Registry publisher) / issue Open VSX PAT for `ovsx publish` | ❌ UI-only | `https://open-vsx.org/user-settings/tokens` — sign in via the **GitHub** option (Open VSX is GitHub-SSO native) | `gh secret set OVSX_PAT -R <owner>/<repo>` + local `npx ovsx publish <vsix> -p $OVSX_PAT` | | any / register a GitHub Secret | ✅ `gh secret set` | (not needed) | — | | `tailscale` / revoke an auth key | ✅ API revoke available — `DELETE /api/v2/tailnet/:tailnet/keys/:keyID` (requires an access token / fine-grained trust-credential with key-management scope; console-only if no such token is already available) | `https://login.tailscale.com/admin/settings/keys` → sign in → locate the key by its ID/name → delete (fallback when no API token exists) | none (revoke has no follow-up handoff — see "Revoke flow" above) | ## Note on GitHub PR image hosting (why R2)
Confidence: 80% confidence
Finding: Documenting a direct DELETE endpoint for key revocation, combined with a parameterized key ID, creates a pathway for destructive actions if inputs are wrong, injected, or insufficiently confirmed. In a skill that automates credential operations, this becomes dangerous because a mistaken or manipulated identifier could revoke the wrong key and cause denial of service or account disruption.

VirusTotal

VirusTotal findings are pending for this skill version.

View on VirusTotal

Static analysis

No suspicious patterns detected.