By Home Assistantis one of the most popular solutions for running and managing your smart home at the moment. Besides being open-source software (OSS), it has support for a myriad of different devices and services out in the market. Adding Home Assistant to your home can be as straightforward as simply purchasing a plug-and-play device (Home Assistant Green), or running your own Home Assistant via Docker with your own hardware customisations. As such, it is no surprise that Home Assistant is so popular among consumers who want to live in a smart home. At the same time, its widespread adoption makes it a prime target for attacks, especially when it is typically deployed within a trusted network (such as homes). Back in 2023, we published a detailedblog poston how we audited Home Assistant's pre-auth attack surface. Part of the research was assessing Home Assistant's various integrations with different smart devices, and we noted that most integrations are performed through HTTP. As that blog post already provided information about the Home Assistant architectural overview, and there were no major changes since then, we shall not go into the finer details here. This time, when we looked into Home Assistant, we were interested in hunting for attack chain primitives rather than a full exploit chain. We believe that high impact bugs will always be relevant no matter if they are exploitable now, or could potentially be exploited in the future. This research bore fruit as we were able to discover an interesting command injection vulnerability inffmpegand managed to exploit it using a novel technique to take over Home Assistant. We reported it to the developers, and it was patched in version2026.6.2. Even though this issue was remediated, our submission was closed as N/A: Nonetheless, we have published an advisoryhere. Note that this blog post only covers theffmpegsink specifically, which we found while exploring sinks in potential exploit chains. We researched Home Assistant back in 2023, and found a critical authentication bypass vulnerability with the Home Assistant Supervisor Integration (CVE-2023-27482). Thereafter, Cure53 and GitHub Security Lab also researched Home Assistant and discovered more vulnerabilities within Core and its mobile applications. Then,Pwn2Own Ireland 2025rolled around and introduced Home Assistant Green as a target with a $40,000 (USD) bounty. There were four submissions which were all successful (albeit with some collisions), with bugs such as: SSRF, command injection, arbitrary file write and cleartext transmission of sensitive data. With that many successful entries, we wondered: how many high impact attack chain primitives are actually sitting unexploitable without a full chain? We searched Home Assistant Core for any command injection that was perhaps thought to be unexploitable, or required constraints that made it hard to use in Pwn2Own (full chains), such as requiring an authentication bypass vulnerability as a prerequisite. This was when we stumbled across an argument injection inffmpeg, where attacker-controlled input is used as one of the command arguments. The vulnerability wasn't string interpolation where arbitrary commands could be inserted, but rather attacker input injected as part of a single command argument. Exploiting this vulnerability allowed us to read and exfiltrate the content of any local file. One highly-sensitive target would be/proc/self/environ, which contained theSUPERVISOR_TOKEN, opening the path to remote code execution on the Home Assistant server. This is because the token allows an attacker to abuse the supervisor's APIs to achieve command execution as root on the host. The affected code was identified within Home Assistant's Wyoming protocol integration, which has anannounceservice that plays audio through anffmpegsub-process. Themedia_idparameter accepted attacker-controlled strings and passed them directly toffmpegas the-icommand argument. Handling ofannouncewas found inassist_satellite.py, where the user-controlledannouncement.media_idis parsed and used as part of theffmpegprocess being spawned: At first glance, this looked like a straightforward sink to exploit, but multiple constraints presented themselves once we tried. What is an exploitation write-up without obstacles? 😛 Firstly, theannouncement.media_idfield was validated as a URL, and its scheme was checked against a blocklist thatrejectedhttpandhttpsthat pointed to any Home Assistant address. Thus, SSRF to interact with local services is mostly blocked. However,ffmpegpseudo-protocols, includingconcat:,file:andsubfile:were absent from this blocklist and accepted as valid input. This allowed us to pass arbitraryffmpegprotocol strings directly to the sub-process. Our immediate thought was then to read local files since we could usefile:(e.g.file:///proc/self/environ), in order to exfiltrate sensitive environment variables (such asSUPERVISOR_TOKEN). Reading/proc/self/environdirectly wasn't pos...