Arduino-MCP

The primary Node.js server uses input validation (Zod) and path sanitization (`resolveSafePath`) which mitigate common server-side risks. However, critical vulnerabilities exist within the associated `ArduinoMCP` ESP32 firmware library and its usage examples: 1. **ESP32 Firmware Path Traversal**: The `ArduinoMCP` library's SPIFFS API endpoints (`/api/spiffs/list`, `/api/spiffs/read`, `/api/spiffs/write`, `/api/spiffs/delete`) directly use user-provided `path` arguments in `SPIFFS.open`, `SPIFFS.remove`, and `file.print` operations without apparent sanitization against path traversal (e.g., `../`). This creates a critical vulnerability on the ESP32 device itself, allowing an attacker to read, write, or delete arbitrary files on the SPIFFS partition. 2. **Hardcoded Credentials in Example Sketch**: The `mercury_net_diag/settingManager.cpp` file, part of an example sketch, contains multiple hardcoded WiFi SSIDs and passwords (`mainSSID`, `mainPass`, `altSSID`, `altPass`, `devSSID`, `devPass`). Deploying this sketch or similar code with sensitive information hardcoded poses a significant security risk. 3. **Default Lax CORS Policy**: The Console Server's API defaults `MCP_CORS_ORIGIN` to `*`, making it accessible from any origin. This is a security concern if the console server is exposed to an untrusted network. 4. **Unrobust JSON Parsing (ESP32 Sketch)**: The `settingManager.cpp` uses a simplistic string-based JSON parser (`fromJson`) which is prone to errors with malformed JSON and could lead to unexpected behavior or data corruption on the device, though not directly to code execution.