The Coffee Machine Incident: A Vulnerability Disclosure in 120 Days

What follows is fiction. Any resemblance to your office is a coincidence, and also inevitable.

Day 1. New coffee machine installed in the open kitchen, three steps from the visitor meeting room. Bean hopper opens without a key. Water tank opens without a key. Anyone in the building, including guests, contractors and the man who came to argue about the parking invoice, has write access to everything the company drinks. I file ticket #4021 with IT: “Unauthenticated physical access to shared beverage infrastructure.”

Day 2. Ticket #4021 closed. Resolution: “Coffee machine is not an IT asset.”

Day 3. Filed with Facilities. Response by end of day: “It has a power cord and a screen. That’s IT.”

Day 8. Raised it at the all-hands under “any other business.” Got the biggest laugh of the quarter, which stung, because Marketing had spent twenty minutes on their new slogan. The CFO said the coffee was the best thing about the building. He is not wrong, which is sort of my point.

Day 15. Proof of concept, executed responsibly: I left a folded note inside the bean hopper. It said, “I could have been anything.” The office manager found it two days later, threw it away, and sent a company-wide email asking people to stop leaving rubbish in the machine. My disclosure was literally taken out with the trash.

Day 22. Wrote a formal risk assessment instead. Three pages. Corporate template. Likelihood, impact, a heat map with an honest red square in the corner. Attached it to the reopened ticket. The ticket now has a label: wontfix-funny.

Day 40. Release week. Somebody — and I want to be very clear that it was not me — swapped the beans for decaf.

No alarms went off, because there are no alarms. The first symptom appeared around 10:40 as a general softness in the standup. By 14:00 two engineers were asleep in the sprint review with their cameras on. The deploy went out ninety minutes late because the person holding the deploy button read the same Slack thread four times “to be sure.” Nobody noticed the CTO’s demo had crashed, including the CTO.

At 16:20 an incident was finally declared. Severity 1. Title: “Coffee tastes wrong.”

Day 41. Emergency retrospective. Attendance was better than for any postmortem in company history. Fourteen minutes in, someone remembered that I had “predicted” the attack, and for a short while I was the prime suspect, on the theory that the person who reports the hole must be the person who wanted to use it. I pointed at ticket #4021, opened 40 days earlier, as my alibi. This did not help. A ticket, it turns out, reads very differently after the incident than before it.

Day 45. The countermeasures arrived, and they were magnificent.

The machine was moved behind reception, where reception can watch it. Reception’s shift ends at 17:00; engineering’s coffee consumption peaks at 21:30, but that was ruled out of scope. A padlock now secures the bean hopper. The key hangs on a hook beside the machine, at a height convenient for visitors. A camera was pointed at the kitchen. It records to a USB stick, which Dave from Facilities takes home every Friday, for backup.

Day 60. By decree, all modifications to the machine now go through the newly formed Coffee Advisory Board. Changing the grind size requires a request form, two approvals and a documented rollback plan. The board meets on Thursdays. It has already rejected one request for “insufficient business justification” and tabled another pending “stakeholder alignment on crema.”

Day 74. The users have responded to the new controls the way users always respond to controls: they routed around them. Thermoses appeared. Personal ones at first, then a communal one of frankly industrial capacity, refilled at the café downstairs by whoever loses at rock-paper-scissors. Management noticed and banned outside beverages. The thermoses did not disappear. They went underground.

Day 75. There is now a french press in the server room. I want to note the security posture here without any irony at all: it sits in the only room in the building with badge access, an entry log and a camera that records to something that is not a USB stick. The most protected asset in the company is unofficial coffee. Someone labeled the press “DO NOT REMOVE — LOAD-BEARING.” Nobody has touched it.

Day 90. The annual audit reviewed the kitchen. Findings: the padlock on the bean hopper was rated “commendable.” The water line, which enters the machine from the wall and was never secured by anyone, was rated “out of scope, see next cycle.” I had covered the water line on page three of my risk assessment, in the appendix. Nobody reads appendices. I have begun putting my most important findings in appendices as a form of encryption.

Day 118. Budget approved for a replacement machine, an enterprise model, procured specifically — I am quoting the purchase order — “with security in mind.” It arrived today. It has Wi-Fi. It has a companion mobile app. It has a cloud dashboard, a loyalty program, and a REST API. The default admin password is printed in the quick-start guide, which is available as a PDF on the manufacturer’s website.

It is, at last, officially an IT asset.

Day 120. Ticket #4021 has been reopened and assigned an owner.

The owner is me.

Closing note: the machine’s firmware changelog thanks an anonymous researcher for reporting “a remote bean-type override issue.” I have printed the changelog and put it in the drawer with the padlock key, where I know people will find it after the next incident.

---

The coffee in this story is fictional. The pattern is not: findings without owners age into incidents, controls added after the fact protect the wrong thing, and the assets nobody claims are the ones attackers like best. If your network has a coffee machine — and it does, usually several, some with REST APIs — the cheapest time to find it is before Day 40.