barkpush

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:45 AM UTC
• Version: 1.2.0

Overview

This Bark notification skill appears purpose-aligned, but it handles device keys, message contents, broadcasts, deletion, and local history with too little scoping or protection.

Install only if you trust the Bark server configured in `default_push_url`, protect device keys like credentials, and avoid sending sensitive notification bodies or clipboard values unless you accept they may be stored locally. Before using it broadly, restrict file permissions on the state directory, consider disabling update/history if not needed, avoid HTTP or unknown custom endpoints, and use `--user all` and `--delete` only after manually confirming the intended recipients and target message.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: bark_push/config_manager.py:205
• Finding: Unrestricted Bark Endpoint Allows Plaintext Disclosure of Device Credentials and Notification Data<![CDATA[ ## Vulnerability Details **File Location**: `bark_push/config_manager.py:205`, `bark_push/command_handler.py:36`, `bark_push/command_handler.py:236-240`, `bark_push/bark_api.py:19-28` **Vulnerability Type**: Unvalidated outbound endpoint and insecure transport **Risk Level**: Medium ### Vulnerable Code ```python # bark_push/config_manager.py:205 default_push_url = _require_str( raw, "default_push_url", "https://api.day.app", ) or "https://api.day.app" ``` ```python # bark_push/command_handler.py:36 self._api = BarkClient( base_url=self._config_mgr.config.default_push_url ) ``` ```python # bark_push/command_handler.py:236-240 for alias, device_key in zip(users.aliases, users.device_keys): single_payload = dict(payload) single_payload["device_key"] = device_key single_payload["_use_push_path"] = True resp = self._api.push_json(single_payload) ``` ```python # bark_push/bark_api.py:19-28 def __init__(self, base_url: str) -> None: self._base_url = base_url.rstrip("/") def push_json( self, payload: dict[str, Any], timeout_s: float = 10.0, ) -> BarkResponse: url = self._resolve_url(payload) body_bytes = json.dumps( payload, ensure_ascii=False, ).encode("utf-8") req = Request(url, data=body_bytes, method="POST") req.add_header("Content-Type", "application/json; charset=utf-8") try: with urlopen(req, timeout=timeout_s) as resp: ``` ### Technical Analysis The `default_push_url` configuration value is only checked for being a string. The implementation does not parse or validate its scheme, hostname, port, embedded credentials, or destination. The configured value is passed directly to `BarkClient`. During a push, the client adds the recipient's Bark `device_key` to the JSON payload and transmits the payload to that endpoint. The payload can also contain notification content, clipboard data, actions, and ciphertext-related parameters. Consequently, a config ...[truncated 2188 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Parse `default_push_url` with `urllib.parse.urlparse` before constructing `BarkClient`. 2. Require the `https` scheme for production endpoints. 3. If local development over HTTP is necessary, permit it only for explicit loopback addresses such as `127.0.0.1` and `::1`, and require a dedicated development option. 4. Reject malformed URLs, missing hostnames, embedded user credentials, fragments, and schemes other than HTTPS. 5. Consider using an allowlist containing `api.day.app` and explicitly approved custom Bark servers. 6. Require a clear confirmation when the configured host differs from the official endpoint. 7. Document that custom servers receive device keys and complete notification payloads. 8. Add tests confirming that cleartext remote URLs, unsupported schemes, and malformed endpoints are rejected. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: bark_push/history_manager.py:145
• Finding: Sensitive Device Keys and Notification Contents Are Persisted in Plaintext History Files<![CDATA[ ## Vulnerability Details **File Location**: `bark_push/command_handler.py:261-278`, `bark_push/history_manager.py:30-50`, `bark_push/history_manager.py:145-151`, `bark_push/config_manager.py:145-164` **Vulnerability Type**: Plaintext storage of credentials and sensitive notification data **Risk Level**: Medium ### Vulnerable Code ```python # bark_push/command_handler.py:261-278 if self._config_mgr.config.enable_update: try: record = new_history_record( push_id=push_id, device_keys=list(users.device_keys), user_aliases=list(users.aliases), title=str(payload.get("title") or ""), subtitle=str(payload.get("subtitle") or ""), body=str(payload.get("body") or payload.get("markdown") or ""), content_type=str(parsed.content_type.value), parameters=parsed_params, status=status, success_count=len(success_users), failed_count=len(failed_users), failed_users=failed_users, error_messages=errors, bark_response=last_resp, ) self._history.upsert(record) ``` ```python # bark_push/history_manager.py:30-50 def to_dict(self) -> dict[str, Any]: return { "id": self.id, "timestamp": self.timestamp, "datetime": self.datetime, "device_keys": self.device_keys, "user_aliases": self.user_aliases, "title": self.title, "subtitle": self.subtitle, "body": self.body, "content_type": self.content_type, "parameters": self.parameters, "status": self.status, "success_count": self.success_count, "failed_count": self.failed_count, "failed_users": self.failed_users, "error_messages": self.error_messages, "bark_response": self.bark_response or {}, "updated_at": self.updated_at, "update_count": self.update_count, } ``` ```python # bark_push/histor ...[truncated 3411 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not persist raw device keys. Store recipient aliases or a non-reversible keyed fingerprint when correlation is necessary. 2. Remove `ciphertext`, `copy`, authentication material, and other sensitive fields from `parameters` before creating a history record. 3. Store only a redacted and length-limited message preview by default. Make full-content history an explicit opt-in feature with a warning. 4. Create the state directory with owner-only permissions (`0700` on POSIX systems). 5. Create configuration and history files with owner read/write permissions only (`0600` on POSIX systems). 6. Validate and correct permissions on existing files before reading or updating them. 7. Use atomic writes through a securely created temporary file in the same protected directory, followed by `os.replace`. 8. Consider authenticated encryption for retained sensitive history if full content is operationally required. 9. Provide configurable retention periods and a command that securely clears history. 10. Add tests that verify redaction and restrictive file modes on supported platforms. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (29)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 90% confidence
• Finding: The supplied code only provides low-level network push functionality for Bark: building a request, posting JSON, resolving the endpoint path, and parsing responses/errors. It does not implement user management, content recognition/analysis, history persistence or tracking, or message update behavior. The declared description significantly overstates the implemented features, so the description does not accurately represent this code chunk.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The declared description presents a feature-rich Bark push assistant with user management, content analysis, historical record tracking, and message updating. However, the supplied code chunk contains only a test for basic HTTP POST push_json behavior of a Bark client against a mock local server. There is no evidence in this code of multi-user handling, content recognition, history persistence, or message update logic. The code’s actual purpose is narrowly focused on validating API request/response behavior, so the description materially overstates what this code chunk does.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 84% confidence
• Finding: The skill documents capabilities that imply network access plus local file read/write state management, but it does not declare any explicit tool scope such as permissions or allowed-tools. This weakens reviewability and can lead to over-broad execution in hosts that rely on metadata declarations for sandboxing or user consent.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill supports `--user all` to broadcast to every configured recipient, but the documentation does not clearly warn that this can notify all users at once. In operational environments, accidental mass notification can cause alert fatigue, information disclosure to unintended recipients, or disruption if sensitive content is broadcast broadly.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill documents deletion of pushed messages as a feature without warning that it is a destructive action. Users may remove notifications or records unintentionally, affecting auditability, user awareness, or operational response workflows.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The example shows a delete command directly, without any confirmation guidance, safeguards, or warning banner. Copy-pasteable destructive examples materially increase the chance of accidental deletion, especially in CLI-oriented workflows.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The method serializes an arbitrary payload and sends it via HTTP POST using `urlopen`, which may transmit user or system data to an external Bark endpoint. There is no confirmation prompt, logging, comment, or docstring in this file warning that data will be sent over the network.

Natural-Language Policy Violations

Medium

• Confidence: 97% confidence
• Finding: The file's user-visible messages and help text are consistently hard-coded in Chinese, such as `用户列表`, with no indication that the user can choose another language. This is a natural-language locale policy issue because the skill forces a specific language without opt-in or documented region-specific justification.

Description-Behavior Mismatch

Medium

• Confidence: 90% confidence
• Finding: The manifest describes a Bark push assistant with multi-user management, content recognition, history tracking, and message update support, but it does not mention deletion. This file explicitly accepts a delete operation and enables remote deletion of prior messages when update support is enabled, which is a materially different operation from sending or updating pushes.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: This code sends per-user payloads containing notification content and a device key to a remote Bark API via `push_json`, but there is no confirmation prompt, print/log disclosure, or explanatory comment/docstring in this file warning that user-provided content will be transmitted over the network. Because this is a code file and the operation is a network transmission of user/system data, it meets the missing-warning criterion.

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: Several exception messages shown to users are written only in Chinese, such as the validation and configuration errors in get_user_device_key. This forces a specific language/locale without offering a user choice or documenting a justified locale restriction.

Natural-Language Policy Violations

Medium

• Confidence: 94% confidence
• Finding: Multiple ConfigError messages in the config reading and parsing paths are emitted only in Chinese. Because these messages are part of the user-visible interface for failures, they impose a language policy without opt-in or documented justification.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: The code returns Chinese strings such as "图片", "链接", and "通知", and also formats markdown with Chinese labels. This forces a specific language in user-visible output with no opt-in or indication that the skill is intentionally Chinese-only, which matches the locale policy violation criteria.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The code persists full notification history to disk, including message title/body, recipient aliases, device keys, failure details, and Bark responses, without any minimization, encryption, access controls, or apparent user disclosure. In the context of a push-notification assistant, this creates a privacy and secret-exposure risk because local compromise, backup leakage, or accidental file sharing could reveal sensitive notification content and recipient identifiers.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: This manifest/config example contains user-facing natural-language descriptions exclusively in Chinese across the schema fields. Under the policy, forcing a specific language without user opt-in or clear justification is a natural-language locale violation.

Natural-Language Policy Violations

Medium

• Confidence: 90% confidence
• Finding: This JSON schema contains user-facing natural-language descriptions in Chinese, starting at L004 and continuing throughout the file, but provides no indication that the skill is region-specific or that another language is available. Under the policy, forcing a specific language without user opt-in or justification is a natural-language locale violation.

External Transmission

Medium

• Category: Data Exfiltration

Content

**请求示例**：
```
POST https://api.day.app/push
Content-Type: application/json; charset=utf-8

{"device_key":"xxx","title":"标题","body":"内容"}

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 83% confidence
• Finding: This markdown file documents sending push content to external Bark API endpoints and storing push history, and later proposes webhook callbacks to specified URLs. While the architecture explains how these features work, it does not clearly warn users that message content, device identifiers, and related metadata may be transmitted to third-party services or persisted locally.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 70% confidence
• Finding: npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The documentation explicitly shows a `--user all` broadcast action without warning that it sends to every configured recipient. In an agent skill context, examples strongly shape behavior, so this omission increases the chance of accidental mass notification, misuse, or social-engineering amplification across all users.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The documentation demonstrates `--delete <push_id>` as a normal operation but does not warn that deletion is destructive and may be irreversible. In automation or agent-driven usage, this can cause accidental loss of message history or operational evidence if a user or workflow invokes deletion without understanding the consequence.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The configuration example includes a per-user device key (`device_key_alice_abc123`) but does not identify it as a sensitive credential. Readers may store, share, or commit such keys insecurely, enabling unauthorized push delivery, user impersonation in notifications, or abuse of the Bark endpoint for spam and phishing.

Natural-Language Policy Violations

Low

• Confidence: 87% confidence
• Finding: The natural-language content of the skill is presented exclusively in Chinese, and there is no indication that the user can choose another language or that the skill is intentionally limited to a Chinese-speaking context. This can violate a language/locale policy when a skill implicitly forces one language without opt-in.

Missing User Warnings

Low

• Confidence: 82% confidence
• Finding: The loader automatically creates the state directory and writes a new config.json when the target path does not exist. This is a file-writing operation that changes the user's filesystem, but there is no confirmation prompt, print/log message, or in-file warning disclosing that behavior.

Natural-Language Policy Violations

Low

• Confidence: 96% confidence
• Finding: The user-facing argparse help strings are written entirely in Chinese, including option descriptions and group names. This imposes a specific language on users without any visible opt-in, fallback, or documentation that the skill is intentionally limited to a Chinese-speaking context.

Static analysis

No suspicious patterns detected.