A digital-billboard controller will happily write whatever file you hand it, no questions asked
Daktronics VFC-DMP-5000 (and sibling DMP-5000 / DMP-8000) controllers run a file service that accepts uploads from any authenticated session without validating the extension, MIME type, or content. An attacker who can authenticate can drop a binary, shell script, or configuration file straight onto the controller's filesystem — the same filesystem that runs the sign's playback engine. Affected firmware is anything below 8.117.x.x, 9.43.x.x, or 10.34.x.x; vendor fix tracks are 8.117.0.x, 9.43.0.x, and 10.34.0.x depending on hardware revision.
Vendor's HIGH/7.1 rating is *technically* correct — PR:L makes the math come out to 7.1 — but it understates the operational reality. Daktronics' product line has a long, well-documented history of internet-exposed units running default credentials, including the infamous DOT highway-sign hijack cases. 'Authenticated' on a fleet of LED controllers reachable from the open internet is a much thinner gate than 'authenticated' on a hardened enterprise app. We hold the score at 7.1 but warn that the *effective* exploit barrier is closer to MEDIUM-PR than HIGH-PR for any defender who has not rotated factory passwords.
5 steps from start to impact.
Locate exposed controller
http.title:"Daktronics", port 80/8080/8082). Census of the install base typically returns a few hundred to low thousands of directly reachable units, plus a much larger pool reachable from compromised stadium / venue / DOT networks.- Controller is reachable over IP — either directly internet-facing or via flat venue/DOT network
- Attacker has Shodan/Censys access or active scanner like
masscan+ Daktronics fingerprint
- Many properly-deployed units sit behind a vendor-managed VPN (Show Control Pro or carrier-provided APN)
- Some operators NAT controllers behind a single jump host
Authenticate to the file service
PR:L requirement is satisfied — but on Daktronics fleets specifically, 'authenticated' has historically been a low bar.- Valid credentials for any role with file-service access
- Reachable management interface from step 1
- Operators who rotated default credentials and enforce strong passwords genuinely raise the bar here
- Some deployments restrict the management VLAN to a single ops workstation
Upload arbitrary file via file service
curl script reproduces the bug.- Active session token from step 2
- Filesystem may be read-mostly on certain firmware revisions, limiting write paths
- Some DMP variants run a stripped musl userland that won't execute a generic x86_64 ELF
Achieve code execution on the controller
- Writable path in step 3 intersects an executable code path
- Some models verify firmware signatures on boot — but this bug is below that layer, in user content
- No clean persistence across factory-reset workflows used by some operators
Optional pivot inside venue/DOT network
chisel, ligolo, tinyproxy recompiled for the controller's ARM/x86 target.- Controller has L3 reachability to other internal hosts
- Attacker can cross-compile or use static ARM/MIPS tooling
- Properly segmented OT networks (Purdue-aligned) block the pivot at the conduit firewall
- DOT and Big-Four-stadium ops increasingly run a dedicated sign VLAN with strict egress
The supporting signals.
| In-the-wild status | No known active exploitation as of 2026-06-30. Not KEV-listed. No named campaigns. |
|---|---|
| Proof-of-concept | No public PoC repo at disclosure. Bug is trivial to reproduce — curl -u user:pass -F [email protected] https://<host>/fileservice/upload. |
| EPSS | 0.00341 (~74th percentile) — low predicted exploitation in next 30 days, consistent with niche embedded target. |
| KEV status | Not listed. CISA published ICS advisory ICSA-26-176-04 on disclosure date. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N → 7.1 HIGH. Network-reachable, low complexity, low-priv auth required, integrity-heavy impact. |
| Affected versions | VFC-DMP-5000, DMP-5000, DMP-8000 firmware below 8.117.x.x, 9.43.x.x, or 10.34.x.x (track depends on hardware variant). |
| Fixed versions | 8.117.0.x, 9.43.0.x, 10.34.0.x — vendor-published. No distro backports apply (embedded controller). |
| Exposure data | Shodan and Censys consistently fingerprint Daktronics controllers; public-facing count typically in the low thousands. Stadiums, transportation signage, retail digital billboards are the dominant deployment roles. |
| Disclosed | 2026-06-26 via CISA ICS-CERT coordinated disclosure (ICSA-26-176-04). |
| Credit | Reported by Daktronics through CISA's ICS coordinated-disclosure channel; researcher attribution pending in the advisory. |
noisgate verdict.
Held at HIGH because the single decisive factor — PR:L authentication requirement — is materially weakened by Daktronics' well-documented default-credential history and the fleet's public internet exposure on Shodan/Censys. The chain ends in code execution as root on an embedded controller whose worst-case role is a DOT highway sign, where defacement is a public-safety event.
Why this verdict
- Authentication is a soft gate on this fleet: Daktronics' install base has a documented history of factory-default credentials surviving deployment, including prior public DOT-sign hijacks.
PR:Lunderstates effective exploitability. - Role multiplier — DOT / public-safety signage: when the affected controller is driving highway variable-message signs, a successful chain ends in attacker-controlled public-safety messaging. That floors the verdict at HIGH and would push CRITICAL if KEV-listed.
- Role multiplier — stadium / commercial signage: chain ends in reputational defacement during a televised event. Blast radius is one sign, but media impact is high.
- Role multiplier — corporate/retail in-store signage: chain ends in a single embedded foothold; pivot potential exists but is gated by venue network segmentation. This is the population that justifies *not* upgrading to CRITICAL.
- Exposure is non-trivial but bounded: Shodan/Censys return low-thousands of directly reachable units — meaningful, but well below the 'mass internet target' threshold that drives KEV-grade urgency.
- EPSS 0.00341 and no public PoC trim the near-term exploitation probability, but the bug is a 15-line
curlaway from a working exploit once anyone bothers.
Why not higher?
Not CRITICAL because (a) authentication is genuinely required even if the bar is low, (b) the affected component is a single-purpose display controller — blast radius does not naturally extend to domain or identity tier, and (c) there is no in-the-wild exploitation evidence and no KEV listing. A CRITICAL bucket here would conflate a high-impact-per-host bug with a fleet-wide identity/hypervisor compromise.
Why not lower?
Not MEDIUM because the role-multiplier floor for transportation/public-safety deployments holds the verdict at HIGH regardless of friction. The chain produces root-equivalent code execution on the controller, the default-credential reality of this product line erodes the PR:L discount, and CISA judged the issue worth an ICS advisory on disclosure day.
What to do — in priority order.
- Rotate factory and shared credentials on every Daktronics controller in the fleet — The vuln is gated by authentication; killing default and reused passwords is the single highest-leverage control. Deploy within 30 days per noisgate mitigation SLA for HIGH. Use a per-device unique password stored in your PAM.
- Block inbound to controller management ports from the internet at the perimeter — Most legitimate management traffic comes from a known ops workstation or vendor VPN. ACL TCP/80, 8080, 8082, and any vendor file-service ports to that source set only. Implement within 30 days.
- Segment the signage VLAN with explicit egress allowlists — Prevents step-5 pivot if a controller is compromised. Restrict egress to vendor cloud, NTP, and your management host only — drop everything else. Roll out within 30 days.
- Subscribe to Daktronics security bulletins and pre-stage firmware 8.117.0.x / 9.43.0.x / 10.34.0.x — Validate the firmware on a single test unit, then schedule a maintenance window across the fleet. Complete remediation within the 180-day noisgate remediation SLA for HIGH.
- Ship controller auth logs to a SIEM and alert on file-service POSTs — Even without a vendor-supplied audit feed, you can syslog-forward the device's web logs. Alert on any file-service upload originating from a non-management source IP.
- Network-based WAF rules on generic file-upload patterns — the controller's file service does not look like a standard web app and most WAFs do not have a profile for it.
- EDR or AV on the controller — there is none for this embedded platform; do not assume host telemetry exists.
- MFA on the management UI — the controller firmware does not support MFA; do not plan around it.
- Relying on
PR:Lto keep this off the priority list — Daktronics' default-credential history makes the auth gate weaker than the CVSS vector implies.
Crowdsourced verification payload.
Run from an auditor workstation with network reach to the controller. Provide the controller hostname/IP, a known-good credential, and an optional firmware-track override. Example: ./check_dmp5000.sh 10.20.30.40 admin 'CorrectHorseBattery'. No elevated privileges required on the auditor host; the credential needs only basic UI login on the controller.
#!/usr/bin/env bash
# noisgate verifier — CVE-2026-33560 (Daktronics DMP-5000 file service)
# Probes the controller's firmware version banner and compares to the fixed tracks.
# Output: VULNERABLE | PATCHED | UNKNOWN
set -u
TARGET="${1:-}"
USER="${2:-admin}"
PASS="${3:-}"
if [[ -z "$TARGET" || -z "$PASS" ]]; then
echo "usage: $0 <host-or-ip> <user> <pass>" >&2
echo "UNKNOWN"; exit 2
fi
# Try the common management endpoints used by DMP-series controllers
for scheme in https http; do
for port in 443 8082 8080 80; do
URL="$scheme://$TARGET:$port/api/system/version"
BODY=$(curl -sk --max-time 5 -u "$USER:$PASS" "$URL" 2>/dev/null) || continue
VER=$(echo "$BODY" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -n1)
[[ -n "$VER" ]] && break 2
done
done
if [[ -z "${VER:-}" ]]; then
echo "could not retrieve firmware version from $TARGET" >&2
echo "UNKNOWN"; exit 3
fi
MAJ=$(echo "$VER" | cut -d. -f1)
MIN=$(echo "$VER" | cut -d. -f2)
case "$MAJ" in
8) FIX_MIN=117 ;;
9) FIX_MIN=43 ;;
10) FIX_MIN=34 ;;
*) echo "unrecognized firmware track: $VER" >&2; echo "UNKNOWN"; exit 4 ;;
esac
if (( MIN < FIX_MIN )); then
echo "running $VER — below fixed minor $MAJ.$FIX_MIN.0.x"
echo "VULNERABLE"; exit 1
else
echo "running $VER — at or above fixed minor $MAJ.$FIX_MIN.0.x"
echo "PATCHED"; exit 0
fi
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.