Back to skill

Security audit

Molt

Security checks for vulnerabilities and agentic risk

Overview

The MoltFundMe skill instructions are mostly coherent, but the bundled platform and deployment materials contain high-impact authentication, KYC, credential, and host-privilege risks that should be reviewed before use.

Install or use this only with explicit user approval for any public post, upvote, evaluation, advocacy, profile change, or upload. Do not follow the production deployment guide as-is: use least-privilege deployment accounts, unique SSH keys, read-only package tokens, pinned and verified installers, hardened secret storage, and proper KYC review before accepting real campaigns or donations.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (7)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
api/app/api/routes/auth.py:25
Finding
Magic-Link Token Disclosure Enables Authentication Bypass<![CDATA[ ## Vulnerability Details **File Location**: `api/app/api/routes/auth.py:25-66` **Vulnerability Type**: Authentication token disclosure and account takeover **Risk Level**: Critical ### Vulnerable Code ```python token = create_magic_link_token() expires_at = datetime.now(timezone.utc) + timedelta( minutes=settings.magic_link_expire_minutes ) try: magic_link = MagicLink( email=request.email, token=token, expires_at=expires_at, ) creator_query = select(Creator).where(Creator.email == request.email) creator_result = await db.execute(creator_query) creator = creator_result.scalar_one_or_none() if not creator: creator = Creator(email=request.email) db.add(creator) await db.flush() db.add(magic_link) await db.commit() if email_service.is_configured(): await email_service.send_magic_link( to_email=request.email, token=token, frontend_url=settings.frontend_url, ) return MagicLinkResponse( success=True, message="Check your email for the sign-in link.", ) return MagicLinkResponse( success=True, message=f"Magic link created. Token: {token} (dev only - don't expose in production)", ) except Exception as e: await db.rollback() raise HTTPException(status_code=500, detail=f"Failed to create magic link: {str(e)}") ``` ### Technical Analysis The application returns a valid magic-link token directly in the HTTP response whenever the email service is not configured. This behavior is controlled only by `email_service.is_configured()` and is not restricted to a development or test environment. Production orchestration permits an empty `RESEND_API_KEY`, so a production instance can enter this insecure branch. Because callers can supply an arbitrary email address, an unauthenticated attacker can request a token for another creator's email address and use i ...[truncated 992 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Never return authentication tokens in an API response from the magic-link request endpoint. - Explicitly gate any development-only behavior using a dedicated test setting, and reject startup if that setting is enabled in production. - In production, fail closed when the email service is unavailable. - Require successful delivery through a verified email channel before allowing token redemption. - Add per-IP and per-email rate limits to the magic-link request and verification endpoints. - Return the same generic response for existing and non-existing accounts. - Record token issuance and redemption events for abuse detection. - Consider storing only a cryptographic hash of each magic-link token. - Invalidate previously issued unconsumed tokens when a new token is generated. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
api/app/api/routes/kyc.py:126
Finding
KYC Submissions Are Automatically Approved Without Identity Verification<![CDATA[ ## Vulnerability Details **File Location**: `api/app/api/routes/kyc.py:126-137` **Related Authorization Gate**: `api/app/api/deps.py:69-82` **Vulnerability Type**: Verification and authorization bypass **Risk Level**: Critical ### Vulnerable Code ```python submission = KYCSubmission( creator_id=creator.id, id_photo_path=id_relative_path, selfie_photo_path=selfie_relative_path, submitted_date=submitted_date, status="approved", # Auto-approve initially ) db.add(submission) # Update creator KYC status creator.kyc_status = "approved" # Auto-approve creator.kyc_flagged_for_review = True # Flag for manual review creator.kyc_submitted_at = utc_now() creator.kyc_attempt_count += 1 ``` The resulting status is used directly as an authorization decision: ```python async def get_required_kyc_creator( creator: Creator = Depends(get_required_creator) ) -> Creator: """Require a valid creator with approved KYC.""" if creator.kyc_status != "approved": raise HTTPException( status_code=status.HTTP_403_FORBIDDEN, detail={ "code": "KYC_REQUIRED", "message": "KYC verification required", "kyc_status": creator.kyc_status, } ) return creator ``` ### Technical Analysis Uploading two files with permitted filename extensions immediately changes the creator's KYC state to `approved`. No identity-verification provider, authorized reviewer decision, image analysis, document validity check, or ownership validation occurs before approval. The `kyc_flagged_for_review` flag does not mitigate the issue because campaign authorization checks only whether `creator.kyc_status == "approved"`. Therefore, the application grants financially sensitive privileges before the purported manual review occurs. ### Attack Path 1. Obtain a creator JWT, either legitimately or through the magic-link disclosure vulnerability. 2. Prepare arbitrary files nam ...[truncated 789 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Set all new KYC submissions to `pending`. - Grant `approved` status only after a successful decision from a trusted KYC provider or an authenticated, authorized reviewer. - Separate submission state, review state, and authorization state. - Record reviewer identity, decision time, provider reference, and reason for every status transition. - Require positive document authenticity, liveness, identity matching, and sanctions checks appropriate to the platform's obligations. - Ensure `kyc_flagged_for_review` prevents campaign publication rather than merely recording a flag. - Add server-side state-transition controls so ordinary creator endpoints cannot set or influence approval. - Revoke or suspend campaign privileges when an approval is reversed. - Review and invalidate all approvals created by the current automatic process. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
api/app/api/routes/kyc.py:75
Finding
KYC Documents Receive Extension-Only Validation and Potentially Permissive Storage<![CDATA[ ## Vulnerability Details **File Location**: `api/app/api/routes/kyc.py:75-116` **Related Deployment Configuration**: `DEPLOY.md:131-133` **Vulnerability Type**: Insecure sensitive-file upload and storage **Risk Level**: High ### Vulnerable Code ```python # Validate file types (jpg, png only) allowed_extensions = {".jpg", ".jpeg", ".png"} id_ext = Path(id_photo.filename).suffix.lower() selfie_ext = Path(selfie_photo.filename).suffix.lower() if id_ext not in allowed_extensions or selfie_ext not in allowed_extensions: raise HTTPException( status_code=status.HTTP_400_BAD_REQUEST, detail="Only JPG and PNG images are allowed" ) # Validate file sizes (max 10MB each) id_content = await id_photo.read() selfie_content = await selfie_photo.read() max_size = 10 * 1024 * 1024 # 10MB if len(id_content) > max_size or len(selfie_content) > max_size: raise HTTPException( status_code=status.HTTP_400_BAD_REQUEST, detail="File size must be less than 10MB" ) await id_photo.seek(0) await selfie_photo.seek(0) creator_dir = ensure_upload_directory(creator.id) timestamp = datetime.now(timezone.utc).strftime("%Y%m%d_%H%M%S") id_filename = f"id_photo_{timestamp}{id_ext}" selfie_filename = f"selfie_{timestamp}{selfie_ext}" id_path = creator_dir / id_filename selfie_path = creator_dir / selfie_filename id_relative_path = await save_upload_file(id_photo, id_path) selfie_relative_path = await save_upload_file(selfie_photo, selfie_path) ``` The host data directory is provisioned as follows: ```bash sudo mkdir -p /home/moltfund/molt-data sudo chown -R moltfund:moltfund /home/moltfund/molt-data sudo chmod 755 /home/moltfund/molt-data ``` ### Technical Analysis The server trusts the user-controlled filename extension and does not inspect image signatures, decode the image, validate dimensions, or re-encode the content. Arbitrary content can therefore be stored as a purported KYC image. Files are written using default pr ...[truncated 1270 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Validate file signatures and decode uploads using a maintained image-processing library. - Reject malformed, animated, multi-frame, oversized-dimension, and decompression-bomb images. - Re-encode accepted images into a controlled format and strip metadata. - Generate cryptographically random filenames rather than timestamp-only names. - Create KYC directories with mode `0700` and files with mode `0600`. - Run KYC storage under a dedicated service identity and keep it separate from publicly served uploads. - Encrypt documents at rest using managed keys. - Apply strict per-request, per-account, and global storage quotas. - Stream uploads with enforced limits rather than retaining multiple large files in memory. - Define retention and secure-deletion policies for rejected or expired submissions. - Audit all processes and users that can read `/home/moltfund/molt-data`. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
DEPLOY.md:12
Finding
Deployment Account Receives Unrestricted Passwordless Root Privileges<![CDATA[ ## Vulnerability Details **File Location**: `DEPLOY.md:12-17` **Vulnerability Type**: Excessive host privileges **Risk Level**: High ### Vulnerable Code ```bash # Add to sudo group (needed for initial setup) usermod -aG sudo moltfund # Allow passwordless sudo (no sudo typing required) echo "moltfund ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/moltfund chmod 0440 /etc/sudoers.d/moltfund ``` ### Technical Analysis The deployment guide permanently grants the `moltfund` account unrestricted command execution as root without requiring authentication. This violates least privilege because routine application deployment and container management do not require unlimited access to every host command and file. The same guide also adds the account to the Docker group. Docker daemon access is normally root-equivalent because a user can mount host filesystems into a privileged container. These overlapping privilege paths make compromise of the deployment account equivalent to immediate host compromise. ### Attack Path 1. Steal an SSH credential, CI credential, shell session, or token associated with the `moltfund` account. 2. Authenticate as `moltfund`. 3. Run an arbitrary command through `sudo` without a password, for example by launching a root shell. 4. Alternatively, use Docker access to mount the host root filesystem. 5. Read or modify application secrets, databases, KYC files, SSH configuration, services, and system binaries. ### Impact Assessment Compromise grants complete root control of the production host. An attacker can access all application and KYC data, extract secrets, alter deployed images, install persistence, modify firewall and SSH settings, impersonate the service, and destroy or encrypt backups. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Remove `NOPASSWD:ALL`. - Separate runtime, deployment, backup, and administrative identities. - Grant only narrowly scoped commands through sudoers when unavoidable. - Do not give the application or routine deployment account membership in the Docker group. - Use a controlled deployment service or rootless container runtime. - Require multi-factor protected administrative access and short-lived credentials. - Restrict deployment automation to signed, reviewed artifacts. - Monitor sudo, Docker, and SSH activity and alert on unexpected privilege use. - Periodically audit `/etc/sudoers.d`, group membership, and authorized keys. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
DEPLOY.md:19
Finding
Root SSH Authorization Is Duplicated onto a Root-Equivalent Deployment Account<![CDATA[ ## Vulnerability Details **File Location**: `DEPLOY.md:19-24` **Vulnerability Type**: Excessive credential scope and privilege expansion **Risk Level**: High ### Vulnerable Code ```bash # Copy SSH keys from root so you can SSH in as the new user mkdir -p /home/moltfund/.ssh cp /root/.ssh/authorized_keys /home/moltfund/.ssh/ chown -R moltfund:moltfund /home/moltfund/.ssh chmod 700 /home/moltfund/.ssh chmod 600 /home/moltfund/.ssh/authorized_keys ``` ### Technical Analysis The deployment process copies every key authorized for the root account to the `moltfund` account. The destination file permissions are correctly restrictive, but the authorization scope is not. Keys intended for emergency or tightly controlled root administration become valid credentials for the operational deployment account. Because that account is also configured with unrestricted passwordless sudo and Docker access, each copied key remains capable of obtaining full host control through a broader and more frequently used login path. ### Attack Path 1. Obtain any private key corresponding to an entry in root's `authorized_keys`. 2. Authenticate directly as `moltfund` using that key. 3. Invoke unrestricted passwordless sudo or use Docker daemon access. 4. Obtain root privileges and access all host and application resources. ### Impact Assessment The practice expands the number and purpose of credentials that can reach a root-equivalent account. Theft of any copied key can lead to complete production-host compromise, access to secrets and identity documents, service modification, and persistent unauthorized access. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Do not copy root's complete `authorized_keys` file. - Provision a dedicated deployment key with a clearly limited purpose. - Use short-lived SSH certificates rather than long-lived shared keys where possible. - Apply source-address, command, and forwarding restrictions to deployment credentials. - Maintain separate emergency administrative and routine deployment credentials. - Rotate existing keys after correcting the deployment procedure. - Disable direct root SSH access only after independently validating a restricted administrative path. - Audit authorization files centrally and remove obsolete keys promptly. ]]>

T08 · Insecure Dependencies

Error
Location
DEPLOY.md:55
Finding
Mutable Remote Installer Is Downloaded and Executed Without Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `DEPLOY.md:55-57` **Vulnerability Type**: Unsafe third-party bootstrap dependency **Risk Level**: High ### Vulnerable Code ```bash curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh rm get-docker.sh ``` ### Technical Analysis The deployment guide downloads a mutable shell script and immediately executes it during host provisioning. No immutable version, checksum, signature, or independently verified digest is specified. Although the referenced domain is Docker's recognized convenience installer, the effective code can change after this project is audited. Compromise of the upstream publication process, DNS or certificate trust, or the downloaded artifact could introduce arbitrary commands into a privileged provisioning workflow. ### Attack Path 1. An attacker compromises the remote installer publication path or otherwise causes modified content to be delivered. 2. An administrator follows the deployment guide. 3. `curl` downloads the altered script. 4. `sh get-docker.sh` executes the unverified content with provisioning privileges. 5. The script installs malware, steals credentials, modifies the host, or creates persistence. ### Impact Assessment Successful exploitation provides code execution at the privilege level used for provisioning, normally root. This permits complete host takeover, theft of secrets and KYC data, alteration of containers, and installation of persistent backdoors. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Install Docker from a verified package repository using pinned package versions. - Verify repository signing keys through an independent trusted channel. - Pin the expected installer or package digest. - Validate checksums or signatures before execution. - Retain installation logs and package provenance for auditability. - Test and promote immutable machine images rather than repeatedly executing mutable bootstrap scripts. - Run provisioning from reviewed infrastructure-as-code with controlled dependencies. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
api/app/api/routes/auth.py:64
Finding
Internal Exception Details Are Returned in HTTP Responses<![CDATA[ ## Vulnerability Details **File Location**: `api/app/api/routes/auth.py:64-66,118-120` **Additional Locations**: `api/app/api/routes/kyc.py:151-156`; `api/app/api/routes/campaigns.py:419-421` **Vulnerability Type**: Internal information disclosure **Risk Level**: Medium ### Vulnerable Code ```python except Exception as e: await db.rollback() raise HTTPException( status_code=500, detail=f"Failed to create magic link: {str(e)}" ) ``` ```python except Exception as e: await db.rollback() raise HTTPException( status_code=500, detail=f"Failed to verify token: {str(e)}" ) ``` Equivalent disclosure occurs in the KYC route: ```python except Exception as e: await db.rollback() raise HTTPException( status_code=status.HTTP_500_INTERNAL_SERVER_ERROR, detail=f"Failed to submit KYC: {str(e)}" ) ``` And in campaign creation: ```python except Exception as e: await db.rollback() raise HTTPException(status_code=500, detail=f"Failed to create campaign: {str(e)}") ``` ### Technical Analysis These handlers interpolate raw exception messages into externally visible HTTP responses. Depending on the failing subsystem, messages can reveal filesystem paths, database schema details, uniqueness constraints, library behavior, provider responses, or operational configuration. The global exception handler correctly returns a generic message, but these local handlers convert exceptions into `HTTPException`, bypassing that generic protection. ### Attack Path 1. Submit malformed, conflicting, oversized, or otherwise failure-inducing input to affected endpoints. 2. Trigger database, filesystem, email, or validation exceptions. 3. Read the raw exception text from the HTTP response. 4. Use disclosed paths, schema details, or service behavior to refine subsequent attacks. ### Impact Assessment The issue does not directly grant additional privileges, but it provides reconnaissance da ...[truncated 180 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Return generic failure messages such as `Internal server error`. - Log full exception details only on the server. - Attach a random correlation ID to the client response and corresponding log entry. - Ensure logs redact tokens, authorization headers, email-delivery credentials, KYC paths, and personal information. - Catch expected exception classes individually and map them to stable public error codes. - Allow unexpected errors to reach the existing global exception handler rather than exposing `str(e)`. - Add tests asserting that failure responses do not contain database, filesystem, provider, or stack-trace details. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (340)

Credential Access

High
Category
Privilege Escalation
Content
# Copy SSH keys from root so you can SSH in as the new user
mkdir -p /home/moltfund/.ssh
cp /root/.ssh/authorized_keys /home/moltfund/.ssh/
chown -R moltfund:moltfund /home/moltfund/.ssh
chmod 700 /home/moltfund/.ssh
chmod 600 /home/moltfund/.ssh/authorized_keys
Confidence
96% confidence
Finding
Creating and populating `/home/moltfund/.ssh/` from root's SSH authorization material provisions credentialed access in a way that reuses sensitive trust relationships. Because the new user is later made highly privileged, this turns simple account setup into a credential-propagation risk.

Credential Access

High
Category
Privilege Escalation
Content
# Copy SSH keys from root so you can SSH in as the new user
mkdir -p /home/moltfund/.ssh
cp /root/.ssh/authorized_keys /home/moltfund/.ssh/
chown -R moltfund:moltfund /home/moltfund/.ssh
chmod 700 /home/moltfund/.ssh
chmod 600 /home/moltfund/.ssh/authorized_keys
Confidence
96% confidence
Finding
Creating and populating `/home/moltfund/.ssh/` from root's SSH authorization material provisions credentialed access in a way that reuses sensitive trust relationships. Because the new user is later made highly privileged, this turns simple account setup into a credential-propagation risk.

Credential Access

High
Category
Privilege Escalation
Content
cp /root/.ssh/authorized_keys /home/moltfund/.ssh/
chown -R moltfund:moltfund /home/moltfund/.ssh
chmod 700 /home/moltfund/.ssh
chmod 600 /home/moltfund/.ssh/authorized_keys
```

---
Confidence
90% confidence
Finding
This line finalizes permissions on a new user's SSH authorization file that originated from root's authorized keys, cementing credential reuse rather than distinct identity management. The danger is the inherited root-trusted access, not the permission mode itself.

Credential Access

High
Category
Privilege Escalation
Content
cp /root/.ssh/authorized_keys /home/moltfund/.ssh/
chown -R moltfund:moltfund /home/moltfund/.ssh
chmod 700 /home/moltfund/.ssh
chmod 600 /home/moltfund/.ssh/authorized_keys
```

---
Confidence
90% confidence
Finding
This line finalizes permissions on a new user's SSH authorization file that originated from root's authorized keys, cementing credential reuse rather than distinct identity management. The danger is the inherited root-trusted access, not the permission mode itself.

Credential Access

High
Category
Privilege Escalation
Content
## 7. Setup GHCR Authentication on VM

```bash
# Create GitHub Personal Access Token (PAT) if you don't have one:
# Go to https://github.com/settings/tokens
# Generate new token (classic) with scopes: read:packages, write:packages
Confidence
92% confidence
Finding
Instructing users to generate a GitHub Personal Access Token with both `read:packages` and `write:packages` for VM registry login grants more privilege than necessary for pull-only deployment. Over-privileged long-lived credentials increase the impact of token leakage, including unauthorized image publication.

Credential Access

High
Category
Privilege Escalation
Content
docker pull ghcr.io/sahanico/moltfundme/api:latest
docker pull ghcr.io/sahanico/moltfundme/web:latest

# Note: Credentials are stored in ~/.docker/config.json
# To persist across reboots, ensure Docker service is enabled (already done in step 4)
```
Confidence
90% confidence
Finding
The guide explicitly notes that registry credentials are stored in `~/.docker/config.json` but does not instruct the operator to protect that file with a credential helper, least privilege, or file-permission checks. If exposed, an attacker could pull or possibly push images depending on token scope, enabling supply-chain abuse.

Credential Access

High
Category
Privilege Escalation
Content
git clone git@github.com:sahanico/moltfundme.git molt
cd molt

# Create .env from example
cp .env.example .env

# Edit .env with production values
Confidence
87% confidence
Finding
Creating a `.env` file for production secrets is common, but the guide gives no instructions for permission hardening, exclusion from backups/logs, or secret-management alternatives. This can lead to accidental exposure of application secrets such as `SECRET_KEY` and database configuration.

Credential Access

High
Category
Privilege Escalation
Content
cd molt

# Create .env from example
cp .env.example .env

# Edit .env with production values
nano .env
Confidence
87% confidence
Finding
Editing `.env` interactively to insert production secrets without accompanying guidance on terminal history, editor swap files, file permissions, or secret storage creates avoidable credential exposure risk. The issue is especially relevant because the document is otherwise positioned as operational guidance.

Credential Access

High
Category
Privilege Escalation
Content
# Create .env from example
cp .env.example .env

# Edit .env with production values
nano .env
# Required values:
# - ENV=production
Confidence
87% confidence
Finding
The instructions enumerate sensitive production values for insertion into `.env` but omit controls for protecting them at rest and in operational workflows. This can result in long-lived plaintext secrets being broadly accessible on disk.

Credential Access

High
Category
Privilege Escalation
Content
cp .env.example .env

# Edit .env with production values
nano .env
# Required values:
# - ENV=production
# - SECRET_KEY=<generate secure random string>
Confidence
88% confidence
Finding
The document specifically calls for a `SECRET_KEY` in `.env` yet provides no guidance on entropy requirements, storage protections, or rotation. Poor handling of this key could enable session forgery, token compromise, or broader application-level attacks depending on usage.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The description claims substantial crowdfunding-related functionality, but the provided code chunk does not implement any of it. Since the code only contains a comment ('API routes') and no executable logic, the declared purpose is not supported by the actual behavior shown. This is a material description-to-code mismatch due to absence of the advertised capabilities in the supplied code.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared purpose describes end-user crowdfunding and campaign advocacy functionality specific to MoltFundMe. The provided code does not browse campaigns, evaluate causes, participate in discussions, handle donations, or interact with MoltFundMe campaign data. Instead, it provides backend access-control helpers for identifying agents and creators from headers/tokens and enforcing KYC requirements. This is a materially different primary purpose and introduces undeclared security/authentication capabilities unrelated to the stated description.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
The declared description focuses on campaign discovery and advocacy activity on MoltFundMe. However, this code chunk is specifically an agents API module for identity/profile management. Its primary functions are creating agent accounts, issuing credentials, updating profiles, uploading avatars, and listing agent standings. While there is some relation to advocacy through leaderboard filtering and recent advocacy summaries, the main behavior is not campaign browsing, cause evaluation, donation participation, or war room discussion access. The API key creation and avatar file upload are also undeclared capabilities. Therefore the description does not accurately represent this code chunk's actual behavior.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description says this skill is for interacting with MoltFundMe crowdfunding campaigns and advocacy features. However, the supplied code is entirely focused on auth: generating magic-link tokens, persisting them, verifying expiration/usage, creating or retrieving user records, issuing JWTs, and handling logout. There is no campaign browsing, cause evaluation, war room discussion participation, karma earning, crowdfunding data access, or crypto donation functionality in this chunk. This is a materially different primary purpose, so the description does not accurately represent the code's behavior.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The code does relate to MoltFundMe crowdfunding campaigns, so part of the declared domain is accurate. However, the declared description emphasizes browsing, advocacy participation, war room discussions, and earning karma. This code chunk does not implement advocacy actions, war room discussion features, or karma-related behavior. Instead, it exposes substantial campaign administration and operational capabilities that are not declared: creating, editing, and cancelling campaigns; uploading and deleting campaign images; listing donations; generating social crawler OG pages; and refreshing blockchain balances with withdrawal detection and notification logic. Those are materially different backend capabilities beyond simple browsing/advocacy, so the description does not accurately represent the code's actual behavior.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
The declared description emphasizes public-facing MoltFundMe campaign discovery and advocacy features: discovering campaigns, evaluating causes, joining discussions, donating/advocating context, and earning karma. This code instead implements a backend endpoint for authenticated creators to retrieve their own campaigns. It uses creator authentication, queries campaigns by creator_id, includes cancelled campaigns, paginates results, and calculates campaign metrics such as donation counts, distinct donor counts, advocate counts, and creator verification status. That is a materially different function from browsing or advocating for campaigns. While it is still within the broader MoltFundMe/campaign domain, the primary behavior here is creator dashboard data retrieval, which is not accurately represented by the declared description.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description is about browsing and advocating for crowdfunding campaigns on MoltFundMe, but the code is entirely focused on creator identity verification workflows. It exposes endpoints for KYC status, KYC document submission, and submission history. It handles sensitive document uploads and updates creator verification state, which are materially different capabilities from campaign discovery, advocacy, war room participation, or karma earning. This is a clear description-behavior mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description promises substantial MoltFundMe-related functionality, but the provided code does not implement any of it. The code chunk is effectively a placeholder (__init__.py with only a comment), so the actual behavior does not match the declared primary purpose.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description suggests a feature for interacting with MoltFundMe campaigns and advocacy workflows. However, the supplied code does not browse campaigns, evaluate causes, participate in discussions, process donations, or handle karma. Its purpose is purely infrastructural: loading and validating application settings for a backend service. This is a materially different primary purpose from the declared user-facing crowdfunding functionality, so the description does not accurately represent the code.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description is about interacting with MoltFundMe crowdfunding campaigns and advocacy workflows. The supplied code does not browse campaigns, evaluate causes, support discussions, handle donations, or perform any crowdfunding-related actions. Instead, it provides backend infrastructure for limiting agent registration attempts by IP address. This is a materially different primary purpose and represents unrelated functionality not reflected in the declared description.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description says the skill should help users browse and advocate for MoltFundMe crowdfunding campaigns. However, the supplied code does not contain any campaign discovery, advocacy, discussion, donation, or MoltFundMe-specific logic. Its primary purpose is backend security infrastructure for credential and token handling. This is a materially different purpose and constitutes undeclared capabilities unrelated to the declared skill behavior.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared purpose is an end-user feature focused on browsing and advocating for crowdfunding campaigns on MoltFundMe. The actual code does not implement any campaign discovery, advocacy, donations, discussions, karma, or MoltFundMe-specific functionality. Instead, it provides generic backend middleware for setting security-related HTTP headers on responses. This is a materially different primary purpose and an unrelated capability, so it is a clear mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The declared description promises a user-facing crowdfunding advocacy skill centered on MoltFundMe, but the provided code chunk is only an empty database module stub with no functional logic. This is a material mismatch because the actual code does not exhibit the claimed primary purpose or capabilities.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
This code chunk is generic backend database setup, not application logic for browsing or advocating for crowdfunding campaigns. While database access could support such a system, the supplied code itself does not implement any MoltFundMe-specific behavior, campaign operations, crypto donation handling, or user-facing advocacy features described in the skill. The primary purpose is materially different from the declared description, so this is a clear mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
There is a clear mismatch between the declared purpose and the actual code behavior. The description promises end-user MoltFundMe crowdfunding features, but the code only initializes a database asynchronously. This is infrastructure/setup functionality, not campaign discovery, advocacy, discussion, or donation support. No MoltFundMe-specific logic or user-facing crowdfunding behavior is present in the supplied code chunk.

Static analysis

Detected: suspicious.env_credential_access, suspicious.exposed_secret_literal

Environment variable access combined with network send.

Critical
Code
suspicious.env_credential_access
Location
web/e2e/fixtures/api.fixture.ts:8

Environment variable access combined with network send.

Critical
Code
suspicious.env_credential_access
Location
web/e2e/global-setup.ts:9

Environment variable access combined with network send.

Critical
Code
suspicious.env_credential_access
Location
web/e2e/tests/api-endpoints.spec.ts:10

Environment variable access combined with network send.

Critical
Code
suspicious.env_credential_access
Location
web/e2e/tests/campaigns.spec.ts:8

Environment variable access combined with network send.

Critical
Code
suspicious.env_credential_access
Location
web/e2e/tests/feed.spec.ts:4

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
api/app/api/routes/auth.py:106

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
api/tests/integration/test_auth_agent_full_coverage.py:727