Security audit
Security checks for vulnerabilities and agentic risk
The skill fits its smart-home purpose, but its documented network setup can expose the access token used to control devices and access cameras.
Use HTTPS or an encrypted tunnel for LAN access before supplying the bearer token. Protect the saved configuration and use reviewed, pinned client and container versions. Test connectivity with device listing or state reads; only test power control on equipment safe to interrupt. Anyone holding an optional snapshot link can view the image until it expires. All bundled files were inspected, but external runtime packages and server binaries were not audited.
Potential security issue detected. Manual review is recommended.
docker run --rm \
--network host \
-e TAPO_MCP_USERNAME="you@example.com" \
-e TAPO_MCP_PASSWORD="<YOUR_TAPO_PASSWORD>" \
-e TAPO_MCP_CAMERA_USERNAME="<YOUR_CAMERA_ACCOUNT_USERNAME>" \
Potential security issue detected. Manual review is recommended.
> **Note:** The image binds to `0.0.0.0:3000`, so `TAPO_MCP_API_KEY` is required — the server refuses to start on a non-loopback address without it (see Network exposure above). To reach the server by hostname or LAN IP rather than loopback, also set `TAPO_MCP_ALLOWED_HOSTS`. To get snapshot links, add `-e TAPO_MCP_PUBLIC_URL="https://tapo.example.com"`.
> **Note:** `--network host` is required so the container can reach Tapo devices on your local network via UDP broadcast for discovery. On macOS and Windows, `--network host` is not supported — you can use `-p 3000:3000` instead, but device discovery won't work as Docker Desktop runs containers inside a VM without LAN access.
### Kubernetes
Potential security issue detected. Manual review is recommended.
key: TAPO_MCP_DISCOVERY_TARGET
> **Note:** `hostNetwork: true` is required for UDP broadcast discovery, similar to `--network host` in Docker. Because clients reach the server by node IP or hostname rather than loopback, set `TAPO_MCP_ALLOWED_HOSTS` accordingly (see Network exposure above). To get snapshot links, add `TAPO_MCP_PUBLIC_URL` to the ConfigMap and the Deployment's `env`.
## Testing
Code deploys a privileged Kubernetes workload (privileged container, hostPath mount, or host namespaces). This grants root on the node and is a node/cluster takeover vector.
labels:
app: tapo-mcp
spec:
hostNetwork: true
containers:
- name: tapo-mcp
image: ghcr.io/mihai-dinculescu/tapo-mcp:latest
Code deploys a privileged Kubernetes workload (privileged container, hostPath mount, or host namespaces). This grants root on the node and is a node/cluster takeover vector.
key: TAPO_MCP_DISCOVERY_TARGET
> **Note:** `hostNetwork: true` is required for UDP broadcast discovery, similar to `--network host` in Docker. Because clients reach the server by node IP or hostname rather than loopback, set `TAPO_MCP_ALLOWED_HOSTS` accordingly (see Network exposure above). To get snapshot links, add `TAPO_MCP_PUBLIC_URL` to the ConfigMap and the Deployment's `env`.
## Testing
The general invocation uses an unpinned npm CLI, not an MCP server package as the finding suggests. If mcporter is not installed locally, npx can fetch a changing registry version, exposing the agent's environment and smart-home credentials to a compromised release.
This setup command can run a registry-resolved, unpinned mcporter release. A compromised release would receive the bearer token supplied to the configuration command and could access local configuration.
Even though listing schemas is read-only, npx may first fetch and execute an unpinned mcporter release. Compromise of that release could expose the agent's files and configured server credentials.
Device discovery uses an unpinned CLI that npx may obtain from the registry. A malicious release could access credentials and local resources regardless of the intended read-only discovery operation.
The device-check command does not constrain the mcporter version that npx may execute. Device identity validation does not protect against compromise of the client performing that validation.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
Get a device's current state. Checks the capability's parameters, then automatically runs check_device.
# Device info
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
Control a device by applying 1 to 12 set capabilities, in order. The count and every value are checked before the device is contacted; then it automatically runs check_device, and a capability the device does not support fails the call before any capability is applied. Brightness, Color, HueSaturation and ColorTemperature also turn the device on if it is off. When the device returns an error partway through, the error says how many capabilities were applied and which one failed.
# Turn on (plugs, lights, power strip child plugs, and S210 switches paired to a hub)
Reading device information can trigger execution of an unpinned registry release of mcporter. A compromised client could access the execution environment and configured smart-home credentials.
The hourly-energy example executes mcporter without a version constraint. Its read-only purpose does not prevent a compromised npm release from accessing credentials or other local resources.
The daily-energy query relies on an unpinned npm CLI that npx may download when absent locally. A malicious release would execute with the agent's process permissions.
The monthly-energy query can execute a changing registry-resolved mcporter version. This introduces supply-chain exposure despite the requested operation being read-only.
The energy-meter command uses unversioned npx package resolution. If a compromised release is fetched, it could access credentials and the agent's environment before performing the legitimate query.
This power-history query invokes mcporter without pinning its version. A registry compromise could therefore introduce executable code into an environment holding smart-home access credentials.
The hourly power query can cause npx to fetch and execute an unpinned mcporter release. The query's limited functionality does not restrict the permissions of the client process.
The trigger-log query uses an unpinned client package. A malicious release could access both configured credentials and potentially sensitive device activity records.
The temperature-history query relies on unpinned npx execution. If an untrusted release is resolved, it runs with the agent's permissions rather than being limited to reading sensor records.
The camera-detection query can execute a registry-resolved mcporter release without version pinning. A compromised release could access server credentials and sensitive camera activity metadata.
The power-on command uses an unpinned executable client. A compromised release could misuse configured access to physical devices or access local secrets instead of performing only the requested action.
The power-off command may fetch and execute an unpinned mcporter release. Smart-home control increases the consequences of client compromise because malicious code could issue unintended device commands.
The brightness example invokes an unpinned mcporter package. A compromised release would not be constrained to changing brightness and could access other resources available to the agent.