Back to skill

Security audit

Funpay Assistant

Security checks for vulnerabilities and agentic risk

Overview

This FunPay chat assistant is purpose-aligned overall, but it ships an account credential and private chat/order state in the package and can automatically message customers from that account.

Review this carefully before installing. The publisher should remove and rotate the embedded FunPay token, ship only empty example state, require the installer to provide their own credential securely, disclose automated messaging, and add explicit operator approval for sensitive account-access replies.

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

T09 · Insecure Skill Coding Practices

Error
Location
monitor.py:11
Finding
Hardcoded FunPay Authentication Credential## Vulnerability Details **File Location**: `monitor.py:11` (credential), used at `monitor.py:44` **Vulnerability Type**: Hardcoded authentication secret **Risk Level**: High ### Vulnerable Code ```python GOLDEN_KEY = "r7sb47vn2sq6vhziu7veeh8eh31j02bz" ``` The credential is subsequently used to authenticate the account: ```python acc = Account(GOLDEN_KEY).get() ``` ### Technical Analysis A FunPay authentication credential is embedded directly in the source code. Unlike a configuration placeholder, this value is passed to `Account` and used to establish an authenticated FunPay session. Source-controlled secrets can be recovered from distributed archives, repository clones, backups, build artifacts, and version-control history. Removing the value from only the latest revision would not protect it if previous copies remain accessible. ### Attack Path 1. An attacker obtains a copy of the project or its source history. 2. The attacker reads the `GOLDEN_KEY` constant from `monitor.py`. 3. The attacker supplies the recovered key to the FunPay API client or an equivalent compatible request flow. 4. If the credential remains valid, the attacker authenticates as the associated FunPay account. 5. The attacker accesses account data or performs actions permitted by that authenticated session. No active exploitation was performed during this static audit. ### Impact Assessment Successful exploitation may expose the associated FunPay account's chats and customer information. It may also permit unauthorized message transmission and any other account operations granted by the credential and the FunPay API. The scope is limited by the privileges of the exposed credential, but compromise could affect the entire associated account rather than only one chat. Credential validity and exact server-side permissions were not verified.
Remediation
## Remediation Suggestions 1. Revoke and rotate the exposed FunPay credential immediately. 2. Remove the credential from the current source tree and purge it from version-control history and distributed artifacts. 3. Read the credential from a protected environment variable or secret manager: ```python GOLDEN_KEY = os.environ.get("FUNPAY_GOLDEN_KEY") if not GOLDEN_KEY: raise RuntimeError("FUNPAY_GOLDEN_KEY is not configured") ``` 4. Ensure secrets are not printed in logs or exception output. 5. Restrict access to deployment secrets according to least privilege. 6. Add automated secret scanning to commits and build pipelines. 7. Review account activity for unauthorized access occurring after the credential was exposed.

T09 · Insecure Skill Coding Practices

Warning
Location
state.json:2
Finding
Plaintext Customer Communications and Transaction Metadata Included in Runtime State## Vulnerability Details **File Location**: `state.json:2-57` **Vulnerability Type**: Plaintext storage and distribution of sensitive customer data **Risk Level**: Medium ### Vulnerable Data The committed state contains chat identifiers, message contents, usernames, and order identifiers. Representative complete entries include: ```json "last_message_texts": { "239144364": "уволен.", "239099466": "Покупатель irooler подтвердил успешное выполнение заказа #JTYQL57S и отправил деньги продавцу D0g9y." } ``` It also retains chat workflow state: ```json "auto_replied_chats": [ "239122985", "238962150" ] ``` ### Technical Analysis `state.json` is a live runtime-state file distributed as part of the project. It stores customer communications and transaction metadata in plaintext, including chat IDs, usernames, order IDs, and account-related conversation details. The application writes this data through `save_state()` without encryption, access-control hardening, retention limits, or data minimization. Anyone who receives the project archive or gains read access to its directory can inspect the records without authenticating to FunPay. ### Attack Path 1. An attacker obtains the project archive, repository contents, backup, or read access to the application directory. 2. The attacker opens `state.json`; no decryption key or FunPay authentication is required. 3. The attacker extracts chat IDs, usernames, order identifiers, and message contents. 4. The attacker correlates those records to profile transactions or prepare targeted phishing and social-engineering messages. This exposure requires access to a copy of the project or its runtime directory. The audit found no code that independently transmits `state.json` to an unauthorized external destination. ### Impact Assessment The exposed data reveals private customer communications and transaction metadata. Potential consequences include ...[truncated 341 chars]
Remediation
## Remediation Suggestions 1. Remove the populated `state.json` from the distributed project and purge historical copies where feasible. 2. Add `state.json` to version-control and packaging exclusion rules. 3. Distribute only an empty schema example, such as: ```json { "last_message_texts": {}, "auto_replied_chats": [] } ``` 4. Store runtime state outside the source directory in an application-specific data directory. 5. Apply restrictive filesystem permissions so only the service account can read or modify the state. 6. Minimize retained data. Prefer message IDs or hashes over complete message bodies when duplicate detection does not require plaintext. 7. Define and enforce a retention period that deletes stale chat and transaction records. 8. Consider authenticated encryption if sensitive message content must remain on disk. 9. Review repository history, release archives, logs, and backups for additional copies and follow applicable incident-response or notification requirements.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (8)

Context-Inappropriate Capability

High
Confidence
99% confidence
Finding
The file contains a hardcoded FunPay token and uses it to authenticate as an account, read private chats, and send automated replies. This creates unauthorized account-access and impersonation risk, and the surrounding logic explicitly automates conversations about accessing a buyer's account, which makes the behavior more sensitive than ordinary chat tooling.

Missing User Warnings

High
Confidence
100% confidence
Finding
A hardcoded account credential is embedded directly in source code, making compromise likely through source sharing, logging, backups, or repository exposure. Anyone obtaining the file can authenticate to the FunPay account and read or send messages as that account.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
Telegram notifications about consent to log into an account imply transmission of account-related events to a third-party messaging platform, yet the description provides no warning or safeguards around sensitive data handling. Even if only event metadata is sent, this can expose account activity patterns or identifiers and may leak sensitive information if notifications include usernames, chat excerpts, or account details.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The skill explicitly states that unrecognized messages are forwarded to the owner, but there is no indication that users are warned or that message contents are minimized before forwarding. This creates a privacy risk because arbitrary user messages may contain personal, account, or transaction information that is transmitted to another recipient without informed consent.

Natural-Language Policy Violations

Medium
Confidence
78% confidence
Finding
The predefined reply strings at L016-L018 are only in Russian, and the script automatically uses them for outgoing messages. There is no opt-in, language selection, or documented region-specific justification, which creates a natural-language locale policy concern.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The script automatically sends outbound messages to users without clear disclosure that replies are automated or operator-approved. This can mislead counterparties, facilitate impersonation, and create social-engineering or compliance risks, especially because the messages concern troubleshooting and potential account access.

Natural-Language Policy Violations

Medium
Confidence
87% confidence
Finding
The message states that "by FunPay rules" mentioning proxy or VPN services is forbidden and continues entirely in Russian, but more importantly the file contains user-facing natural-language content with no indication that language choice is optional. This creates a locale/language policy concern when a skill or workflow may implicitly force communication in a specific language without offering user choice.

Intent-Code Divergence

Low
Confidence
90% confidence
Finding
The inline comment 'Пересылка админу' indicates an action of forwarding messages to an admin. In reality, the code merely accumulates formatted notification strings and later prints them, which contradicts the stated behavior in the comment.

Static analysis

No suspicious patterns detected.