Back to skill

Security audit

Proof Of Contribution

Security checks for vulnerabilities and agentic risk

Overview

This skill is related to its stated Bitcoin payment purpose, but it asks users to rely on third-party financial and CI infrastructure without enough scoping or safety guidance.

Review this carefully before installing. If you use it, pin the GitHub Action to a reviewed commit SHA, set minimal workflow permissions, avoid exposing unrelated secrets, verify the btcvision.org and payment/support domains yourself, and treat any wallet or payout setup as a financial integration requiring explicit user confirmation.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:27
Finding

GitHub Action Referenced by a Mutable Version Tag

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 27–31
Vulnerability Type: Supply-chain risk caused by an unpinned third-party GitHub Action
Risk Level: Medium

yaml
- uses: welove111/proof-of-contribution@v1
  with:
    lightning_address: ${{ secrets.LIGHTNING_ADDRESS }}
    package_name: 'your-package-name'
    package_registry: 'npm'

Technical Analysis

The documented workflow references the third-party Action through the mutable v1 tag instead of a reviewed, immutable commit SHA. The repository owner can move this tag to a different commit, and compromise of the upstream repository could similarly alter the code resolved by the tag. Consequently, users following the instructions may execute code that differs from the version originally audited.

This is security-sensitive because a GitHub Action executes on the workflow runner and receives the configured Lightning address secret as an input. Depending on the surrounding workflow configuration, the Action may also be able to read repository contents, access workflow context, use the permissions granted to GITHUB_TOKEN, modify workspace files, or communicate with external systems.

Attack Path

  1. A user copies the workflow example into a repository.
  2. The upstream owner moves v1 to a malicious commit, or an attacker compromises the upstream Action repository and changes the tag.
  3. A subsequent workflow run resolves welove111/proof-of-contribution@v1 to the altered code.
  4. GitHub downloads and executes that code on the workflow runner.
  5. The malicious Action reads the inputs and other data available to the job, including LIGHTNING_ADDRESS, and may transmit accessible information externally.
  6. If the workflow grants write permissions, the malicious code may also modify repository resources within the scope of the workflow token.

Impact Assessment

Exploitation permits attacker-controlled code execution in the co ...[truncated 444 chars]

Remediation
View remediation

Remediation Suggestions

  • Replace the mutable tag with the full commit SHA of a reviewed Action revision, for example:
    yaml
    - uses: welove111/proof-of-contribution@FULL_40_CHARACTER_COMMIT_SHA
    
  • Retain the release version in a comment for maintainability while keeping the executable reference immutable.
  • Review the pinned Action source and its transitive dependencies before adoption.
  • Use dependency-management tooling, such as Dependabot, to propose controlled SHA updates that receive security review before merging.
  • Declare explicit least-privilege workflow permissions, using permissions: {} by default and enabling only permissions required by the job.
  • Avoid exposing unrelated secrets to the job and prefer environment-level protections for sensitive workflows.
  • Use ephemeral GitHub-hosted runners where possible. If self-hosted runners are necessary, isolate them from sensitive networks and credentials.
  • Restrict outbound network access or monitor Action traffic where the runner environment supports such controls.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The trigger conditions are broad enough to invoke the skill for generic payment or Bitcoin-related conversations, not just explicit requests to configure this specific GitHub Action. In a finance/crypto context, overbroad invocation increases the chance the agent will surface guidance that nudges users toward external payment infrastructure without adequate relevance, review, or consent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill embeds a direct POST example to a third-party endpoint without explaining what data is sent, what trust boundary is crossed, or what privacy/security considerations apply. In a crypto/payment-themed skill, this is more dangerous because users may normalize contacting external services tied to financial workflows, potentially exposing metadata or enabling phishing-style redirection to unvetted infrastructure.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.