CI/CD supply chain risk: GitHub Actions not SHA-pinned, nightly-release follows @main

[elgreco86]

Summary

Several GitHub Actions in WLED's CI/CD workflows use mutable references (tags and branches) instead of immutable SHA pins. The highest-risk case is andelf/nightly-release@main which follows the main branch of a 22-star repository and runs nightly with write access to the WLED repo.

Findings

Critical: andelf/nightly-release@main

In .github/workflows/nightly.yml (line 34):

- name: Update Nightly Release
  uses: andelf/nightly-release@main
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

This action is pinned to the main branch (not a tag, not a SHA) of a repository with 22 stars. It runs automatically every night at 2 AM UTC via cron, with GITHUB_TOKEN (repo write access) and access to PAT_PUBLIC.

If andelf/nightly-release is compromised (account takeover, malicious PR merged, etc.), the attacker's code runs inside WLED's CI with the ability to:

• Replace firmware binaries in nightly releases with malicious builds
• Exfiltrate GITHUB_TOKEN and PAT_PUBLIC
• Push commits or modify tags on the WLED repo

Broader pattern

No GitHub Actions across any workflow are SHA-pinned. All use mutable tags:

Action	Reference	Risk
andelf/nightly-release	@main (branch)	High — 22-star repo, branch pin
softprops/action-gh-release	@v1 (major tag)	Medium
janheinrichmerker/action-github-changelog-generator	@v2.4	Medium
actions-cool/check-user-permission	@v2	Medium
peter-evans/repository-dispatch	@v3	Low-Medium
actions/checkout, setup-python, setup-node, etc.	@v4/@v5	Low (official, but still mutable)

Suggested fix

Pin all actions to their commit SHA with a tag comment for readability:

# Before
uses: andelf/nightly-release@main

# After
uses: andelf/nightly-release@<commit-sha>  # main

Consider adding Dependabot or Renovate to automate SHA updates when upstream actions release new versions.

Alternatively, replace andelf/nightly-release with a more widely-used action like ncipollo/release-action (pinned to SHA), or inline the release logic with gh release CLI commands directly.

Context

Found during a third-party code audit of the WLED repository. This is a CI/CD configuration issue, not a firmware vulnerability, so public disclosure is appropriate.

[elgreco86]

Additional findings from the same audit

While reviewing the CI/CD pipeline, we also audited the firmware source. Some additional findings that may be worth addressing:

Critical

• Wildcard CORS on all responses (wled_server.cpp:339-341) — Access-Control-Allow-Origin: * with Allow-Methods: * and Allow-Headers: * on every response. Combined with no CSRF protection, any website can control a WLED device from a user's browser via DNS rebinding.

High

• Unauthenticated /reset endpoint (wled_server.cpp:389-392) — GET /reset reboots the device with zero authentication. Trivial denial of service for any client on the network.
• Bootloader OTA endpoint (ota_update.cpp) — /updatebootloader writes directly to flash at the bootloader offset via esp_flash_erase_region + esp_flash_write. No cryptographic signature verification. A malicious firmware update through this endpoint could install a persistent backdoor that survives normal OTA updates.
• skipValidation OTA bypass (ota_update.cpp, beginOTA()) — The OTA metadata validation can be completely bypassed by passing skipValidation=1 as a POST parameter, allowing arbitrary unsigned firmware to be flashed.
• ArduinoOTA runs without password (wled.cpp:534-553) — When AOTA is enabled, ArduinoOTA.setPassword() is never called. The ArduinoOTA protocol itself has no authentication.

Medium

• Global session-less PIN state (wled.h:586) — Once any client enters the correct PIN, the global correctPIN boolean unlocks settings for ALL clients simultaneously until timeout. No per-client sessions.
• Improv passLen not bounds-checked (improv.cpp:268) — passLen is read from RPC data as an unsigned byte (0-255) but clientPass buffer is only 64 bytes. memcpy(multiWiFi[0].clientPass, rpcData+3+ssidLen, passLen) can overflow.

These were found through source code review, not fuzzing or exploitation. Happy to provide more detail on any finding.

[netmindz]

Please don't mix unrelated items in the same issue as it makes it really had to track. Most of the second comment is not a "finding" but just reality of certain design choices. For example, the WLED community has 3k forks, this isn't commercial software so preventing anything other than officially signed firmware to be installed is clearly something we would never do.

Please don't waste time by just spamming the results for AI without human review