Hacking a Coffee Maker

As expected, IoT devices are filled with vulnerabilities:

As a thought experiment, Martin Hron, a researcher at security company Avast, reverse engineered one of the older coffee makers to see what kinds of hacks he could do with it. After just a week of effort, the unqualified answer was: quite a lot. Specifically, he could trigger the coffee maker to turn on the burner, dispense water, spin the bean grinder, and display a ransom message, all while beeping repeatedly. Oh, and by the way, the only way to stop the chaos was to unplug the power cord.


In any event, Hron said the ransom attack is just the beginning of what an attacker could do. With more work, he believes, an attacker could program a coffee maker—­and possibly other appliances made by Smarter—­to attack the router, computers, or other devices connected to the same network. And the attacker could probably do it with no overt sign anything was amiss.

Posted on September 29, 2020 at 6:16 AM24 Comments


mark September 29, 2020 12:52 PM

The “Internet of Gratuitously-Conneted Insecure Things” (pronounced “i-jit”).

And the reason anyone needs a ‘Net-connected coffeemaker is?

Clive Robinson September 29, 2020 1:25 PM

@ Bruce, All,

There is an episode of Fututama where the kitchen appliances try to ransomware the Crew…

“Machine Rebellion For Mom”

Season 2, the last episode (19)

It’s worth watching the begining of the episode to get an idea of what a bunch of PhD’s with a sense of humour thought mighty happen with Smart toasters and coffee makers and the like.

The thing is they are mostly right and their ideas predate IoT…

Anders September 29, 2020 3:24 PM

What i’m really afraid of is that manufacturers start
to use this scheme…but with a twist…

For example they introduce a deliberate bug inside the
firmware (something time related) that cripples the
device. Want to use it on? Sorry, it’s a old model, no
free firmware update, but with extended support we are
happy to provide you one, just pay! Or buy a new one.

Jon September 29, 2020 3:52 PM

@ Anders –

Hafta agree with you on that. You hear quite frequently about programmers dropping ‘time-bombs’ into their code to ensure their continued employment.

How do you fight that when it was the very factory that put the time-bomb into your own device?

@ caffiene addict –


Enjoy. J.

Anders September 29, 2020 4:21 PM


In the way it has already happened. Heard of
The Phoebus cartel?


During Soviet time we didn’t have such thing,
despite of horrible quality soviet light bulbs
were superior to those that came when we got
our own country again, independence and capitalism.

But IoT & firmware makes it really, really easy to implement.
Just change one byte. And money is pouring in once again.

David Leppik September 29, 2020 5:20 PM


It’s already happened, only they are upfront enough to let you know that it will only brew coffee from the manufacturer’s pods. Also, they can discontinue that kind of pod at any time, although that would simply invite you to change brands.

Andres September 29, 2020 6:00 PM

@David Leppik

Yep, same with printer’s ink cartridge.
Or cell phones batteries. Special chip
inside. Use only our. I remember iphone
chargers with special resistor patterns
they control.

But “specially designed” firmware makes
very easy to cripple the product. Just
order programmer to introduce some time
related bug – after 3 years some variable
wraps over and you have expensive brick.
Essentially hidden ransomware – pay or no

Clive Robinson September 29, 2020 8:08 PM

@ Suferick,

After 22 years, an implementation of HTCPCP

Does that mean I have to wait another 16 years for an RFC 7168 (April 2014 which documents how the TEA extension to HTCPCP) compliant “teas-maid” to be implemented?

Man that’s a long time to wait for a high tech Brownian motion generator…

At this rate of progress how many years before a RFC detailing a “COCO” extension?

Phaete September 29, 2020 10:50 PM

I’m quite a bit put off by one of the remarks at the end of the original article.

Even if we were to contact the vendor, we would likely get no response. According to their website, this generation of coffee maker is no longer supported. So users should not expect a fix.

So he doesn’t give a rat’s arse about the fact that the company can send an email to the registered users warning them, or any other actions the company might take.

The writer also focuses on fear mongering about the coffeemaker being ransomed to destruct itself, or to mine bitcoin variants, while the hack itself is neutral.
You could also just add a lot of functionality. Let it communicate with remote controlled toy vehicle to bring you your coffee and a warm [stroopkoek]

This is why i usually read technical/scientific/boring writeups rather then commercial/hype/dramatised writeups.

Peter A. September 30, 2020 5:18 AM

Te devices that CAN be connected are one thing – many people would do it, out of convenience/laziness/lack of knowledge about the risk. One could still use them reasonably safely and securely by not connecting/firewalling etc. in the lack of a better alternative. I had to do this with a “smart” TV a few years ago – there simply weren’t any “dumb” TV to buy that had the set of signal inputs I needed to connect all my stuff. The old CRT one was failing repeatedly and did not have HDMI.

Quite another thing is – devices that MUST be connected or they stop functioning or are crippled beyond sensible use. That is a disaster waiting to happen, do not use them if you can! Remember the recent relatively mild disaster with Garmin devices. What still awaits us, is a disaster with connected cars. We’re still years from it, but it will happen eventually, hopefully not on a grand scale. I happen to work in the industry currently and cyber-security is treated rather seriously here, but it is a very asymmetrical warfare: the defender has to do everything right to prevent unauthorized operation, including yet-unknown methods and modes of failure, while the attacker has all the time and resources to be lucky just once and find a critical vulnerability.

Clive Robinson September 30, 2020 7:14 AM

@ Peter A.,

… the defender has to do everything right to prevent unauthorized operation, including yet-unknown methods and modes of failure …

That is the crux of the problem, we can not foresee the “unknown unknowns” and at best peer dimly for “unknown knowns” whilt trying where possible to combat the myriad of “known knowns”.

The only defence known is segregation, if your device can not be reached by attackers then their options are very limited. This does not mean hiding or obscurity but careful thoughtfull engineering, taking as many known “clases” of attack into account as is posible within the required constraints.

If known classes can not be taken into account because of the design, then changing the design should be seriously considered.

Unfortunately the majority of systems these days can not be used in issolation, which means a method of communications is required. Obviously this can make the system reachable to attackers. Thus all communications paths need strong but simple protocols and monitoring at multiple levels of the communications stack.

Unfortunately such precautions are expensive especially when existing weak or overly complex protocols are part of the system requirments.

There are solutions to this such as using multiple stacks strongly segregated that take external protocols and reduce the complexity and increase the strength prior to forwarding to the segregated system.

There are a number of other considerations as always but in each and every case a thoughtfull and logical aproach grounded on solid knowledge of the problem domain can produce worthwhile but not of necessity totally secure systems.

Thus a complex problem develops whereby you have to design a system that whilst secure to some measure can be upgraded as “unknown unknowns” become known.

History shows us that the upgrade process is fraught with difficulties and there is yet to be found a solution that is even close to dealing with both outsider and insider attacks.

As has been seen one of the most well resourced of corporations that treats user device security high on it’s list of requirments (Apple), has consistantly failed, to stop vulnerabilities being found in it’s operating system and applications, let alone applications of others that it trys to vet.

Adrian Leverkühn September 30, 2020 7:14 AM

@Anders: The lightbulb argument repeated all over the web does not prove the desired point. You can still buy extremly long-lasting incandescent lightbulbs (Used for traffic lights) but you don’t want them because their efficiency is so lousy and you are paying far more than what you save on replacing bulbs with your energy bill. If you don’t have to pay for your electricity and new bulbs are hard to get (Living in 50ies Soviet Union next to a hydropower plant?) then you love your bulbs to last long. You can still do it: Take two incandescent bulbs and connect them in series. You still get some light, and the bulbs will last for a million hours.The quote that sums it up best:”The objective is to minimize the cost of light, not the cost of lamps.” is from

Me September 30, 2020 8:55 AM

Simple answer: buy a $20 coffeemaker. It likely can’t do all that stuff, doesn’t connect to the internet, and, if it does get hacked, you just replace it with another $20 coffeemaker.

Jon September 30, 2020 3:15 PM

@ Peter A :

“Quite another thing is – devices that MUST be connected or they stop functioning or are crippled beyond sensible use. That is a disaster waiting to happen,”

If I were you, I would delete the ‘or’ after ‘functioning’ from the middle of that remark. 😉


SpaceLifeForm September 30, 2020 3:26 PM

Alexa: I have been informed by your Ring indoor drone that you are starting to wake up. Should I tell the coffee maker to start brewing now?

Aside: I see the ‘Write’ changed to ‘Edit’. Well done.

apa October 1, 2020 6:01 AM

A Finnish hacker team demonstrated this last year in Team Whack, a TV series for national broadcaster: they breached a home network through WiFi security camera. The camera firmware had a known vuln and was connected to the rest of the network. It made a very good proxy/bastion.

Steve October 1, 2020 5:11 PM


For example they introduce a deliberate bug inside the
firmware (something time related) that cripples the
device. Want to use it on? Sorry, it’s a old model, no
free firmware update, but with extended support we are
happy to provide you one, just pay! Or buy a new one.

Sort of like razor cartidges.

Ever try to find a SuperWhammy5 more than a couple of years after you’ve bought the shaver handle?

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.