Summary
WLED exposes general device configuration through the /json/cfg endpoint without checking the settings PIN, allowing unauthenticated clients on the network to view network, hardware, and LED settings. Because the PIN-unlock state is stored in one global boolean rather than per session, a client that successfully submits the PIN may enable subsequent clients to perform sensitive configuration changes, including Wi-Fi reconfiguration, factory reset, or OTA updates.
Affected context
The issue occurs in WLED's HTTP configuration interface when the device is reachable by untrusted or semi-trusted clients on the network. The read endpoint does not apply the same settings-PIN control used by the edit path, while the authorization state for configuration writes is shared globally across clients rather than isolated to the session that authenticated.
Exploit preconditions
- Attack surface: WLED's network-accessible HTTP API
- Required access: Network connectivity to the WLED device; configuration writes additionally depend on the global PIN state having been unlocked
- Trigger point: Requests to
/json/cfgor configuration write operations through/json - Why exploitation is possible: The read endpoint omits authorization, and a successful PIN submission changes a process-wide boolean that can authorize other clients
Why this happens
The vulnerability is caused by missing authorization enforcement and shared authentication state. The configuration endpoint returns sensitive data without verifying the settings PIN, while a single global correctPIN flag represents authorization for every client instead of maintaining identity- or session-bound state. This behavior maps to CWE-862: Missing Authorization, because access checks are absent or applied in a way that does not constrain the requesting client.
Potential impact
- Unauthenticated clients may disclose network, hardware, and LED configuration details
- Attackers may modify device or Wi-Fi settings after the shared PIN state is unlocked
- An attacker may trigger a factory reset or disrupt device availability
- OTA update functionality could be abused to install unauthorized firmware
- Compromised devices could provide a foothold for broader network reconnaissance or disruption
General mitigation guidance
Mitigation generally focuses on enforcing authorization consistently and binding authorization decisions to the requesting session.
Common defensive patterns include:
- Require authenticated, session-scoped authorization for every sensitive configuration read and write
- Avoid global authentication flags; associate authorization state with a securely managed session or request identity
- Apply deny-by-default access control to configuration, reset, Wi-Fi, and OTA operations
- Minimize configuration data returned to unauthenticated clients and avoid exposing secrets or network details
- Use secure session lifecycle controls, expiration, logout, and protection against session fixation
- Restrict device management interfaces to trusted network segments and least-privileged administrative roles
- Add explicit authorization checks before state-changing operations, including firmware updates and factory resets
How teams detect issues like this
Organizations can detect related access-control weaknesses through:
- Static analysis searches for sensitive handlers that return configuration data without an authorization guard
- Code review checks for global authentication or authorization booleans shared across clients
- Tests that access management endpoints before authentication, after another client's authentication, and after session expiration
- API policy checks requiring authentication for configuration, reset, network, and OTA operations
- Dynamic testing that compares authorization behavior across separate client sessions
- Automated security review tools configured to flag missing authorization checks and shared security state
