Rode’s Rodecaster Duo—a $499 professional audio interface used by podcasters and streamers worldwide—ships with SSH enabled by default on port 22, a security researcher discovered April 25, 2026. Nowhere in the documentation does Rode mention that every unit is running an open SSH server accessible to anyone on the local network. The discovery highlights how professional audio gear has quietly become IoT devices with all the security baggage that entails.
The Technical Reality
The Rodecaster Duo runs 64-bit embedded Linux with a 1.5 GHz quad-core processor underneath its podcast mixer interface. Port 22 is wide open. The firmware ships as an unsigned tarball with no encryption and no signature verification—meaning anyone on your network can probe for SSH access, and anyone who intercepts a firmware update could inject malware.
This isn’t theoretical. On a shared studio network, at a conference, or in a coffee shop, an attacker with local network access could eavesdrop on recordings, inject audio into live streams, or recruit the device into a botnet. The attack surface exists because the device needs network features—Rode’s “CallMe” remote podcasting capability requires Wi-Fi and Ethernet connectivity. However, shipping with SSH enabled by default crosses the line from feature to vulnerability.
The broader context makes this worse. In 2026, 89% of Linux endpoint attacks are SSH brute-force attempts. IoT botnets like Aisuru/TurboMirai have reached 20+ terabits-per-second DDoS capability. Professional podcasters and streamers—who aren’t security experts—now have devices on their networks that behave like servers, not appliances.
Why Audio Gear Runs Linux
This isn’t unique to Rode. Modern audio interfaces increasingly run embedded Linux because the operating system provides flexible real-time audio processing, network stack support, and open-source driver ecosystems. Behringer, Midas, and Allen & Heath all use Linux-based systems in their networked audio products.
SSH access makes sense during development. Engineers need to test firmware, diagnose issues, and configure devices remotely. Nevertheless, SSH enabled for development somehow made it to production builds—and stayed there. This is a classic threat modeling failure: audio hardware wasn’t traditionally viewed as security-critical, so the “disable SSH before shipping” checklist item never existed.
The Hacker News discussion reveals the community divide. One commenter wrote: “This makes me want to purchase your gear. Don’t change it.” The hacker and maker communities value open, hackable hardware. They want SSH access to customize audio routing, install third-party extensions, and tinker with the Linux underpinnings. From that perspective, Rode’s openness is a feature. But from a security perspective, default SSH violates the fundamental principle of “secure by default.”
Regulatory Pressure Coming
That tension between openness and security is about to get resolved—by regulation. The EU Cyber Resilience Act (CRA) entered force in December 2024, with full compliance obligations taking effect in December 2027. Reporting requirements for vulnerabilities start in September 2026—just five months from now.
The CRA mandates “secure by default” configuration, meaning SSH must be disabled unless explicitly enabled by the user. It requires firmware signing and secure boot to prevent supply chain attacks. Products cannot ship with known exploitable vulnerabilities. Manufacturers must commit to five years of security updates minimum. Rode’s current practice would violate every one of those requirements.
Moreover, this isn’t just Rode’s problem. The entire professional audio industry will need to adopt secure development lifecycles, implement code signing infrastructure, establish vulnerability disclosure programs, and conduct third-party security audits. The timeline is tight: 20 months until full compliance, and non-compliance means no EU market access.
What Should Happen Next
Rode should issue a security advisory acknowledging SSH access, release a firmware update with SSH disabled by default, and document all network services in the user manual. The middle-ground solution: make SSH an opt-in feature with clear instructions for power users who want access. That satisfies both security professionals who need “secure by default” and the hacker community who values openness.
Meanwhile, users should isolate their Rodecaster Duo on a separate network VLAN and block port 22 at the firewall until Rode ships a fix. Network segmentation is the best mitigation: treat your audio interface like you’d treat a smart TV or IP camera—untrusted until proven otherwise.
The broader industry should use this disclosure as a wake-up call. Networked audio gear is IoT now, with all the security responsibilities that entails. CRA compliance isn’t optional. Professional audio equipment running embedded Linux with undocumented SSH access isn’t a quirky feature—it’s a security issue that reveals how far the industry has drifted from basic secure development practices.
