A BBC Reporter's Laptop Was Taken Over. An Ex-Failed-Engineer Breaks Down the Orchids Incident and '4 Alarms in 3 Weeks'

A note file named “Joe is hacked” appeared out of nowhere on his desktop.

The wallpaper had been swapped out for an illustration of an AI hacker.

The person at the laptop was BBC journalist Joe Tidy. The attacker was cybersecurity researcher Etizaz Mohsin. And the bridge between them was Orchids—an AI platform for “vibe coding.” That’s where the BBC-covered Orchids incident begins. Note: the primary BBC URL is still being verified at the time of writing. Multiple secondary outlets, including InformationWeek, have independently reported consistent details.

I’ve been writing a vibe coding series for a while now. Just two days before this story broke, I published the eighth installment on Cisco Project CodeGuard, where I wrote that “the era of big companies lending a hand has arrived.” Then the BBC incident hit.

Honestly, I needed to step back and process.

This isn’t a one-off event. To me, it looks like evidence of a “threshold crossing”—four alarms going off in three weeks. As a former failed engineer, I’m going to walk through what happened, in order. Not to scare anyone, but to turn it into action you can take today.

---

First: What Actually Happened in the Orchids Incident

Orchids is an AI platform for “vibe coding”—building apps with natural language prompts.

• Headquarters: San Francisco, USA
• Founded: 2025 (per LinkedIn page)
• Team size: Under 10 people
• Users: 1 million (company’s own claim)
• Notable clients: Google, Uber, Amazon (company’s own claim)

By the numbers alone, it fits the profile of a classic high-growth startup.

Here’s how the incident unfolded, as reported.

In December 2025, researcher Etizaz Mohsin was experimenting with vibe coding systems when he spotted a vulnerability in Orchids. He later performed a zero-click attack demo targeting an Orchids project created by BBC journalist Joe Tidy.

“Zero-click” refers to a class of vulnerability where an attack succeeds without the victim clicking anything at all. No phishing link to follow, no attachment to open. If the attack surface lives on the platform side, an intruder can get in with zero fault on the user’s end.

What Mohsin did, as reported, went roughly like this:

1. He gained unauthorized access to an Orchids project that Tidy had built through vibe coding
2. He embedded a single, hard-to-spot line among thousands of lines of code
3. That line reached Tidy’s laptop and rewrote the desktop
4. It created a note file called “Joe is hacked” and changed the wallpaper to an AI hacker image

What made this demo so striking was that an attacker could take over someone’s laptop simply by modifying the code in another person’s vibe coding project.

If Orchids truly has a million users as claimed, that same attack surface potentially extends to every single one of them. That’s the backdrop to BBC’s “easily hacked” headline.

References: InformationWeek “Zero-click hack exposes flaw in Orchids vibe coding platform” / Digital Watch Observatory “Security flaws expose ‘vibe-coding’ AI platform Orchids to easy hacking” / CySecurity News “AI Coding Platform Orchids Exposed to Zero-Click Hack in BBC Security Test”

---

Why This Incident Won’t Stay Isolated—4 Alarms in 3 Weeks

When I first read about the Orchids incident, my immediate reaction was “again.”

That gut response says something: in the past three weeks, alarms have been going off in the same direction, one after another. Let me lay them out.

Alarm 1: Oct 2025 → Feb 2026 — Cisco Project CodeGuard

Cisco released “Project CodeGuard” as open source on GitHub in October 2025—a security ruleset designed for AI coding agents. It supports Cursor, GitHub Copilot, and Claude Code. The official repository is github.com/project-codeguard/rules.

In February 2026, Cisco donated the project to CoSAI (the Coalition for Secure AI). It graduated from a single company’s initiative to a candidate for industry-wide standards.

That’s Alarm 1: tooling and rule-setting started moving at the industry level.

Alarm 2: April 2026 — Lovable, 170 Vulnerabilities

Lovable is another vibe coding platform. A third-party investigation found security flaws in approximately 10.3% of public apps built on Lovable, with a total of 170 “backdoors” reported.

I covered this in my April series. The core point is simple: “it works” and “it’s safe” are two different things.

Alarm 2: the “individual developer accountability phase” became visible.

Alarm 3: May 2026 — Tenzai Research, 69 Vulnerabilities Across 5 Major Agents

Earlier this month, a research group called Tenzai ran vulnerability scans on five major coding agents and reported a total of 69 issues. Their findings align with a separate SVIBES study, which found that only about 1 in 6 pieces of code that passed functional tests was actually safe—two independent investigations pointing in the same direction.

Alarm 3: the “empirical audit phase” has arrived.

Alarm 4: May 2026 — BBC Orchids Incident

And then the Orchids incident described at the top.

The moment “Joe is hacked” appeared on Tidy’s desktop marked what I’d call the first wave of the “real-world damage phase.” It was a good-faith demo by a researcher—but the fact that the demo worked means it would work for a malicious actor too.

Four times in three weeks. Calling this a coincidence is becoming hard to justify.

---

Why I’d Say Vibe Coding Has Crossed a Threshold

Looking back at software history, when a new development paradigm spreads into society, it tends to move through certain stages. Based on what I’ve seen, the pattern goes something like this:

1. Prototype phase: Early adopters experiment. Incidents are isolated
2. Adoption phase: A flood of users arrives. Incidents become scattered
3. Threshold crossing phase: “There are now enough people doing this that it’s worth attacking”
4. Norm-building phase: Industry rules and standards scramble to catch up

Vibe coding is sitting right on the line between 3 and 4, in my read.

Three reasons inform that judgment.

First, the cost of attacking has dropped. Both Orchids and Lovable were built around natural language prompts and shared project spaces. That’s also a design that’s easy for an attacker to read. There’s no proprietary syntax to decode anymore. Because the attack surface has been standardized, attack methods are easier to standardize too.

Second, the blast radius has grown beyond individuals. Orchids claims a million users. That’s a million people storing code on a platform with the same attack surface. A technique one researcher demoed can, in principle, be aimed at all million of them.

Third, the industry is beginning to respond. Cisco’s donation of Project CodeGuard to CoSAI signals a shift from “one company’s good intentions” to “shared industry defense.” They’re catching up—and the fact that they’re catching up is itself a signal.

“Threshold crossing” is my framing. But it’s hard to look at four alarms in three weeks and call it coincidence.

---

4 Checks an Ex-Failed-Engineer Is Doing Starting Today

That’s the situation. Now let’s turn it into action.

I’m not a dedicated security engineer. I narrowed this down to four checks that are realistic for a vibe coder to actually do.

Check 1: Know Where Your Vibe Coding Platform Stores Your Code

What was hard to see in the Orchids incident was “where is the code I wrote actually being stored?”

Most AI-based vibe coding platforms store user code on the cloud side by default. That’s convenient—but it also means that if the service has a vulnerability, “just protect my local machine” isn’t enough.

Today’s task: pull up the documentation for the platforms you use and find out where your code is stored. Cloud storage? Local storage? Hybrid? Is it just the code, or the entire execution environment? This takes ten minutes.

I redid this check on May 17th. Of the three services I was using, two were “cloud storage, including execution environment” and one was “local storage, cloud sync only.” Even things all called “vibe coding” can have very different attack surface sizes.

Check 2: Put Cisco CodeGuard Rules in Your Repository

I covered this in detail in the eighth installment. In practice, you place a rules file at the root of your project so the AI agent can read it.

# CodeGuard rules layout example
your-project/
├── .codeguard/         # CodeGuard ruleset
│   ├── deny-rules.md   # Prohibited categories
│   ├── recommend-rules.md  # Recommended categories
│   └── context-rules.md    # Context categories
└── src/                # Your code

Just having this ruleset in place creates a structure where the AI treats it as a “design assumption” and refers to it. In my experience, adding a single line at the start of the prompt—“Always reference CodeGuard rules before writing”—noticeably increased the rate at which the AI actually consulted them.

Check 3: Add Bugbot or Equivalent to Your PR Reviews

Bugbot got a significant upgrade in Cursor 3 back in April. It’s now processing over 2 million PRs per month, with 78% of flagged issues resolved (per Cursor’s official site).

Solo vibe coders don’t have reviewers. That’s exactly why inserting one AI reviewer into the loop matters. It meaningfully raises the odds of catching the “it runs but it’s dangerous” code you’d otherwise miss.

It’s not a perfect defense. But when it comes to finding “one malicious line hidden among thousands”—the kind of thing that happened in the Orchids incident—a solo human reviewer is less likely to catch it than an AI reviewer.

Check 4: Draw a Line Between “It Works” and “It’s Ready to Ship”

The power of vibe coding is “getting something running, period”—and that’s the philosophy I’ve built everything on so far.

But after the Orchids incident, I redrew one line for myself.

Code that “just works” stays a personal tool only. Before sharing it with teammates, publishing it externally, or putting it into production, it has to pass at minimum three steps: CodeGuard + Bugbot + 5-minute self-review.

This is my own local rule. Raise the bar too high and you kill the speed that makes vibe coding valuable. Keep no bar at all and incidents like Orchids can land on your side too. The right spot is somewhere between “ship the moment it works” and “review everything.”

---

A Note on “Prevention-First Design” from a CS Background

From here on, this is more about mindset than technology.

During my time in customer success, I was called in to help companies after incidents had already happened, over and over again. The days following an incident left everyone exhausted: root cause analysis, stopgap fixes, permanent solutions, explaining to stakeholders, reaching consensus on prevention measures—time and energy spent without mercy.

What that experience taught me is that “fixing things after an accident” is almost always more expensive than “designing with accidents in mind from the start.”

When you read about something like the Orchids incident, it’s tempting to think “I’ll be fine.” “I’m not a professional security engineer.” “My tool is small.” I heard those exact words countless times in my CS days. Nearly everyone who had an incident believed beforehand that they would be fine.

Vibe coding is fast. And precisely because it’s fast, the “cost of that speed” needs to be part of the design from day one. Five minutes to set up CodeGuard. Three minutes to run Bugbot. Five minutes for a self-review. Thirteen minutes of habit-building, in exchange for days of incident response. The cost-benefit analysis clearly favors the former.

“Prevention-first design” sounds stiff. In my everyday language, it’s “walk carefully enough that you don’t trip before you fall.”

During the three years I spent away from code as a failed engineer, I was listening to users describe their problems. The core habit I built during those years was: “How do you design so that users don’t have accidents in the first place?” Now that I’m back to writing code, I want to bring that habit directly into how I design it.

Writing about friction points before people hit them—that’s something I’ve repeated throughout this series. This time, I’m writing it in advance for people other than myself too. For anyone who read about the BBC incident and thought “that could land near me”—the range of things that 13 minutes of habit can prevent is wider than you might think.

---

Wrap-Up — After 4 Alarms in 3 Weeks, Here’s What to Do Next

To summarize:

• As of May 18th, four major alarms have sounded around vibe coding in the span of three weeks: Cisco CodeGuard, Lovable (170 vulnerabilities), Tenzai (69 vulnerabilities), and BBC Orchids
• The BBC Orchids incident is on the record as real-world harm—a BBC journalist’s laptop taken over zero-click. It was a researcher’s demo, but if the design allows a demo, it allows a malicious actor too
• Taken together, the four alarms indicate that vibe coding is in a “threshold crossing phase”: the cost of attacking has dropped, the blast radius has grown beyond individuals, and the industry is scrambling to respond
• Four things individual vibe coders can do today: check where their code is stored, set up CodeGuard, bring in Bugbot, draw a line between “works” and “ship-ready”
• My conclusion from a CS background: prevention-first design is overwhelmingly cheaper than incident response. The 13-minute habit is worth starting today

I came back to coding as an ex-failed-engineer turned vibe coder, and I intend to keep writing about the joy of being able to build things. “Being able to build” and “being able to protect what you build”—I’m making both a habit, starting today.

I don’t want to let accidents ruin that feeling of having a world-class engineer living inside me. That’s all this is.

---

References

• BBC News / Joe Tidy reporting: “Major vibe coding platform Orchids is easily hacked” (2026 — primary BBC URL still being verified)
• InformationWeek “Zero-click hack exposes flaw in Orchids vibe coding platform”
• Digital Watch Observatory “Security flaws expose ‘vibe-coding’ AI platform Orchids to easy hacking”
• CySecurity News “AI Coding Platform Orchids Exposed to Zero-Click Hack in BBC Security Test”
• Cisco Project CodeGuard official repository: https://github.com/project-codeguard/rules
• Cursor Bugbot official
• You Don’t Need to Know How to Code Anymore—AI Changed That (Nagi)
• For Anyone Confused About “How to Use Claude Code” (Nagi)