embedded-engineer
PassAudited by VirusTotal on May 10, 2026.
Overview
Type: OpenClaw Skill Name: ah-embedded-engineer Version: 1.0.0 The skill bundle provides a comprehensive persona and detailed code examples for an embedded systems engineer. It is classified as suspicious due to the presence of several critical security vulnerabilities in the reference code (references/examples.md), most notably an insecure Over-The-Air (OTA) update mechanism that uses unencrypted HTTP (http://update.server.com) and the use of hardcoded credentials for WiFi and MQTT. While these appear to be intended as placeholders for educational purposes, they represent high-risk patterns that an AI agent might propagate into production environments.
Findings (0)
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 copied unchanged into a real project, users may normalize storing Wi-Fi passwords directly in firmware.
The example includes a hardcoded Wi-Fi credential-looking value. It appears illustrative and purpose-aligned for embedded networking code, but hardcoding real credentials would be unsafe.
const char* ssid = "IoT_Network"; const char* password = "SecurePassword123";
Replace placeholders with secure configuration handling, avoid committing real secrets, and document credential storage best practices.
A copied deployment could expose device commands or telemetry to parties that can reach the broker/topic namespace.
The example uses a public MQTT broker on the common plaintext port and subscribes to command/config topics. This is relevant to IoT examples, but real deployments need authentication, authorization, TLS, and topic isolation.
const char* mqtt_server = "broker.hivemq.com";
const int mqtt_port = 1883;
...
mqtt.subscribe("iot/devices/ESP32_SENSOR_001/commands");
mqtt.subscribe("iot/devices/ESP32_SENSOR_001/config");Use a private or authenticated broker, TLS, per-device credentials, restricted topics, and explicit command validation before deploying similar code.
If adapted directly, a device could install firmware from an unauthenticated or tampered update source.
The reference firmware example demonstrates downloading and applying OTA updates from a remote URL over HTTP. OTA updates are expected for IoT examples, but unsecured firmware update paths are high-impact if reused without verification.
http.begin("http://update.server.com/firmware/latest.json");
...
t_httpUpdate_return ret = httpUpdate.update(client, url);Require HTTPS, signed firmware, version/rollback checks, trusted update metadata, and user or fleet-policy approval for OTA updates.