Back to skill

Security audit

Get local help for shifts and tasks (Blossomai.org)

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly clear and purpose-aligned, but it relies on a permanent Blossom account API key without expiry, scopes, or self-service revocation.

Review this before installing if you plan to use Blossom for real hiring or applications. The skill asks for personal/job data and can perform account actions after confirmation. The main risk is that the returned API key is long-lived; keep it only in secure credential storage, avoid logs or chats, and understand that exposed keys require contacting Blossom support to rotate or revoke.

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

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:26
Finding

Permanent Unscoped Bearer Token Lacks Expiry and Self-Service Revocation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:26-28, SKILL.md:153-154, and SKILL.md:302-308
Vulnerability Type: Permanent, unscoped account credential with inadequate lifecycle controls
Risk Level: Medium

Evidence

text
The returned API key is permanent and grants account access.
Store it only in secure credential storage, never in source code, plaintext
configuration, logs, or conversation history.
text
Persist `apiKey` securely and reuse it as the Bearer token. Persist `personId`
only as the account identifier. Do not persist `passKey`.
text
The protocol currently exposes no scoped keys, expiry, password-based protocol
login, or self-service revocation. If the API key is unavailable, do not ask
`/ask` to authenticate or recreate identity. Re-register only if the user
intends to create a distinct new account. If a key may have been exposed, stop
using it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate
or revoke access.

Technical Analysis

The Skill requires a permanent Bearer API key for all authenticated operations through /ask. The key grants account access but has no documented expiration, restricted scope, automated rotation, or self-service revocation mechanism. Read operations and consequential marketplace mutations therefore rely on the same long-lived credential.

Secure credential storage reduces the likelihood of disclosure but does not limit the consequences after disclosure. Because Bearer authentication treats possession as authority, an attacker who obtains the key can submit authenticated requests without an additional authentication factor. The absence of expiry allows continued use until the operator manually rotates or revokes the credential.

The network transmission itself is disclosed, limited to the declared Blossom HTTPS service, and generally necessary for the Skill's functionality. The weakness concerns crede ...[truncated 2008 chars]

Remediation
View remediation

Remediation Suggestions

  1. Replace permanent API keys with short-lived access tokens and securely rotated refresh tokens.
  2. Add self-service credential inventory, immediate revocation, and rotation controls without requiring support intervention.
  3. Scope tokens by capability, separating read access from role, address, application, and scheduling mutations.
  4. Use narrowly scoped, time-limited authorization for destructive or privacy-sensitive operations.
  5. Require recent user reauthorization or step-up authentication for deletion, application submission, address changes, and other consequential actions.
  6. Detect token reuse from anomalous devices, locations, or request patterns and automatically suspend suspicious credentials.
  7. Preserve the existing secure-storage requirements while explicitly preventing tokens from entering conversation history, telemetry, backups, crash reports, and diagnostic logs.
  8. Document a tested incident-response workflow that invalidates exposed tokens immediately and notifies affected users.
  9. Where compatibility requires long-lived keys, allow users to create multiple named keys with least-privilege scopes, expiration dates, last-used metadata, and independent revocation.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • 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
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.