What happened?
On 19 February 2024, Bitdefender and Wyze jointly disclosed that a caching flaw in Wyze’s camera infrastructure had let users see thumbnails and video snippets from cameras they did not own — roughly 13,000 accounts received glimpses of strangers’ homes between 12 and 16 February while Wyze was migrating its video-pipeline servers. The fix landed fast; the trust question — what does it mean when your doorway camera shows you someone else’s kitchen — took longer.
Quick Answer: A server-side caching bug during a Wyze infrastructure migration mixed users’ event thumbnails and clips across accounts for four days in February 2024, exposing ~13,000 customers’ camera feeds to strangers; it was Wyze’s third major security lapse in a year and renewed scrutiny of cheap-camera cloud architecture.
The mechanics were unglamorous, which is the point. During a migration, some video-event metadata hit a cache that failed to scope by user identity. When customers opened their Events tab, the app fetched what the cache served — sometimes another customer’s motion thumbnail. Not every account saw foreign content; the exposure correlated with active event processing during the window. Wyze’s engineering postmortem framed it as an internal tooling failure (an earlier version of the flaw was visible during debugging), but customers experienced it as: my camera app is showing me a house that isn’t mine.
A pattern, not an incident
February’s flaw landed on a brand already bruised. In 2023, Bitdefender had disclosed an earlier thumbnail flaw — strangers’ images surfacing via a client-side API mix-up — and before that, a 2019-style exposure of users’ database tables through an unsecured Elasticsearch cluster. Two strikes plus an ancestral one is a pattern, not noise. The 2024 incident was smaller in count but larger in symbolism, because it showed the previous disclosures had not been one-off bugs but symptoms — of a product line whose cloud backend had outgrown its original architecture’s safety guarantees.
| Date | Event |
|---|---|
| 2024-02-12 | Server migration begins; cache-mixing window opens on the Events pipeline |
| 2024-02-16 | Bitdefender reports cross-account thumbnails to Wyze; mixing window closes after fix deploys |
| 2024-02-19 | Joint disclosure; ~13,000 affected accounts confirmed; Wyze details three-factor fix |
| 2024-02-20 | Class-action machinery stirs; coverage contrasts Wyze response speed with prior incidents |
| 2024-03 | Wyze promises external security review and re-architecture of the events cache layer |
How the failure stayed invisible until reported
The mixing emerged not from internal dashboards but from Bitdefender’s external research relationship — a humbling origin for a flaw of this sensitivity. Wyze’s telemetry showed healthy caches, healthy latency, healthy error budgets. What it did not show was identity correctness of cache contents. That blind spot is common wherever multi-tenant systems trust their scoping layer without canary probes: nothing looks broken when the failure mode is “right data, wrong owner.” Post-incident, Wyze committed to cross-tenant canaries — synthetic account pairs continuously verifying isolation in production.
Why camera-feed cross-access cuts deeper than data theft
A leaked password can be rotated. A leaked camera feed is a violation that cannot be un-seen — and the victims here were often inside their own homes when the exposure happened. Privacy harm of this category has a different legal and emotional weight: it touches biometric-adjacent space, domestic activity, children’s routines. Regulators — and juries — treat visual intrusions as aggravated harm compared to credential spills.
- Intimacy of the data: interior video defeats assumptions of domestic privacy.
- Irreversibility: recipients of misdirected clips cannot be identified or compelled to delete.
- Persistent fear: victims report lasting re-evaluation of where cameras belong in the home.
- Chilling effect: prospective buyers delay adoption — a market-level cost, not just brand damage.
FAQ
How long were Wyze feeds exposed to strangers?
The confirmed mixing window ran roughly 12 to 16 February 2024, during server migration work. Wyze stated the flaw required an active Events tab session and processed events in the window; ~13,000 accounts had foreign content surfaced, out of millions of users. No continuous live-feed sharing was, per the company, possible through this flaw — thumbnails and short motion clips were the exposure unit.
Was this the same flaw as Wyze’s 2023 camera thumbnail issue?
No — different mechanism, similar symptom. The 2023 issue involved client-side API interactions surfacing others’ thumbnails; the 2024 flaw was a server-side cache-scoping failure during migration. Same product surface failing twice in different ways is precisely why the joint disclosure promised architectural review, not just patch-and-ship.
What should Wyze camera owners do after such incidents?
Practical hygiene: rotate the Wyze account password, enable MFA (supported since 2023’s incidents), review device firmware currency, and treat camera placement as if clips could someday mis-route — because this class of flaw can recur at any vendor. Owners with high-sensitivity placements may reasonably reconsider cloud-dependent event processing altogether.
The disclosure that worked
Credit where due: Wyze and Bitdefender moved from private report to public disclosure in three days, with affected-customer notifications and an engineering postmortem that named the failure mode plainly. Compared to the industry’s median response — quiet fixes and denials until journalists assemble the timeline — the February handling modeled what IoT disclosure should resemble. The reputational damage came from the pattern of repeat incidents, not from the handling of this one.
Lessons for the cheap-camera economy
Wyze built a market by making connected cameras absurdly affordable. The recurring lesson of 2023–2024 is that the cloud backend is where that economics bites: event pipelines, thumbnail caches, and identity scoping are the load-bearing walls of a camera platform, and they must be designed — and load-tested — against cross-tenant failure modes before migrations, not after strangers meet in an Events tab. For buyers, the durable takeaway is to price trust into the sticker: a camera is a cloud service with a lens attached, and its incidents will look like cloud incidents, not camera ones.
Detection and response playbook
The Wyze incident was a two-vulnerability event on the same device: CVE-2024-27957 (thumbnail cross-access via a device-ID guess) and CVE-2024-27959 (event-video access through an unrelated caching layer) — meaning a stranger could see your camera feeds simply by enumerating identifiers. For defenders running any fleet of cheap IoT cameras, the playbook generalizes far past one vendor.
- Treat device enumeration as the attack, because it is. Both flaws required only knowing or guessing a device ID — no authentication bypass wizardry. Any system where knowledge of an internal identifier substitutes for authorization (IDOR-class) is the same vulnerability wearing an IoT costume. Fuzz your own APIs for exactly this: swap IDs between two test accounts and see what renders.
- Monitor for the impossible: events with no owner session. The caching-layer flaw let users fetch event videos outside their account scope. The detection that generalizes: alert when media objects are served with no corresponding authenticated session from the owning identity, or with session/object mismatch. On the vendor side this is table stakes; on your side, it is a reason to demand access logs from IoT vendors before an incident.
- Segment cameras like the adversary they are. Home- and SMB-grade cameras assume cloud trust models that failed here. Enterprise compensating control: cameras live on an isolated VLAN with no lateral movement, egress restricted to the vendor’s documented endpoints — so a feed-disclosure bug does not become a network foothold.
- Apply the firmware-update economics lesson. Wyze pushed a mandatory update within days — good — but the fleet that updated was the fleet that auto-updated. In IoT procurement, write update-enforcement and end-of-support dates into requirements; unpatchable cameras are a liability with a power adapter.
- Prepare for the privacy dimension of disclosure. Cross-user camera access is a different disclosure conversation than “data was accessed”: the material is imagery of private spaces. Legal, comms, and regulatory timelines (this event touched FTC scrutiny of camera vendors) should be pre-mapped for exactly this scenario.
The cheap-camera economy lesson, compressed: you are not buying a camera, you are renting an authorization model designed by a vendor whose incentive is time-to-market. Sometimes the bill arrives as 13,000 strangers with your front-door feed.
Where this sits in the broader pattern
Wyze’s cross-access flaw joined a camera-adjacent incident family that shapes consumer IoT policy to this day: the Ring camera account-takeover cases of 2019 (credential stuffing, then harassment through live feeds), the Verkada incident of 2021 (super-admin access to 150,000 customer cameras from inside a support network), and the Mirai lineage on the device side. The recurring lesson across all of them: once a camera is watching, an authorization failure is a privacy violation with imagery attached — a categorically different harm profile than a data-column leak, and one regulators increasingly treat as such.
The FTC’s subsequent enforcement actions against camera vendors made the compliance dimension explicit: reasonable access controls, timely disclosure, and deletion duties are now legal expectations, not just engineering aspirations. Wyze’s fast mandatory update was widely credited as the right response — but the fact that two independent IDOR-class bugs shipped on the same product line also illustrates how authorization testing lags feature velocity at IoT scale.
For organizations deploying any camera fleet — security cameras, conferencing room devices, body cams — the consolidation is boring and effective: segment the devices, log the access paths, test identifiers for authorization (not just authentication), and write update-enforcement into procurement. The Mirai chapter of the cyberattack history series covers the device-side botnet consequences; this incident covers the privacy-side consequences; the mitigation list is nearly identical, which tells you where to spend.
The bottom line. Thirteen thousand strangers saw through a caching hole because two authorization checks shipped broken on devices people point at their living rooms. The failure was ordinary software engineering; the harm was extraordinary because cameras watch. Segment the fleet, test every identifier for authorization before an attacker does, demand logs and update enforcement from vendors, and treat camera infrastructure with the seriousness of the spaces it observes. The cheap-camera economy will keep shipping these bugs; whether they become your incident is mostly a procurement and segmentation decision.
Frequently Asked Questions
.aiopt-faq-block{border:1px solid var(–aio-border,#e2e8f0);border-radius:8px;overflow:hidden}
.aiopt-faq-item{border-bottom:1px solid var(–aio-border,#e2e8f0)}.aiopt-faq-item:last-child{border-bottom:none}
.aiopt-faq-question{width:100%;text-align:left;padding:16px 20px;background:none;border:none;cursor:pointer;display:flex;justify-content:space-between;align-items:center;font-size:16px;font-weight:600;color:#1e293b;gap:12px}
.aiopt-faq-question:hover{background:#f8fafc}
.aiopt-faq-icon{font-size:20px;transition:transform .2s;flex-shrink:0;color:#6366f1}
.aiopt-faq-open .aiopt-faq-icon{transform:rotate(45deg)}
.aiopt-faq-answer{max-height:0;overflow:hidden;transition:max-height .3s ease}
.aiopt-faq-open .aiopt-faq-answer{max-height:1000px}
.aiopt-faq-answer-inner{padding:0 20px 16px;color:#475569;line-height:1.7;font-size:15px}
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What were the February 2024 Wyze camera vulnerabilities?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “CVE-2024-27957 let an unauthorized user view camera thumbnails by guessing device IDs; CVE-2024-27959 exposed event videos through a caching layer that failed to verify account ownership. Together they allowed strangers to access other users’ camera feeds.”
}
},
{
“@type”: “Question”,
“name”: “How was the Wyze flaw discovered?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Through security research (Bitdefender) and responsible disclosure; Wyze then confirmed, patched, and force-pushed a mandatory app update u2014 an unusually fast, well-handled disclosure by IoT standards.”
}
},
{
“@type”: “Question”,
“name”: “How do you protect camera fleets against IDOR-style access flaws?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Isolate cameras on restricted VLANs, demand per-object authorization logs from vendors, test your own APIs for ID-substitution between accounts, and enforce auto-updates with end-of-support procurement rules.”
}
}
]
}
Related Reading
- What Studying 33 Historic Cyberattacks Taught Me About Defending Systems Today
- Passwordless in 2026: Why Passkeys Are Finally Killing the Password (and How Attackers Are Adapting)
- 2022–2024: Lapsus$, Change Healthcare & the XZ Backdoor
- Authoritative reference: CISA Known Exploited Vulnerabilities
- Verkada Camera Breach: 150,000 Feeds Behind One Credential
- Internet Archive Breach and DDoS: 31M Accounts, One Pop-Up
- Cisco SSM On-Prem Flaws: CVSS 10.0 and a CLI Zero-Day in One Week
