Security researcher Tal Be'ery has published a fourth method for bypassing WhatsApp's View Once feature — and this time, Meta is declining to issue a patch, arguing the technique falls outside its official security model. For the three billion people who rely on WhatsApp, that answer raises more questions than it settles.
Disclosed on March 18, 2026, and first reported by SecurityWeek, the fourth View Once bypass was identified by Tal Be'ery — CTO of crypto wallet Zengo and a researcher who has spent the better part of two years documenting the structural weaknesses in WhatsApp's ephemeral messaging architecture. Be'ery has now demonstrated, repeatedly and with increasing precision, that View Once is not a privacy feature in any technically meaningful sense. It is, in his words, a promise built on a flag.
What View Once Is Supposed to Do
WhatsApp's View Once feature launched in 2021 and was positioned as a way to share sensitive media — initially photos and videos — with the assurance that the recipient could access them only a single time. According to WhatsApp's official documentation, View Once media cannot be forwarded, shared, copied, or screenshotted. Once opened, the content disappears from the chat. In December 2023, WhatsApp expanded View Once to include voice messages, announcing that audio sent this way would disappear after a single play. The feature was designed to operate exclusively on mobile devices — Android and iOS — where the operating system provides the controls necessary to restrict copying and screen capture. WhatsApp's own documentation also notes that View Once media must be opened within 14 days of being sent, after which it expires from the chat — a detail that underscores the feature's intended ephemerality while also confirming the server-side retention window that researchers would later flag as a design gap.
When a user on WhatsApp Web or a desktop client receives a View Once message, they see a notice that the content can only be opened on a mobile phone. The restriction is intentional: mobile operating systems give WhatsApp the ability to block screenshots and prevent other processes from reading displayed content. On the web, those controls don't exist in the same way. That architectural reality is where the problem begins — and where it has remained, through four disclosed bypasses, for nearly two years.
The Technical Flaw That Keeps Getting Exploited
Be'ery's original September 2024 research, published through his Zengo X research team, exposed the core design issue plainly. View Once messages are not architecturally different from ordinary WhatsApp media messages. They are sent to all of the recipient's linked devices — including web clients — and contain the same components: a URL pointing to encrypted media hosted on WhatsApp's blob store, a decryption key, and a HMAC-SHA256 key for integrity verification. The only thing distinguishing a View Once message from a standard one is a viewOnce field set to true in the message's JSON structure.
Tal Be'ery of Zengo X Research Team described the design as structurally identical to ordinary media messages, differing only in that single flag — comparing the restriction to "putting a note on the picture that says 'don't look'." Setting that flag to false restores the media to a standard, fully shareable attachment. (Be'ery, Medium, September 2024)
The implication is significant: any client that ignores that flag — whether a modified Android app, a browser extension, or an entirely custom-built client — can access the media without restriction. No server-side authentication beyond the decryption key is required. No server-side enforcement prevents a non-standard client from treating a View Once message as regular media. The flag is advisory. It relies entirely on client compliance, and clients can be modified.
Be'ery and his team demonstrated this by building their own WhatsApp client using Baileys, an open-source implementation of the WhatsApp Web API. Linked to a real WhatsApp account in the same way a standard web session would be, their unofficial client downloaded and saved View Once media with no friction. The team also found that View Once media was not deleted from WhatsApp's servers immediately after download — it remained accessible on WhatsApp's blob store servers for up to two weeks. Be'ery's later analysis confirmed that WhatsApp uses Signal's Sesame algorithm to route messages across multiple linked devices, sending the full View Once message — decryption key and all — to every device in the recipient's session set, including web clients. For a feature built around ephemerality, that architectural reality means the media is never truly ephemeral until the server-side retention window closes, and any client in that session can request it before then.
The root failure is not in any individual implementation — it is in the architecture. View Once enforces ephemerality at the client layer, not the server layer. Patching one client surface leaves every other surface open. This is why four separate bypasses have emerged from four different angles: there is no single flaw to close. The constraint is a design choice, and the design choice was wrong.
A History of Bypasses and Inconsistent Responses
The fourth bypass didn't arrive without context. It is the latest in a documented pattern of exploitation that has produced at least four distinct bypass methods since the feature launched, and a disclosure process that has exposed an uncomfortable inconsistency in how Meta decides which vulnerabilities merit a fix.
The first public disclosure came in September 2024 when Be'ery and Zengo went public after discovering that their responsibly disclosed findings — submitted to Meta's Bug Bounty program on August 26, 2024 — were already being exploited in the wild. Browser extensions with thousands of active users were available on the Chrome Web Store, allowing anyone to flip the View Once flag and save the content permanently. TechCrunch confirmed the extensions were functional when tested. One had been available on GitHub for more than a year prior to Be'ery's disclosure.
Be'ery argued that a false sense of privacy is worse than no privacy at all — that leading users to believe their communications are protected when they are not makes a broken feature more dangerous than no feature. View Once, in its current state, should be thoroughly fixed or removed. (Be'ery, Medium, September 2024)
WhatsApp's initial response was a partial client-side patch released in mid-September 2024 that addressed some of the web-based exploits. It was incomplete. Some of the browser extensions that had been exploiting the flaw adapted within days and continued to work. A second, more comprehensive server-side fix followed in mid-November 2024. Be'ery's own analysis pinpoints the deployment window precisely: his team verified the issue was still active on November 12, 2024, then observed users of the exploiting Chrome extension beginning to complain of failures on November 16 — placing the server-side deployment in that narrow window. That update stopped WhatsApp Web from receiving the encrypted media for View Once messages altogether — web clients received only a decryption error when attempting to retrieve the content, consistent with the E2EE error WhatsApp's FAQ associates with missing media keys. It was a more meaningful fix, but it addressed only the web surface. Be'ery presented this research at the Intent Summit on November 19, 2024, by which point the fix had been live for only a few days.
Be'ery documented in a January 2025 follow-up analysis that the November 2024 fix left modified mobile clients entirely unaddressed. A patched Android APK that ignored the viewOnce flag could still receive and save View Once media because the server-side change applied to web companion sessions, not to the underlying API used by mobile clients. That gap has never been formally closed.
A separate iOS-specific vulnerability surfaced in late January 2025, reported by security researcher Ramshath in a Medium post. That flaw allowed a recipient to access View Once media through WhatsApp's internal storage management interface — navigating to Settings, then Storage and Data, then Manage Storage, then sorting by "Newest" — even after the content had supposedly disappeared from the chat. The flaw was specific to iOS and not reproducible on Android. Android Police staff reproduced it internally on January 23, 2025. When Ramshath submitted it through Meta's bug bounty program, Meta's response was telling: the company confirmed it was already aware of the issue internally and was working on a fix, but stated it would not qualify the report for a bounty reward as a result. The flaw was resolved in WhatsApp for iOS version 25.2.3, released at the end of January 2025 — again without any public acknowledgment from Meta. That was the third confirmed bypass in the public record.
The Fourth Bypass and Meta's Decision Not to Patch
The fourth bypass, disclosed March 18, 2026, again involves a modified WhatsApp client — used to intercept and download View Once media before it disappears from the recipient's interface. According to reporting by SecurityWeek, the technique can also be scaled through browser extensions and through WhatsApp Web, reinforcing what Be'ery has argued throughout this research: the architecture itself is the vulnerability, not any single implementation detail that can be patched in isolation.
What distinguishes this disclosure from the previous three is Meta's explicit refusal to patch. The company's stated position is that exploits requiring modified or unofficial client applications fall outside its security model and outside the scope of its bug bounty program. Modified clients and client spoofing are not scenarios the official software is designed to defend against, Meta argues, and the company contends DRM is not an appropriate mitigation for WhatsApp's threat model.
Meta has confirmed it will not patch the fourth View Once bypass. The company's stated rationale is that exploitation requires a modified WhatsApp client — a scenario it considers outside its official security model and bug bounty scope. No specific affected versions have been identified. No active exploitation of this particular method in the wild has been confirmed as of the date of publication.
Be'ery has publicly challenged that position as inconsistent. Earlier View Once bypasses also relied on modified clients — browser extensions and patched Android apps that altered the viewOnce flag. Some of those bypasses were patched by Meta anyway. Some were submitted through the bug bounty program and handled. Meta's current position draws a line that, by Be'ery's account, was not applied consistently in prior disclosure rounds. If the same category of exploit has previously prompted engineering responses and bounty consideration, a sudden determination that it falls outside scope is difficult to reconcile on purely technical grounds.
Why DRM Is the Real Fix — and Why Meta Disagrees
Be'ery has consistently pointed to Digital Rights Management as the architecturally correct solution to View Once's fundamental weakness. Modern Android and iOS platforms both provide DRM frameworks — Android through its DRM API, and iOS through Apple's FairPlay Streaming system. A properly implemented DRM layer would not simply flag media as view-once in a JSON field; it would use hardware-backed controls to enforce that restriction at the decryption and rendering stage, preventing any client — modified or otherwise — from storing or redistributing the content after playback.
A less architecturally complete but more immediately deployable alternative, which Be'ery has also proposed, would be to restrict View Once media delivery to the recipient's primary mobile device only — excluding all companion apps, linked devices, and web clients entirely. This would not address modified mobile clients, but it would eliminate the web and desktop attack surface, which has historically been the easiest vector to exploit.
Proposed Solutions Beyond the Standard Proposals
The DRM and device-restriction proposals are the two that have received the most discussion, but neither is the complete answer. DRM addresses the decryption-layer problem but requires Meta to build and maintain per-platform DRM integrations across Android and iOS — significant engineering investment for a feature that Meta has just declined to patch. Device restriction eliminates the web attack surface but leaves modified mobile clients fully operational. The conversation has stayed at this level for two years without advancing. Several approaches have not been seriously explored:
Server-side single-delivery enforcement. WhatsApp's current architecture transmits the View Once decryption key to every device in the recipient's session set. This is a deliberate design choice inherited from how Signal's Sesame algorithm handles multi-device routing. A direct architectural intervention would change the server's behavior for View Once messages specifically: deliver the decryption key to exactly one device per session, retire it server-side upon confirmed receipt, and refuse to re-serve it. This is not a DRM implementation — it requires no hardware-backed enforcement — but it would make the blob store inaccessible to any second device, linked or otherwise, after the primary delivery is confirmed. It would not stop a modified primary-device client from saving the content before the key is retired, but it would close the multi-device vector that has enabled several of the four disclosed bypasses. The trade-off is degraded multi-device usability: users who receive View Once messages on a secondary linked device would lose access entirely. That is a product decision Meta has avoided, but it is technically implementable without DRM.
Client attestation via Play Integrity and DeviceCheck. Android's Play Integrity API and Apple's DeviceCheck framework both allow a server to verify, at request time, that the client application is an official, unmodified build running on a legitimate device. WhatsApp already operates on both platforms and has access to both APIs. If the server required a valid Play Integrity or DeviceCheck attestation token before serving View Once media, a modified APK or a custom Baileys-based client — which cannot produce a valid attestation token — would receive a refused delivery rather than the decryption key. This does not address all threat scenarios: rooted devices and certain emulators can generate fraudulent attestation responses, and this protection has been bypassed at the system level for other applications. Separately, OAuth redirect-based authentication bypasses demonstrate how client-trust assumptions can be exploited at a different layer of the stack. Attestation enforcement would raise the floor significantly against the casual and semi-sophisticated attacker, including the browser extension and modified client scenarios that have produced three of the four disclosed bypasses. No jailbreak or root exploit is required to run a modified APK on an unrooted device — attestation enforcement would close that pathway specifically.
Reduced server-side retention window. View Once media currently remains accessible on WhatsApp's blob store servers for up to two weeks after download. That retention window exists because WhatsApp must accommodate devices that are offline at delivery time — the content needs to remain available for delayed delivery. But two weeks is a generous window relative to the feature's stated purpose. A shorter server-side expiry — set, for example, to 24 or 48 hours after confirmed receipt by the intended device — would reduce the period during which the URL and decryption key remain usable to an attacker who intercepts them from a linked device. This does not address real-time interception at the moment of receipt, but it eliminates a secondary exploit window: an attacker who links a device after the fact, or who obtains the message data through a delayed synchronization, would find the media already expired on the server. It is a limited mitigation, not a fix, but it could be implemented as a server-side configuration change without any client modification.
Transparent feature labeling and disclosure. This is the solution that requires no engineering at all — only product honesty. WhatsApp's current marketing language for View Once presents the feature as a mechanism for sending media that cannot be saved, forwarded, or kept. That description is not technically accurate and has not been accurate since launch. A labeling change — reframing View Once as a convenience feature that limits casual access rather than technically preventing determined access — would not fix the underlying architecture, but it would stop actively misleading users about the protection the feature provides. Regulatory pressure under consumer protection frameworks in the EU and the UK creates a mechanism for this outcome if Meta does not pursue it voluntarily. The Digital Markets Act and existing GDPR enforcement channels both create potential pathways for a data protection authority to examine the gap between a feature's described functionality and its actual behavior. Whether any authority will act on that pathway in the View Once context is unknown. The option exists.
Meta's counter-argument, per SecurityWeek's reporting, is that DRM does not prevent analog recording: a determined attacker can simply point a second camera at the screen and capture the View Once content that way. That argument is technically accurate. But it substantially reframes the risk. Be'ery addressed this exact counterargument in his original September 2024 research, drawing a direct comparison between analog copying and digital replication — and the difference is not merely one of convenience:
Be'ery countered that analog workarounds and digital bypasses operate at entirely different scales — drawing an analogy to the gap between copying cassettes and distributing MP3 files. The differences in quality, speed, reach, and attribution are not incremental. They are categorical. (Be'ery, Medium, September 2024)
The analog-is-still-possible argument does not address what makes digital bypasses categorically more threatening: scale, speed, and perfect reproduction. A browser extension or modified client that bypasses View Once does not require physical proximity. It does not require the attacker to be watching the screen in real time. It operates silently and automatically on every View Once message a recipient receives, producing an exact digital replica instantly, without any degradation in quality and without leaving any fingerprints that distinguish the copy from the original. That is a fundamentally different threat surface than someone holding a second phone up to a screen.
Who View Once Was Built For — and Who Is Actually Using It
Coverage of the View Once vulnerability cycle has focused almost entirely on the technical mechanism — the flag, the blob store, the modified client. That framing is accurate, but it sidesteps a question that matters for understanding the real stakes: who is sending View Once messages, and what are they sending?
WhatsApp's marketing language around View Once is pitched at a general audience sharing passwords, bank details, or personal photos they don't want lingering in someone else's camera roll. That is a real and reasonable use case. But the platform's user base is not a homogeneous group of people sharing casual sensitive information. WhatsApp dominates messaging in markets where it functions as the primary or sole digital communication channel for hundreds of millions of people. In India, Brazil, Nigeria, Indonesia, and across much of the Global South, WhatsApp is not a lifestyle choice — it is the infrastructure. View Once, in those contexts, is being used by people whose threat model is not a curious colleague but an abusive partner, a hostile government, a stalker, or a network of bad actors operating at scale.
The intimate partner surveillance use case is not theoretical. Research on technology-facilitated coercive control has documented how messaging platforms — WhatsApp specifically — are routinely weaponized by abusive partners to monitor communication, identify contacts, and control behavior. A View Once feature that actually worked as advertised would provide meaningful protection for survivors of intimate partner violence who need to communicate privately, receive support resources, or document their own situation without their abuser gaining access to that communication. A View Once feature that can be bypassed by anyone with a modified client and a willingness to run it provides no protection at all — and may actively worsen the situation by creating a false sense of security where none exists.
Meta's framing treats "requires a technical recipient" as a meaningful constraint. It is not — for the users who face the highest consequences. Intimate partner abuse, state surveillance, and organized harassment are not random events. They are patterns of sustained, targeted behavior by actors with both motivation and access to the tools that remove the technical barrier entirely. Browser extensions exploiting View Once were available on the Chrome Web Store with a single search. The constraint matters for the median user. It does not protect those at greatest risk.
The same applies to journalists operating in environments where their sources rely on ephemeral media to communicate safely, to LGBTQ+ individuals in jurisdictions where their communications carry legal risk, and to activists and dissidents for whom a saved View Once message is not a privacy inconvenience but a potential physical danger. These users exist on WhatsApp in significant numbers. The feature's failure is not evenly distributed across its three billion users. It is concentrated in exactly the populations for whom the gap between the promise and the implementation carries the highest cost.
Meta's framing — that the practical risk is limited because exploitation requires a technically capable recipient running a modified client — does not account for the structured nature of the highest-risk contexts. Intimate partner abuse, state surveillance, and organized harassment are not random events visited on random users by random technically-capable strangers. They are patterns of targeted, sustained behavior by people with both the motivation and, increasingly, the access to tools that remove the technical barrier entirely. Browser extensions that bypassed View Once were available to thousands of users with a single Chrome Web Store search. Modified APKs circulate in forums and Telegram channels without meaningful friction. The "it requires a technical recipient" constraint matters for the median user. It matters considerably less for the users at highest risk.
Fix It, Label It, or Remove It
Be'ery's original September 2024 research concluded with a direct challenge: WhatsApp's View Once is a form of false privacy, and it should either be thoroughly fixed or abandoned. After four bypass disclosures, two years, and Meta's explicit decision not to patch the latest known method, that fork in the road has not been resolved. A third path has emerged in practice: leave the feature in its current state, maintain its marketing language, and manage disclosure pressure on a case-by-case basis.
That third path has a significant problem. Shipping a feature under the name "View Once" with marketing copy that describes it as protecting sensitive media from being forwarded, copied, or saved — when any client that ignores a single JSON flag can do all three — is a product honesty question, not just a security question. The question the disclosure cycle has not pressed directly is: at what point does the gap between how a feature is described and how it actually works become something that regulators or consumer protection frameworks should examine?
In the European Union, that question is not entirely hypothetical. WhatsApp operates under GDPR across the EU, and the regulation's data minimization principle under Article 5 applies to personal data processed by the platform. View Once media transmitted and then retained on WhatsApp's blob store servers for up to two weeks — decryption keys and all, routed to all linked devices — raises a question about whether that retention is consistent with processing the minimum data necessary for the stated purpose. The stated purpose is a message that disappears after one viewing. The technical reality is a message that persists, accessible on Meta's infrastructure, for up to 336 hours. The Irish Data Protection Commission has been the lead EU supervisory authority for WhatsApp's GDPR compliance matters. Whether View Once's server-side retention window has drawn any formal scrutiny is not publicly known. Whether it should is a question the existing disclosure record raises clearly.
The "remove it entirely" option has not been seriously discussed in any of the four disclosure rounds. Be'ery raised it as one of two possibilities in 2024 and it has not been picked up in subsequent coverage. It deserves consideration. A feature that cannot be technically enforced, that has been bypassed four times in under two years, and that Meta has now explicitly declined to patch, is a feature that may do more harm than good if its primary function is to make users feel safer than they are. Removing it would be a significant product decision for a platform with three billion users who have come to rely on it as a privacy control. But it is a more honest outcome than maintaining a feature under false pretenses. If Meta cannot or will not implement DRM, and if the modified client vector is permanently outside its security model, the choice is between fixing the architecture and withdrawing the promise — not between fixing the architecture and continuing to make the promise anyway.
What This Means for Users Right Now
The practical privacy situation for View Once has not changed significantly as a result of this fourth disclosure. The feature has never provided robust technical enforcement of its stated guarantees. What has changed is that Meta has now explicitly stated it will not close the remaining gap — at least the one that is currently documented. No active exploitation of this specific fourth method has been confirmed in the wild as of March 18, 2026. Exploitation requires a recipient who is running a modified WhatsApp client. That is a meaningful practical constraint.
However, the pattern across four separate disclosures tells a consistent story. View Once media sent over WhatsApp is delivered as standard encrypted media differentiated only by a flag. That media persists on WhatsApp's servers for up to two weeks after download. It is routed to all of a recipient's linked devices. And any client that ignores the flag can access and save that media without restriction, additional authentication, or server-side intervention. The gap between the feature's branding and its actual technical enforcement has been documented, partially patched, and re-exploited multiple times.
The metadata dimension adds a layer of concern that rarely receives adequate attention in View Once coverage. WhatsApp's end-to-end encryption protects message content from third-party interception. But metadata — the fact that a sender dispatched a View Once message to a specific recipient at a specific timestamp — is visible to WhatsApp's servers. Be'ery's January 2025 follow-up analysis highlighted this explicitly. Even if the content of a View Once message is shielded from server-side inspection, the behavioral signal that a particular person sent time-sensitive private media in the early hours of the morning is information the server can observe, retain, and potentially act upon.
WhatsApp's consistent public guidance throughout this disclosure cycle has been to send View Once messages only to people users know and trust. That guidance places the security burden entirely on the social relationship between sender and recipient rather than on technical enforcement. It is not wrong advice. But it is also not a substitute for the architecture that the feature's marketing implies exists beneath it.
For users whose threat model requires that private media remain genuinely ephemeral and technically unrecoverable, WhatsApp's View Once feature does not meet that bar today. Purpose-built secure messaging applications with more rigorously enforced disappearing message implementations offer stronger guarantees for high-sensitivity use cases. Signal and WhatsApp have both been targeted by state-sponsored phishing campaigns, which underscores why the gap between claimed and actual security properties matters. Signal is the comparison point that comes up in every serious discussion of this gap, but the specific reasons why are worth stating directly rather than leaving implied. Signal's disappearing message timer starts after the recipient reads the message, not after it is sent — meaning the window is based on actual delivery, not assumed delivery. Signal collects minimal metadata by design: it does not retain information about who you communicate with, when, or in what pattern beyond the last-login timestamp. Its sealed sender architecture is specifically engineered to obscure message routing metadata from Signal's own servers. And Signal's codebase is open-source, meaning its enforcement claims can be independently verified by the security community rather than taken on the company's word. None of this makes Signal impervious to a recipient who photographs their screen or uses forensic extraction tools with device access. No platform is. But the structural difference between a platform that enforces ephemerality at the protocol layer with minimal metadata retention and one that enforces it with a client-side flag while retaining media server-side for two weeks is not a difference of degree — it is a difference of architecture. For users with genuine high-stakes privacy requirements, that distinction is the relevant variable.
Key Takeaways
- The flaw is architectural, not incidental: View Once relies on a client-side flag rather than server-side enforcement or hardware-backed DRM. Any client that ignores the flag can bypass the feature. This has been true since launch and has not been resolved by any patch issued to date.
- Meta will not patch the fourth bypass: The company's position is that exploits requiring modified clients fall outside its security model and bug bounty scope. Be'ery has challenged that stance as inconsistent with how prior modified-client bypasses were handled, some of which were patched and at least reviewed for bounty eligibility.
- The bug bounty process has been used inconsistently as a gatekeeper: Researcher Ramshath, who discovered the iOS-specific third bypass, was denied a bug bounty reward because Meta said it was already aware of the issue internally. This is a documented practice: reporting a valid, unpatched vulnerability through proper channels does not guarantee eligibility if Meta claims prior internal awareness — even when the issue has not been publicly disclosed or fixed. Be'ery received a bounty for one of his prior View Once bypass disclosures, but Meta has now declared the fourth falls entirely outside bounty scope. The pattern across multiple researchers and multiple rounds suggests the bounty program has not functioned as a consistent incentive for responsible disclosure in the View Once case.
- DRM is the technically sound fix; Meta disagrees on proportionality: Be'ery has proposed hardware-backed DRM as the only solution that addresses the root cause. Meta argues DRM does not prevent analog recording and is not suited to WhatsApp's threat model. The disagreement reflects a substantive difference in what View Once is designed to guarantee and for whom.
- Metadata exposure persists regardless of content protection: Even when View Once content is protected, the behavioral metadata around the message — sender, recipient, timing, message type — remains visible to WhatsApp's servers. This is a separate and under-discussed risk for users with sensitive communications.
- Trust is the primary control for now: No active exploitation of the fourth bypass in the wild has been confirmed. The practical mitigation for regular users is limiting View Once usage to recipients they trust completely and recognizing that the feature does not provide technical guarantees against a determined, technically capable recipient.
- The "modified client" barrier is not a meaningful constraint for high-risk users: Meta's position treats the technical requirement of a modified client as a practical limit on exploitation. That framing does not hold for the users most exposed to harm — those in domestic abuse situations, journalists with targeted sources, or individuals in jurisdictions where their communications carry legal risk. For these users, the tools needed to exploit View Once are not difficult to acquire, and the consequences of a bypass are not inconvenient but dangerous.
- Meta has not been asked to choose between fixing it and withdrawing it: Four disclosure rounds have produced incremental patches and an eventual refusal to patch. The direct question — whether a feature that cannot be technically enforced should carry different marketing language, a disclosure, or be removed — has not been formally pressed. It is the question that follows logically from the pattern of disclosures, and it remains open.
The broader significance of this four-disclosure cycle is not simply that View Once has a bug. It is that WhatsApp shipped a privacy feature whose marketing outpaced its implementation — and that after nearly two years of disclosures, partial patches, and sustained researcher pressure, the fundamental architectural problem remains open. Whether that changes with a fifth bypass, a regulatory inquiry in any of the jurisdictions where WhatsApp dominates as a communication platform, or a shift in Meta's engineering priorities is an open question. For now, View Once is best understood not as a technical guarantee but as a social signal: a declaration of intent between sender and recipient, enforced by trust rather than by code.
Sources: SecurityWeek (March 2026) · Tal Be'ery, Medium (September 2024) · Tal Be'ery, Medium — Initial Fix Assessment (September 2024) · Tal Be'ery, Medium — Fix Analysis and Metadata (January 2025) · Ramshath, Medium — iOS Bypass Discovery (January 2025) · TechCrunch (September 2024) · TechCrunch — Fix Confirmed (December 2024) · BleepingComputer · The Register · Android Police · MacRumors — iOS Fix (January 2025) · Cybernews — Server Retention Analysis (September 2024) · WhatsApp Blog — View Once Voice Messages (December 2023) · WhatsApp FAQ — View Once Documentation