ClawHub
Back to skill

Security audit

Bark Notifications

Security checks for vulnerabilities and agentic risk

Overview

This skill does what it says: it sends Bark push notifications, but users should understand that notification text goes to Bark's server and the device key is stored locally in plaintext.

Install only if you are comfortable with an agent sending notification titles, bodies, URLs, and your Bark key to the configured Bark server. Prefer POST over GET, avoid sending secrets, restrict ~/.bark/key permissions if you store it, delete or rotate the key when no longer needed, and consider a self-hosted Bark server for more control.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Rogue AgentSelf-Modification, Session Persistence
  • 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
Findings (13)

Vague Triggers

Medium
Confidence
88% confidence
Finding
The skill advertises broad trigger phrases like "notify me," which are common conversational terms and can cause unintended invocation of a capability that sends data to an external service. Because the action can transmit user-supplied content off-platform and use a stored device key, overly permissive activation increases the chance of accidental data disclosure or unexpected notification sends.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The skill instructs storage of the Bark key in `~/.bark/key` as plaintext without clearly warning the user about the security implications. A plaintext API/device key on disk can be recovered by other local processes, users, backups, or logs and then abused to send notifications to the user's device.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The skill does not clearly warn that notification title/body and related parameters are sent to an external Bark server (`api.day.app` by default). Users may unknowingly disclose sensitive content to a third party, especially if they assume the notification action is local or device-direct.

External Transmission

Medium
Category
Data Exfiltration
Content
```bash
KEY=$(cat ~/.bark/key)
curl -s -X POST "https://api.day.app/$KEY" \
  -d "title=Notification Title" \
  --data-urlencode "body=First line
Second line
Confidence
86% confidence
Finding
Although the POST example is safer than GET for message content, it still sends data to an external service and includes the secret key in the URL path. If command output, telemetry, or process arguments are captured, the key may still be exposed.

External Transmission

Medium
Category
Data Exfiltration
Content
1. Read key from `~/.bark/key`
2. If key file doesn't exist or is empty, ask user for their Bark key and write it to `~/.bark/key`
3. Build the request with the key and user-provided parameters
4. Execute via exec/curl
5. Confirm notification received

## Example
Confidence
90% confidence
Finding
The operational instructions explicitly tell the agent to execute `curl` to transmit user-provided parameters to Bark. While this is core functionality, it creates a real data-exfiltration path to a third-party service and should be treated as a true security concern in contexts involving private information.

External Transmission

Medium
Category
Data Exfiltration
Content
## API Overview

- **Base URL**: `https://api.day.app/`
- **Method**: GET or POST
- **Required**: Bark key (from `~/.bark/key`), body text
- **Optional**: title, subtitle, URL, icon, sound, group, level, etc.
Confidence
91% confidence
Finding
The API overview establishes a default external endpoint, meaning all notification data is intended to leave the environment and be processed by a remote service. This is not malicious by itself, but it is a genuine security-relevant behavior that can expose user content if insufficiently disclosed.

External Transmission

Medium
Category
Data Exfiltration
Content
Send a simple notification:

```
GET https://api.day.app/{key}/{body}
```

Send with title:
Confidence
95% confidence
Finding
The GET example places the Bark key and body directly in the URL path, which can be captured by browser history, proxy logs, shell history, or monitoring systems. This increases exposure of both credentials and message contents compared with safer request patterns.

External Transmission

Medium
Category
Data Exfiltration
Content
Send with title:

```
GET https://api.day.app/{key}/{title}/{body}
```

Send with title and subtitle:
Confidence
96% confidence
Finding
This GET example puts the key, title, and body into the URL path, magnifying leakage risk through logs and intermediaries. Because notification content may include sensitive reminders or private information, URL-based transport is unnecessarily risky.

External Transmission

Medium
Category
Data Exfiltration
Content
Send with title and subtitle:

```
GET https://api.day.app/{key}/{title}/{subtitle}/{body}
```

## POST Request (Recommended for multi-line / special chars)
Confidence
96% confidence
Finding
This variant further exposes key, title, subtitle, and body in the request URL, creating a broad surface for credential and content leakage via logs and telemetry. The skill context makes this more dangerous because the examples normalize an insecure calling pattern for routine use.

External Transmission

Medium
Category
Data Exfiltration
Content
```bash
KEY=$(cat ~/.bark/key)
curl -s -X POST "https://api.day.app/$KEY" \
  -d "title=Notification Title" \
  --data-urlencode "body=First line
Second line
Confidence
86% confidence
Finding
Although the POST example is safer than GET for message content, it still sends data to an external service and includes the secret key in the URL path. If command output, telemetry, or process arguments are captured, the key may still be exposed.

External Transmission

Medium
Category
Data Exfiltration
Content
Body: Team sync at 3pm tomorrow

```
curl -s -X POST "https://api.day.app/yourkey" \
  -d "title=Meeting Reminder" \
  --data-urlencode "body=Team sync at 3pm tomorrow"
```
Confidence
90% confidence
Finding
The example demonstrates sending notification content to a remote Bark endpoint with a device key, reinforcing external transmission as standard behavior. This is a true security concern because it can carry user-generated text off-platform without emphasizing privacy implications.

Session Persistence

Medium
Category
Rogue Agent
Content
Key file: `~/.bark/key` (plain text, just the key string).

If the file doesn't exist or is empty, ask the user for their Bark key and write it to `~/.bark/key`.

## API Overview
Confidence
97% confidence
Finding
The skill directs persistent storage of the Bark key in `~/.bark/key`, creating long-lived credential material on disk beyond the current session. Persistent secrets increase the blast radius of local compromise, accidental sharing, backups, and forensic recovery.

Session Persistence

Medium
Category
Rogue Agent
Content
## How to Use

1. Read key from `~/.bark/key`
2. If key file doesn't exist or is empty, ask user for their Bark key and write it to `~/.bark/key`
3. Build the request with the key and user-provided parameters
4. Execute via exec/curl
5. Confirm notification received
Confidence
97% confidence
Finding
The workflow explicitly instructs the agent to write the Bark key to persistent local storage for future reuse. This creates a standing secret that may be reused without fresh consent and can be abused by other processes or users with access to the environment.

Static analysis

No suspicious patterns detected.