T09 · Insecure Skill Coding Practices
- Location
scripts/wifi_setup.py:60- Finding
Persistent WebREPL Provisioning Exposes Plaintext Credentials and Bypasses Dangerous-Operation Confirmation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This MicroPython hardware skill fits its stated purpose, but it needs review because it can persistently enable wireless device access, handle credentials unsafely, broaden serial-port access, and flash unverified firmware.
Install only if you are comfortable letting the agent control connected microcontroller hardware. Prefer USB over WebREPL, avoid the default WebREPL password, do not use chmod 666 for serial access, review any boot.py/main.py changes before running WiFi setup, and verify firmware sources before flashing because flashing can erase or permanently change the device.
scripts/wifi_setup.py:60Persistent WebREPL Provisioning Exposes Plaintext Credentials and Bypasses Dangerous-Operation Confirmation
scripts/webrepl_exec.py:37WebREPL Transmits Authentication Credentials and Executable Code Without Encryption or Endpoint Authentication
scripts/firmware_flash.py:147Firmware Flashing Trusts Unverified Downloads and a Poisonable Shared Temporary Cache
scripts/device_probe.py:210Recommended Serial-Port Permission Fix Grants Device Access to Every Local User
references/connections.md:52Unpinned Dependency Installation and Arbitrary Remote Package Source Guidance
Referenced artifact was not completely inspected
- "SKILL.md"
Referenced artifact was not completely inspected
- "scripts/firmware_flash.py"
Referenced artifact was not completely inspected
- "scripts/firmware_flash.py"
Referenced artifact was not completely inspected
- "scripts/firmware_flash.py"
Referenced artifact was not completely inspected
- "scripts/firmware_flash.py"
The suggested parameter 666 is itself the problem: it applies overly permissive access to the serial device and turns a troubleshooting step into a broad host-side security bypass. In a tool-using agent setting, hardcoded unsafe parameters are especially dangerous because they can be repeated automatically and without nuanced operator review.
- `status: "ok"` → Device has MicroPython, proceed to step 2
- `status: "no_firmware"` → ESP chip detected but no MicroPython. Ask user to confirm, then flash: `python3 {SKILL_DIR}/scripts/firmware_flash.py --port PORT --yes`
- `status: "no_device"` → No device connected. Guide user to connect hardware.
- `status: "permission_denied"` → Serial port not accessible. On Linux: `sudo chmod 666 /dev/ttyACM0`. On Windows: check Device Manager for driver issues.
2. **Connect** — Default: USB via mpremote. Optional: WiFi via WebREPL (user must request)
3. **Execute** — Generate MicroPython code and push to device
4. **Parse** — Scan stdout for tagged lines (RESULT:/ERROR:/STATUS:/LOG:)
The tool guidance embeds a dangerous parameter choice, 'chmod 666', that weakens host security controls as part of normal troubleshooting. Even though the script does not execute the command itself, the skill can induce insecure operator behavior, which is especially risky for an AI-assisted hardware-management workflow.
if "not readable" in combined.lower() or "permission" in combined.lower():
if sys.platform == "win32":
return None, f"Permission denied on {port}. Check Device Manager for driver issues."
return None, f"Permission denied on {port}. Run: sudo chmod 666 {port}"
# Check for connection error
if rc != 0 and ("failed" in combined.lower() or "error" in combined.lower()):
This second instance repeats the same unsafe tool-parameter recommendation in structured output intended to guide the user. Because users may copy-paste remediation text verbatim, this increases the likelihood of insecure host configuration.
"fix": (
"Check Device Manager — the COM port driver may need reinstalling"
if sys.platform == "win32"
else f"Run: sudo chmod 666 {port}"
),
}
print(json.dumps(result, indent=2))
This is a true parameter-abuse/safety issue because the tool encourages a dangerously overbroad permission change on a user-supplied device path. Even though it is only printed as advice, in practice users often copy-paste such remediation, and on a firmware-flashing tool that can erase and rewrite hardware, the resulting access expansion materially increases the attack surface.
if "not readable" in combined.lower() or "permission" in combined.lower():
if sys.platform == "win32":
return None, f"Permission denied on {port}. Check Device Manager for driver issues."
return None, f"Permission denied on {port}. Run: sudo chmod 666 {port}"
chip_match = re.search(r"Chip is (ESP\S+)", combined, re.IGNORECASE)
if chip_match:
The skill describes capabilities that include shell execution, file reads/writes, and network access, but it does not declare any explicit tool scope or permission boundary. In an agent environment, that increases the chance the skill is invoked with broader-than-necessary privileges, enabling unintended host actions beyond the microcontroller workflow.
The trigger description is extremely broad and includes many generic hardware and networking terms, making accidental activation likely. Over-broad activation can cause the agent to enter a workflow that performs device probing, shell commands, network activity, or code generation when the user's intent was only conversational or informational.
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "scripts/firmware_flash.py"
- "scripts/wifi_setup.py"
- "scripts/webrepl_exec.py"
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "scripts/firmware_flash.py"
- "scripts/wifi_setup.py"
- "scripts/webrepl_exec.py"
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "scripts/wifi_setup.py"
- "scripts/webrepl_exec.py"
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "scripts/wifi_setup.py"
- "scripts/webrepl_exec.py"
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "scripts/webrepl_exec.py"
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
- "references/connections.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "scripts/webrepl_exec.py"
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
- "references/connections.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
- "references/connections.md"
- "references/esp32.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "skills/sensor/SKILL.md"
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
- "references/connections.md"
- "references/esp32.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
- "references/connections.md"
- "references/esp32.md"
- "references/safety.md"
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
- "skills/actuator/SKILL.md"
- "skills/network/SKILL.md"
- "skills/diagnostic/SKILL.md"
- "skills/algorithm/SKILL.md"
- "references/connections.md"
- "references/esp32.md"
- "references/safety.md"
Using chmod 666 on a serial device is an over-broad permission change that can expose the port to unintended local access. Because this skill already has shell-oriented behavior and hardware control scope, recommending this command materially increases the risk of unsafe host modification during normal operation.
- `status: "ok"` → Device has MicroPython, proceed to step 2
- `status: "no_firmware"` → ESP chip detected but no MicroPython. Ask user to confirm, then flash: `python3 {SKILL_DIR}/scripts/firmware_flash.py --port PORT --yes`
- `status: "no_device"` → No device connected. Guide user to connect hardware.
- `status: "permission_denied"` → Serial port not accessible. On Linux: `sudo chmod 666 /dev/ttyACM0`. On Windows: check Device Manager for driver issues.
2. **Connect** — Default: USB via mpremote. Optional: WiFi via WebREPL (user must request)
3. **Execute** — Generate MicroPython code and push to device
4. **Parse** — Scan stdout for tagged lines (RESULT:/ERROR:/STATUS:/LOG:)
Using chmod 666 on a serial device is an over-broad permission change that can expose the port to unintended local access. Because this skill already has shell-oriented behavior and hardware control scope, recommending this command materially increases the risk of unsafe host modification during normal operation.
- `status: "ok"` → Device has MicroPython, proceed to step 2
- `status: "no_firmware"` → ESP chip detected but no MicroPython. Ask user to confirm, then flash: `python3 {SKILL_DIR}/scripts/firmware_flash.py --port PORT --yes`
- `status: "no_device"` → No device connected. Guide user to connect hardware.
- `status: "permission_denied"` → Serial port not accessible. On Linux: `sudo chmod 666 /dev/ttyACM0`. On Windows: check Device Manager for driver issues.
2. **Connect** — Default: USB via mpremote. Optional: WiFi via WebREPL (user must request)
3. **Execute** — Generate MicroPython code and push to device
4. **Parse** — Scan stdout for tagged lines (RESULT:/ERROR:/STATUS:/LOG:)
All user-facing prompt examples in this file are presented in Chinese, which may imply a fixed language expectation without offering user choice. Under the language/locale policy, forcing a specific language without opt-in can be a natural-language policy violation unless clearly justified as region-specific.
The documentation includes commands that delete or overwrite files on the microcontroller without clearly warning that these actions can permanently alter device behavior or erase user code. In a hardware-programming skill, users may copy-paste commands directly, so omission of a data-loss warning increases the chance of accidental device disruption.
No suspicious patterns detected.