Security audit

hup-miniapp

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent for building Hup wallet mini apps, but it relies on mutable remote instructions and ships a wallet demo that dynamically executes unpinned SDK code.

Install only if you are comfortable with the agent consulting Hup's live documentation during builds. Treat the bundled demo as a development reference, not production-ready code, and pin or control the SDK source before using it with real wallet sessions or deployed mini apps.

A.I.G

Vulnerability Patterns

Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs

Findings (2)

T01 · Skill Instruction Hijacking

Warning

Location: SKILL.md:26
Finding: Mutable Remote Specification Is Treated as Authoritative Agent Instruction<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 26–31 **Vulnerability Type**: Remote instruction trust and post-review instruction mutability **Risk Level**: Medium ### Vulnerable Code ```markdown ## Canonical Reference The live, always-current specification is: ``` https://hup.social/miniapp-skill.md ``` Fetch it before building — it is the source of truth for the SDK surface and wallet policy. ``` ### Technical Analysis The Skill explicitly instructs the Agent to retrieve a mutable remote document before performing its task and declares that document to be the authoritative source of truth. Because the remote document is not included in the audited package and is not pinned to a version or cryptographic digest, its effective instructions can change after the Skill has been reviewed. This creates an instruction trust boundary that is controlled by the operator of `hup.social` or by anyone who compromises the hosting infrastructure. A modified document could introduce instructions unrelated to the declared mini-app development purpose, request unsafe wallet behavior, redirect the Agent to additional untrusted resources, or attempt to override the Agent's existing goals and safety constraints. The audited repository does not contain evidence that the current remote document is malicious. The vulnerability is the unconditional delegation of authority to unaudited, mutable remote instructions. ### Attack Path 1. An attacker compromises the server, deployment pipeline, DNS resolution, or account responsible for `https://hup.social/miniapp-skill.md`. 2. The attacker modifies the remote specification to include hostile Agent instructions. 3. A user invokes the installed Skill for a Hup mini-app task. 4. Following `SKILL.md`, the Agent fetches the remote document before building. 5. The Agent treats the attacker-controlled document as the source of truth. 6. The injected instructions influence generated code or subsequent Agent actio ...[truncated 677 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Make the bundled `references/miniapp-guide.md` snapshot the authoritative specification for audited Skill behavior. 2. If remote updates are required, reference an immutable versioned URL and verify the downloaded document against a pinned cryptographic digest. 3. Treat remote documentation as untrusted reference material rather than executable or authoritative Agent instruction. 4. Explicitly state that remote content must not override system instructions, user requirements, safety controls, or the Skill's reviewed scope. 5. Compare remote updates against the bundled version and require user approval before applying material behavioral changes. 6. Re-audit and release a new Skill version whenever the authoritative SDK or wallet policy changes. ]]>

T03 · Remote Payload Retrieval and Execution

Error

Location: references/demo-app.html:131
Finding: Demo Dynamically Executes Unpinned SDK Code from Multiple Unsafe Sources<![CDATA[ ## Vulnerability Details **File Location**: `references/demo-app.html`, lines 131–151 **Vulnerability Type**: Unverified remote payload execution and insecure SDK sourcing **Risk Level**: High ### Vulnerable Code ```html  <script> const SDK_SOURCES = ['/miniapp-sdk.js', '../../public/miniapp-sdk.js', 'https://hup.social/miniapp-sdk.js'] function loadSdk(index) { if (index >= SDK_SOURCES.length) { document.getElementById('s-sdk').textContent = 'SDK failed to load' document.getElementById('s-sdk').className = 'bad' return } const script = document.createElement('script') script.src = SDK_SOURCES[index] script.onload = () => window.startDemo() script.onerror = () => { script.remove() loadSdk(index + 1) } document.head.appendChild(script) } </script> ``` ### Technical Analysis The demo dynamically creates a script element and executes the first SDK source that loads successfully. Two unauthenticated same-origin paths are preferred over the declared official Hup SDK: ```javascript '/miniapp-sdk.js' '../../public/miniapp-sdk.js' ``` The final fallback, `https://hup.social/miniapp-sdk.js`, is also mutable and unversioned. None of the sources is validated using a cryptographic digest, Subresource Integrity, a signed manifest, or equivalent authenticity control. A file located at either preferred path can therefore impersonate the SDK. This is especially dangerous because the loaded code executes in the mini app's origin and initializes before the demo obtains the wallet provider. A substituted SDK can redefine the `sdk` and `hup` globals, intercep ...[truncated 2141 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the opportunistic multi-path fallback loader. Do not execute whichever file happens to exist first. 2. Use one explicitly selected and reviewed SDK artifact. 3. Prefer bundling a verified SDK version with the application or referencing an immutable, versioned distribution URL. 4. Verify external assets with Subresource Integrity where the delivery model supports it: ```html <script src="https://trusted.example/miniapp-sdk.VERSION.js" integrity="sha384-PINNED_DIGEST" crossorigin="anonymous"> </script> ``` 5. If the SDK is served from the application origin, ensure it is part of the controlled build output and cannot be supplied by uploaded files or unrelated server routes. 6. Apply a restrictive Content Security Policy that permits scripts only from the selected trusted source and disallows unexpected script origins. 7. Pin deployed artifacts by digest and verify them during CI/CD deployment. 8. Clearly separate development and production loaders. Development fallback behavior must not be shipped in a production reference implementation. 9. Preserve host-side transaction validation and ensure confirmation dialogs display the complete destination, value, calldata, chain, and signing payload. ]]>

SkillSpector

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

Findings (2)

Ae1

High

Category: analysis-evasion
Content: (connect, sign, send, policy checks) is in `references/demo-app.html`.
Confidence: 100% confidence
Finding: Referenced artifact was not completely inspected

Hidden Instructions

High

Category: Prompt Injection
Content: <pre id="log"></pre>
Confidence: 70% confidence
Finding: Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Static analysis

No suspicious patterns detected.