Security: Firmware uploaded to device without any signature or checksum verification

[frenckatron]

Problem

upgrade() downloads a binary from GitHub and immediately POSTs it as a firmware image to the device:

async with self.session.get(download_url, raise_for_status=True) as download:
    form = aiohttp.FormData()
    form.add_field("file", await download.read(), filename=update_file)
    await self.session.post(url, data=form)

There is no signature check, no SHA256 verification against the GitHub release asset digest, and no validation of the binary's structure. The integrity of the transferred firmware rests entirely on (a) TLS to github.com and (b) the path-construction logic — both of which are undermined by the URL-injection finding above and by the user-supplied repo argument (line 639). The POST to the device is plain HTTP (scheme="http"), so the firmware is also visible/modifiable on the LAN segment.

Why This Matters

Combined with the URL-injection issue or with a user being convinced to pass repo="attacker/wled-fork", an attacker can install arbitrary firmware on the ESP device. Without independent integrity checks, callers of this library have no way to detect that they uploaded the wrong binary.

Suggested Fix

Before POSTing, fetch the GitHub release metadata for the requested tag (https://api.github.com/repos/{repo}/releases/tags/v{version}), look up the asset by name, and verify the downloaded bytes against the asset's published digest/sha256 (now exposed by the GitHub releases API) or against a known-good SHA distributed out-of-band. Reject the upload if the digest does not match. At minimum, log/expose the computed SHA256 so callers can pin it.

Details

Severity	🟠 High
Category	crypto
Location	src/wled/wled.py:718-730
Effort	🛠️ Moderate effort

---

🤖 Created by Kōan from audit session

[netmindz]

Checking the sha256 does nothing to address any concern around the user being coerced into supplying a random repo to install from.

The options to enter an arbitrary value should never have been added as a feature. It should only be from the repo that the current firmware is from, or from the official WLED repo if the device doesn't present a repo

[mik-laj]

Thanks for the feedback - you raise a valid point, but I think the SHA256 check and the repo parameter serve different purposes.

On SHA256 verification: The primary goal of this PR is protecting against corrupted transfers — ensuring the binary received from GitHub is exactly what was published for that release. CDN-level tampering or MITM are relatively low-risk, but a partial download, network glitch, or storage error during transfer is a realistic concern when flashing embedded firmware. A bad flash can brick the device, so verifying the digest before POSTing is a pragmatic safety net.

On the repo parameter: In practice, most callers (including Home Assistant) will always use the value reported by the device or the default wled/WLED. That said, there are legitimate manual use cases — for example, a user who wants to migrate from official WLED to a custom fork. In those cases the action is always human-initiated and explicit, done through the CLI. As noted in #2073, upgrade() is a Python API — its arguments are controlled by the calling code, not end users, so restricting repo at the library level wouldn't meaningfully improve security.

To be honest, I think the original security severity was overstated — this is probably Low in practice. But the finding was still valuable: it made me think about what happens when a corrupted or incomplete file gets flashed to a device. The SHA256 check is ultimately a UX improvement — giving users confidence that we won't brick their devices due to a bad download, regardless of the firmware source.