Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Skill Vexa
v0.1.1Send bots to Zoom, Google Meet, and Microsoft Teams meetings. Get live transcripts, recordings, and reports. Self-hosted or cloud — no external API needed.
⭐ 0· 262·1 current·1 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
high confidencePurpose & Capability
The skill description claims "no external API needed", but all runtime scripts call a remote Vexa service (https://api.cloud.vexa.ai) and require VEXA_API_KEY. Registry metadata lists no required env vars, but the SKILL.md and scripts require VEXA_API_KEY and support endpoint switching. The bundled secrets files include multiple API keys. The need to read/write OpenClaw hooks (openclaw.json) and session files is plausible for webhook integration, but the external API dependency and embedded keys are inconsistent with the advertised purpose.
Instruction Scope
SKILL.md and references/onboarding-flow.md instruct the assistant to ask the user for an API key and immediately write it to skills/vexa/secrets/vexa.env (mode 600) without additional confirmation, to proactively set up webhooks (including editing openclaw.json), and to read local session/config files. Scripts read files in the user's home (~/.openclaw/*) and may enumerate sessions/configs. These instructions extend beyond simple 'help start a bot' behaviour and grant broad file access and the ability to modify workspace config; asking users to paste secrets directly into chat is especially problematic.
Install Mechanism
No separate install spec (instruction-only), but the skill ships with Node scripts that will be run. There are no external downloads, which reduces supply-chain risk, but the package itself contains embedded secret files (secrets/*.env and secrets/*.json) that include API keys. Bundling live credentials inside the skill package is a security/operational concern.
Credentials
Registry metadata lists no required env vars/credentials, yet runtime requires VEXA_API_KEY and optionally VEXA_BASE_URL; the skill also ships with multiple pre-populated secrets files containing API keys. Requiring a single API key for the Vexa service would be reasonable, but embedding keys in the package and instructing automatic persistence of pasted keys is disproportionate and risky. Scripts also read home-dir config and session files (openclaw.json, sessions.json), which increases scope.
Persistence & Privilege
The skill writes state and secret files into skills/vexa/secrets/ (persistKey), and onboarding instructions tell the assistant to create/write those files on behalf of the user. The skill also expects to add hook mappings to openclaw.json (workspace/system config) to enable automatic webhooks. While the skill is not force-included (always:false), the pattern of automatically persisting API keys and altering workspace hook configuration increases its privilege and persistence.
Scan Findings in Context
[embedded_credentials_files] unexpected: The repository includes secrets/vexa.env, secrets/vexa-prod.env and secrets/vexa-local.env with apparent API key values. Shipping embedded API keys in the skill package is not necessary for a third-party skill and is a high-risk practice (exposure and reuse).
[external_api_calls] expected: Scripts make REST and WebSocket calls to the Vexa API (api.cloud.vexa.ai) and provide endpoints switching. This is expected for a meeting-bot integrator, but contradicts the SKILL.md claim of 'no external API needed'.
[writes_workspace_and_system_configs] expected: The onboarding flow and scripts read and intend to modify openclaw.json (hooks mappings) and write persistent state under skills/vexa/secrets and ~/.openclaw. Proactively updating workspace hook configuration is plausible for webhook integration, but it requires user consent and careful handling.
[reads_user_home_session_files] unexpected: Scripts read session files (e.g. ~/.openclaw/agents/main/sessions/sessions.json) to detect received webhooks. Accessing session files may be useful for validating webhooks, but it reads user-local state beyond a minimal API integration and should be surfaced to the user.
What to consider before installing
This skill is not internally consistent and has risky secret-handling practices. Key points before installing or using it:
- Do not paste any API keys into chat. The onboarding instructions explicitly tell the assistant to write pasted keys to disk automatically; instead, create the secret file yourself (skills/vexa/secrets/vexa.env) with the VEXA_API_KEY and set file mode 600, or set VEXA_API_KEY in your environment.
- Treat the bundled secrets files as compromised: the package already contains API keys. If you or your org used those keys, rotate/revoke them immediately and do not trust them.
- The skill will read and may modify workspace/system files (openclaw.json, ~/.openclaw/*). Only allow that if you understand and consent to the exact changes (hooks.mappings, transformsDir). Prefer to make those configuration changes yourself rather than granting the assistant write permission.
- If you want to test, run the scripts locally in an isolated environment (container or disposable VM) and review the code paths that write files (onboard.mjs, vexa.mjs, ingest.mjs, audit.mjs, vexa-transform.mjs). Confirm network endpoints (VEXA_BASE_URL) and ensure keys are stored securely.
- If you don't trust the skill source (homepage unknown, owner unknown), avoid installing it in production. Ask the publisher to remove embedded secrets and to document why the package contains keys and the 'no external API needed' claim.
Additional steps that would increase confidence: a) remove bundled credentials from the package, b) update registry metadata to declare VEXA_API_KEY as a required secret, c) change onboarding to ask the user to create the secret file themselves (or supply a secure upload), and d) provide a clear, auditable mechanism for any workspace config changes requiring explicit user approval.Like a lobster shell, security has layers — review code before you run it.
latestvk973y1e8zr0d5rgd1ag73bhzyx82a9y4
License
MIT-0
Free to use, modify, and redistribute. No attribution required.