I opened a Hubitat C8-Pro to see how private and secure it actually is. I wanted to get root, inspect files and services, and list practical fixes you can make yourself. This is a hands-on how-to, not theory. I focus on the steps I used, the hard facts I found, and short, concrete fixes you can apply.
I gained serial access with a USB‑to‑TTL adapter and picocom. The exact command I used was: sudo picocom -b 921600 /dev/ttyUSB0. Use the right adapter pins for TX, RX and GND and remove power before wiring. After powering the board, the console floods at boot. Wait for a login prompt and try the default shell; on my unit the hub user existed but a root shell was accessible from the serial console. To verify root, run id or whoami and look for uid=0. Once at root, copy key system files to a thumb drive or scp them off the hub: /etc/passwd, /etc/shadow, /etc/dropbear*, /root/.ssh, and application directories under /usr/local or /opt. Grep for suspicious strings with commands like grep -R “AWS” / -n or grep -R “PRIVATE KEY” / -n. Those searches show what I later found.
My inspection revealed several concrete privacy and security issues. The web application and installed packages contained hard-coded secrets. I found an RSA private key and AWS access and secret keys embedded in application files. The system also contained a client that establishes a reverse SSH connection to a Hubitat server hosted on AWS, giving remote shell access back to the vendor. The hub blocks incoming SSH on the usual port, but a dropbear instance runs locally and handles the outbound or tunneled connections. Backups and logs were configured to be pushed to S3 buckets in AWS; these backups can include user email addresses and configuration files. The hub uses third‑party TTS services such as Google and Amazon for voice output, which can send snippets of audio or text to cloud providers. The firmware bundles GPL code, so source code requests are valid under licence, but that appears not to have been actioned by the vendor. All of that means the device is capable of pushing data off the local network and accepting remote connections that bypass the local admin UI.
Take action with practical, specific steps. Start by changing any default credentials and remove unused accounts you find in /etc/passwd. Regenerate any keys you find that are embedded in files, then rotate the associated credentials in the cloud console if you can identify the account owner. Disable cloud backups and remote access within the Hubitat UI if the option exists. Block outbound connections from the hub to known cloud endpoints at your router or firewall. A simple iptables rule on a home gateway can block outbound SSH or HTTPS to the vendor domains until you trust the device. If you keep the hub on the network, isolate it on its own VLAN and deny access to sensitive LAN services. Where possible, remove or replace TTS and other third‑party integrations that send data off box. After making changes, verify them: confirm the reverse SSH process is not running with ps aux | grep ssh, check open ports with ss -tuln, and run again the grep searches for keys. If you want the codebase audited beyond what you can see, request the GPL source from the vendor and ask for a changelog or patch for the hard-coded secrets.
I prefer local control and minimal cloud reliance for automation devices. Treat a C8‑Pro as a device that can phone home until you lock down its traffic and credentials. Short, targeted fixes reduce risk quickly: isolate the device, remove embedded secrets, block outbound tunnels, disable backups you do not trust, and ask the vendor for source and remediation. That gives you a clear audit trail and a measurable reduction in data leakage.
