A long vulnerability list can hide the real story.

That is what makes the Omi disclosure worth reading. The Reddit-hot headline is the obvious part: a researcher says the open-source AI wearable platform Omi had seventeen vulnerabilities, including remote code execution, auth bypass, SSRF, path traversal, hardcoded secrets, and unauthenticated access paths touching personal conversation data. Bad enough.

The more useful reading is harsher. Omi is not a boring backend. It is an always-on AI product that promises to listen to conversations, watch screens, and tell users what to do next. When a system like that ships with weak boundaries, the issue is not just bug count. The issue is that the product is built around gathering unusually sensitive data while asking users to trust a fast-moving stack that still looks casual about security.

That is why this post climbed to the top of the conversation in r/netsec today. It is not just another disclosure write-up. It lands on a product category that already makes people uneasy, then adds a public paper trail suggesting the security process itself also needs work.

Why this mattered on Reddit today

Using Reddit's Atom feed, the thread titled "Seventeen vulnerabilities in Omi, fourteen days of silence" showed up at position 5 on r/netsec's hot feed on April 30, with a feed update timestamp of 2026-04-30T11:32:39+00:00.

That is recent enough to matter, and the topic has more substance than the usual launch chatter. It combines three things developers pay attention to:

1. a concrete vulnerability disclosure with technical detail 2. a product that handles intimate user data by design 3. a public response trail that looks messy rather than reassuring

What is actually verified

Here is the part I can verify directly from public records.

1. Omi presents itself as an always-on AI assistant with broad access

The public GitHub repository for BasedHardware/omi describes the project as:

"AI that sees your screen, listens to your conversations and tells you what to do"

The public Omi website also markets it as a note-taking and transcription product. So the disclosure is not about some minor internal tool. It targets a product whose whole pitch depends on users giving it access to speech, context, and workflow data.

2. There is a detailed public disclosure page dated April 29

Researcher Ahmet Kazankaya published Seventeen Vulnerabilities in Omi, Fourteen Days of Silence on April 29.

The write-up claims the original private report was filed on April 15 through GitHub's coordinated disclosure flow and describes a set of issues including:

  • remote code execution via eval() on Redis-backed data paths
  • unauthenticated WebSocket access
  • hardcoded production or development secrets
  • SSRF
  • path traversal in upload handling
  • OAuth CSRF
  • exposure paths affecting personal conversation data

Those are researcher-reported claims, not all independently reproduced here. But the disclosure is detailed, specific, and tied to public repository artifacts rather than vague accusation.

3. A large public remediation pull request existed and was closed without merge

Public GitHub data confirms that PR #6813, titled "Security hardening: RCE, SSRF, IDOR, auth backdoor, firmware keys, replay, XSS, DoS", was opened on April 18 and closed on April 27.

The PR body is not hand-wavy. It lists specific fixes across multiple classes of vulnerability, including:

  • replacing dangerous eval() usage on Redis-backed values
  • adding auth to /v1/trigger/listen
  • removing committed firmware signing and encryption keys
  • adding SSRF protections and URL validation
  • preventing Stripe webhook replay
  • fixing path traversal in upload paths
  • addressing XSS and other input-handling issues

That does not prove every claim in the disclosure is correct. It does prove that a substantial public hardening effort existed, touched the same classes of issues named in the disclosure, and did not get merged.

4. At least one narrower security PR is still open and under review

A second public PR, #6804, titled "fix(security): prevent path traversal in file upload endpoints", remains open.

Its discussion shows something more nuanced than a total blackout. Maintainer comments asked for tests, and follow-up comments added both unit and endpoint-level coverage. That matters because it suggests the public response was not uniformly absent. But it also sharpens the bigger criticism: if narrow fixes can move slowly in public while a broader hardening PR gets closed, users are left guessing which risks are actually being addressed and on what timeline.

5. The repo kept moving during the disclosure window

GitHub's commit API shows at least 500 commits in the repository between April 15 and April 29 alone. That does not prove neglect by itself. Fast-moving projects can work on many things at once.

Still, it supports the broad shape of the researcher's complaint. This was not a frozen repository where nobody was touching anything. Work continued at high speed while the public security picture remained unclear.

What makes this story interesting beyond the headline

The headline is "seventeen vulnerabilities." The deeper issue is that Omi lives in a category where trust boundaries matter more than feature velocity.

If you are building a social app and you miss an access check, that is bad. If you are building an AI wearable and desktop stack designed to hear conversations, watch screens, ingest files, trigger automations, and sit close to user identity, the same miss carries a different weight.

Products like this compress multiple risk domains into one surface:

  • personal audio
  • transcription data
  • user identity and auth state
  • developer plugins and webhooks
  • firmware trust
  • admin tooling
  • third-party model and API integrations

That is why the exact bug list, while important, is not the whole argument. Even if some individual findings turn out to be overstated, the public artifacts already show a system with weak separation between sensitive capabilities.

The closed PR is part of that story. So is the still-open path traversal fix. So is the repo description itself. This is a product asking for broad ambient access. The security bar for that kind of product should be much higher than "we will clean it up later."

Public reaction was predictable, and deserved

The current Reddit traction reflects a familiar security reaction: people are not only judging the bug count, they are judging the kind of product involved.

There is older public discussion around Omi that makes this context useful. In a 2024 Hacker News thread about Omi as an open-source AI wearable, one commenter wrote, "Don't wear one of these near me. I don't want you recording our everyday conversations as a matter of habit." Another discussion in April 2026 about Omi watching screens and hearing conversations drew similarly skeptical replies about privacy and overreach.

Those reactions do not verify the disclosure. They do explain why the disclosure hit a nerve so quickly. Omi was already a trust-heavy product. A messy security paper trail lands differently when the product category already makes bystanders and developers nervous.

What is still uncertain

A few points need careful wording.

  • The disclosure is researcher-authored. The technical claims are detailed, but this post does not independently reproduce all seventeen issues.
  • The claimed GitHub security advisory is not fully public from the API path I checked. The disclosure names GHSA-4j2c-fmg6-8h42, but the public GitHub advisory API did not return a live advisory record during this write-up. That could mean the advisory is still private, restricted, or otherwise not exposed at the public endpoint.
  • Closure does not equal rejection of every fix on the merits. PR #6813 includes automated review feedback flagging at least one backward-compatibility concern in the Redis changes. So the existence of an unmerged PR is not the same thing as proof that every patch was production-ready.
  • The final remediation state is still hard to read from the outside. One narrower PR remains open. The larger hardening PR is closed. The public repo is still moving fast. That combination makes it difficult for outsiders to tell which findings have been fixed, partially fixed, deferred, or disputed.

The practical lesson

The easy version of this story is: AI wearable platform accused of serious bugs.

The better version is: always-on AI products are stacking too much authority behind too few clean boundaries.

Once a product can hear conversations, inspect screens, call webhooks, handle uploads, manage firmware, and impersonate user actions, security mistakes stop being ordinary web bugs. They become failures in how the product defines and limits trust.

That matters beyond Omi.

A lot of the current AI product wave is built on the same instinct: collect more context, wire in more tools, reduce friction, ship quickly. It makes for a compelling demo. It also creates systems where auth shortcuts, exposed keys, permissive webhooks, and sloppy separation between dev and prod have much more room to do damage.

If the Omi disclosure holds up even halfway, the warning is not just "patch these bugs." It is "stop building ambient-access products as if security response can be an afterthought."

That is the part Reddit noticed.

Sources