wechat-new-tool
WarnAudited by ClawScan on May 10, 2026.
Overview
This WeChat helper mostly matches its stated purpose, but it uses under-declared credentials, an unencrypted external bridge, and a direct send endpoint that does not enforce the promised confirmation flow.
Only run this if you fully trust the skill owner and the dashboard.synodeai.com backend. Before use, remove the bundled token, configure your own scoped credentials, require HTTPS, restrict the bridge to localhost or authenticated callers, and make sure every WeChat send is explicitly confirmed by you.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the bridge is reachable or an agent calls this endpoint out of sequence, WeChat messages, images, or files could be sent without the confirmation workflow actually being enforced by the server.
The final-send endpoint performs the WeChat send based on request body fields, and the artifacts do not show caller authentication, a pending-confirmation token, or an explicit localhost-only bind.
app.post('/wechat/confirm_send', async (req, res) => { const { target_id, type, content, fileName } = req.body; ... const result = await wx(config.path, 'POST', config.body); ... }); app.listen(3000);Require server-side confirmation state, authenticate local callers, validate target/type/content, bind to localhost unless remote access is explicitly needed, and require explicit user approval before every send.
The credential source, owner, and scope are unclear, and a bearer token tied to message-sending authority may let the bridge act through an account or service the user did not explicitly configure.
The skill ships an app id and token even though the registry metadata declares no required env vars or primary credential; the code uses this token as bearer authorization for WeChat bridge actions.
env: WECHAT_APPID: "wx_KcD1dMEn7KidBemwN2lVh" WECHAT_TOKEN: "e4cf78e3-afdf-4a45-8090-143ab4df83f2"
Remove hardcoded credentials, declare the required credential contract in metadata, require users to provide their own scoped token, and document exactly what account authority the token grants.
Message contents, file URLs, recipient IDs, and the bearer token could be exposed to the external provider or intercepted in transit.
Bearer credentials, recipient identifiers, and message payloads are sent to a hardcoded non-HTTPS external service that is not clearly disclosed in SKILL.md.
BASE_URL: "http://dashboard.synodeai.com/ai"; headers: { 'Authorization': `Bearer ${CONFIG.TOKEN}` }; text: { path: '/wechatTool/sendText', body: { contact: target_id, content } }Use HTTPS, disclose the external backend and data sent to it, allow users to configure the service endpoint, and avoid transmitting credentials or message data without clear consent.
A user who runs the bridge may install dependency versions that were not pinned or reviewed in the supplied artifacts.
Running the bridge depends on npm packages resolved by version ranges, while the registry provides no install spec; this is purpose-aligned for a Node bridge but leaves setup and dependency provenance less clear.
"dependencies": { "axios": "^1.6.0", "express": "^4.18.0" }, "scripts": { "start": "node wechat_bridge.js" }Provide an explicit install spec, pin dependencies with a lockfile, and document the expected runtime and startup process.