Security audit
Security checks for vulnerabilities and agentic risk
SignalLink is a disclosed Telegram webhook router, but one message-forwarding endpoint is unauthenticated and the default deployment can expose the relay broadly.
Install only if you are prepared to harden it before exposing it beyond localhost: require a non-empty WEBHOOK_SECRET on every POST endpoint including /webhook/raw, bind locally or place it behind a protected reverse proxy, avoid sending secrets or private incident data in webhook payloads, and restrict access to logs because full webhook bodies are logged.
App/webhook.py:64Authentication Bypass on the Raw Webhook Endpoint
App/webhook.py:15Public Fail-Open Webhook Authentication Configuration
App/webhook.py:44Sensitive Webhook Payloads Are Logged in Full
App/formatter.py:82Telegram Markdown Injection Through Unescaped Webhook Fields
App/webhook.py:22Unbounded Webhook Processing and Outbound Message Forwarding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cp .env.example .env
Edit .env and fill in your values:
The declared purpose sounds like a narrow TradingView-to-Telegram relay, but the documentation describes a broader general-purpose webhook forwarder, including arbitrary custom payloads and a raw endpoint. This mismatch can mislead reviewers and users about the trust boundary, making it easier to deploy an internet-exposed message relay that can be abused for spam, alert injection, or exfiltration through Telegram.
The skill instructs users to place the Telegram bot token into a .env file, which is common practice, but the documentation does not warn about protecting that file from source control, sharing, or accidental exposure. Because the token grants control of the bot, leakage can let an attacker send messages, abuse the bot, or hijack notifications.
cp .env.example .env
Edit .env:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
ports:
- "8000:8000"
env_file:
- .env
restart: unless-stopped
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
Package name closely resembles a popular package, suggesting possible typosquatting. Attackers publish malicious packages with similar names to trick developers into installing them.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
logger = logging.getLogger(__name__)
TELEGRAM_API = "https://api.telegram.org/bot{token}/{method}"
async def send_message(text: str, chat_id: str = None) -> dict:
The function sends data to the Telegram API, including a photo URL, caption, and chat identifier, but unlike send_message it has no docstring warning, comment, or logging indicating that external transmission occurs. For code files, outbound network calls that transmit user or system data should have some visible disclosure unless clearly documented as expected behavior.
The manifest describes a narrowly scoped bridge for TradingView alerts to Telegram. However, the main endpoint explicitly accepts payloads from "TradingView or any custom source," and the separate raw endpoint is documented for non-trading alerts such as uptime monitors and CI/CD, expanding the skill beyond the stated trading-alert purpose.
The /webhook/raw route always formats and forwards arbitrary JSON as key-value text, and its docstring explicitly targets non-trading alerts. This is broader than "Forward trading alerts and webhook events from TradingView to Telegram instantly" and represents a meaningful behavior mismatch at the skill level.
The /webhook/raw endpoint accepts arbitrary JSON and forwards it to Telegram without any authentication, unlike the main /webhook route which verifies a secret. This allows any external party who can reach the service to send unsolicited messages to the configured Telegram destination, enabling spam, alert forgery, phishing-style content delivery, and operational disruption.
The README explicitly promotes forwarding arbitrary webhook payloads to Telegram but does not clearly warn users that submitted data will be transmitted to a third-party messaging platform. In this context, operators may send monitoring, CI/CD, or trading data that could contain sensitive information, creating a confidentiality risk through unreviewed external sharing.
The skill requires environment variables and clearly exposes network-facing behavior, but it does not declare an explicit tool scope such as permissions or allowed-tools. That weakens least-privilege controls and can cause an agent or operator to invoke the skill without realizing it needs secret access and network transmission capabilities.
The instructions tell users to provide a Telegram bot token and chat ID, but do not include an explicit warning that the bot token is a sensitive secret that must not be pasted into chats, logs, or shared prompts. In an agent-assisted workflow, this increases the chance of credential disclosure to unintended parties or storage in unsafe locations.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Send a test webhook with curl:
curl -X POST http://localhost:8000/webhook \
-H "Content-Type: application/json" \
-H "X-Webhook-Secret: your_secret_here" \
-d '{
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Send a test webhook with curl:
curl -X POST http://localhost:8000/webhook \
-H "Content-Type: application/json" \
-H "X-Webhook-Secret: your_secret_here" \
-d '{
The dependency is pinned to a version reported as vulnerable to unsafe symlink handling in set_key, which can enable arbitrary file overwrite in workflows that modify .env files. In a webhook-forwarding service that may run with filesystem access and secrets in environment files, this increases risk if any code path or operator tooling uses python-dotenv write functionality on attacker-influenced paths.
No suspicious patterns detected.