#FactCheck - Misleading Video Allegedly Depicting Trampling of Indian Tri-colour in Kerala or Tamil Nadu Circulates on Social Media

Executive Summary:

A photo that has gone viral on social media alleges that the Indian company Patanjali founded by Yoga Guru Baba Ramdev is selling a product called “Recipe Mix for Beef Biryani”. The image incorporates Ramdev’s name in its promotional package. However, upon looking into the matter, CyberPeace Research Team revealed that the viral image is not genuine. The original image was altered and it has been wrongly claimed which does not even exist. Patanjali is an Indian brand designed for vegetarians and an intervention of Ayurveda. For that reason, the image in context is fake and misleading.

‍

Claims:

An image circulating on social media shows Patanjali selling "Recipe Mix for Beef Biryani”.

‍

Fact Check:

Upon receiving the viral image, the CyberPeace Research Team immediately conducted an in-depth investigation. A reverse image search revealed that the viral image was taken from an unrelated context and digitally altered to be associated with the fabricated packaging of "National Recipe Mix for Biryani". 

The analysis of the image confirmed signs of manipulation. Patanjali, a well-established Indian brand known for its vegetarian products, has no record of producing or promoting a product called “Recipe mix for Beef Biryani”. We also found a similar image with the product specified as “National Biryani” in another online store.

Comparing both photos, we found that there are several differences.

Further examination of Patanjali's product catalog and public information verified that this viral image is part of a deliberate attempt to spread misinformation, likely to damage the reputation of the brand and its founder. The entire claim is based on a falsified image aimed at provoking controversy, and therefore, is categorically false.

Conclusions:

The viral image associating Patanjali and Baba Ramdev with "Recipe mix for Beef Biryani" is entirely fake. This image was deliberately manipulated to spread false information and damage the brand’s reputation. Social media users are encouraged to fact-check before sharing any such claims, as the spread of misinformation can have significant consequences. The CyberPeace Research Team emphasizes the importance of verifying information before circulating it to avoid spreading false narratives.

• Claim: Patanjali and Baba Ramdev endorse "Recipe mix for Beef Biryani"
• Claimed on: X
• Fact Check: Fake & Misleading

‍

Introduction

Recently in July 2026, India's Cyber Crime Coordination Centre (I4C) under the Ministry of Home Affairs quietly tried to do something almost no government has managed before: switch off an app that doesn't need the internet to work.  On July 23, 2026, I4C sent takedown notices to Google, Apple and GitHub, ordering them to pull three offline messaging apps – like BitChat, Briar and Bridgefy – from the Play Store, App Store and GitHub's code repository, respectively, giving a three-hour deadline. The notices followed a period of student-led demonstrations at Jantar Mantar, New Delhi, associated with a group "Cockroach Janata Party," a period that also saw a mobile internet shutdown in parts of central Delhi. When Twitter co-founder Jack Dorsey, who built and open-sourced BitChat, publicised the GitHub notice on X, the episode made international news. Google and Apple got near-identical orders the same night, and telecom operators were reportedly told, and then just as quickly untold, to block the apps at the network level. By July 29, all three apps were still live on both app stores, and BitChat's code was still on GitHub. This incident is worth unpacking carefully, because it sits at the intersection of three things most people care about but rarely see explained together: how this technology actually works, what the law actually allows, and why an app can be "banned" on paper while still working perfectly on your phone.

What makes these apps different

Ordinary apps like WhatsApp or Telegram are centralised: your message travels from your phone to a company's server, and then to the recipient's phone. Block or seize the server, and communication stops. BitChat, Briar and Bridgefy are built differently. They use Bluetooth mesh networking, a system where nearby phones talk directly to each other, and each device also relays messages onwards to phones further away, like a bucket brigade. No message ever touches a central server. Briar adds a further layer by routing traffic over Tor, an anonymity network, when internet access is available, and falls back to Bluetooth or Wi-Fi Direct when it isn't. Bridgefy is tuned for larger crowds, useful during concerts, natural disasters, or protests where thousands of phones are packed into a small area and cellular networks buckle under the load. This design, often called decentralised or peer-to-peer communication, is precisely why these apps are useful during disasters and precisely why they worry law enforcement: they keep working when the internet doesn't, whether that's because a cyclone knocked out cell towers or because the government itself ordered a shutdown.

The legal machinery behind a takedown notice

India's power to block online content mainly comes from Section 69A of the Information Technology Act, 2000, which lets the central government order blocking on grounds like sovereignty, public order or preventing incitement to an offence  but only through a defined process set out in the IT (Blocking) Rules, 2009: a designated officer, a review committee, and recorded written reasons. The Supreme Court examined this exact provision in its landmark 2015 ruling, Shreya Singhal v. Union of India. While the judgement is best remembered for striking down the vague "offensive speech" law under Section 66A, it separately upheld Section 69A specifically because it came with procedural guardrails, a reasoned order, an opportunity to be heard, and the possibility of judicial review that stopped it from becoming an unchecked censorship tool. The July 23 notices, however, reportedly leaned on a different lever: Section 79(3)(b) of the IT Act, read with Rule 3(1)(d) of the IT Intermediary Guidelines and Digital Media Ethics Code Rules, 2021. That provision governs when an intermediary loses its legal immunity ("safe harbour") for user content if it fails to act on a government or court order,  a mechanism built for content takedowns, not necessarily for pulling an entire app off a store shelf within three hours. Legal commentators have flagged this as significant, since Shreya Singhal itself read down Section 79(3)(b) to require action only pursuant to a court order or a properly authorised government direction, not an informal notice. This isn't the first time a mesh-messaging app has run into this machinery. In 2023, following an I4C request, the government blocked Briar and thirteen other apps in Jammu and Kashmir under Section 69A, citing use, the first known instance of Section 69A being used for a regional block. Briar's developers challenged this in the Delhi High Court; in 2024, the court dismissed the challenge, holding that principles of natural justice can give way in matters of national security.

Why you can't easily switch off a mesh network

Here's the technical wrinkle that made the July order largely symbolic: removing an app from the Play Store stops new downloads, but it does nothing to phones that already have it installed, and it does nothing at all to the Bluetooth radios exchanging messages between those phones. Unlike an internet shutdown, which works by controlling the pipes that all traffic must pass through, a mesh network has no chokepoint, no server to seize, no IP address to blacklist, and no single company to compel.

GitHub, for its part, said it followed its standard process of notifying the account holder and offering an appeal before taking any action, which is one reason BitChat's source code stayed publicly accessible throughout. Within a day, officials reportedly told the companies orally that enforcement wasn't necessary after all, though no public clarification or official document has been released explaining why the notices were issued or withdrawn.

Two legitimate, competing interests

None of this means the government's underlying worry is baseless. Law enforcement agencies genuinely lose visibility when communication moves off networks they can lawfully intercept, and coordination of unlawful assembly or violence is a real concern during volatile protests. 

The transparency gap

The single biggest problem with how this played out isn't the underlying concern  it's the absence of a public, reasoned order. Under the blocking rules, disclosure is restricted, and courts, including the Supreme Court in Anuradha Bhasin v. Union of India, have said that when access is restricted, reasons must be recorded and, where possible, made available. A three-hour notice, issued and then informally withdrawn without explanation, sits uneasily with that standard. A more durable approach,  one that CyberPeace and other digital-rights researchers have called for, would combine clearly identified statutory authority; published (even if redacted) reasoning; proportionality review; and investment in lawful digital forensics, rather than blanket app-store takedowns that decentralised technology is, by design, built to survive.

CyberPeace's policy recommendations

Alongside the legal analysis above, CyberPeace puts forward a ten-point framework for how India should approach decentralised communication technologies going forward, instead of defaulting to blanket takedowns:

• Strengthen transparency in blocking decisions
• Ensure statutory clarity
• Apply legality, necessity and proportionality
• Differentiate technology from misuse
• Invest in advanced investigative capabilities
• Establish a multi-stakeholder advisory mechanism
• Develop a framework for emerging decentralised technologies
• Promote responsible innovation
• Enhance public awareness
• Foster international cooperation

‍

Conclusion

The referred incident illustrates that regulating decentralised technologies requires more than swift takedown notices. As communication networks become increasingly resilient and distributed, effective governance must combine legal certainty, technical realism, transparency, and proportionate enforcement. India's challenge is not simply to regulate emerging technologies but to develop a kind of regulatory framework that safeguards national security and the constitutional values of privacy, free expression, and due process.

Sources

• MediaNama — Bitchat was not the only mesh-messaging app targeted by a government takedown notice
• Outlook Business — Beyond GitHub, Govt Also Directed Google To Take Down Bitchat, Briar And Bridgefy
• The Wire — Government Asks GitHub to Remove Bluetooth Messaging App Bitchat Over Concerns of 'Misuse'
• The Tech Trace (Substack) — The Indian govt's crackdown on Bluetooth-enabled messaging apps that wasn't?
• Bar and Bench — Section 69A IT Act and the expanding architecture of digital censorship in India
• Supreme Court Observer — X relies on 'Shreya Singhal' in arbitrary content-blocking case in Karnataka HC
• LiveLaw — Internet Freedom, Shreya Singhal v Union of India, IT Act, Blocking Rules 2009
• Manupatra — Full text, Shreya Singhal v. Union of India (2015) 5 SCC 1
• Open Magazine — CJP Protests at Jantar Mantar: How Offline Mesh Messaging Apps Powered a Network of Resistance

Introduction

‍

Recently, in April 2025, security researchers at Oligo Security exposed a substantial and wide-ranging threat impacting Apple's AirPlay protocol and its use via third-party Software Development Kit (SDK). According to the research, the recently discovered set of vulnerabilities titled "AirBorne" had the potential to enable remote code execution, escape permissions, and leak private data across many different Apple and third-party AirPlay-compatible devices. With well over 2.35 billion active Apple devices globally and tens of millions of third-party products that incorporate the AirPlay SDK, the scope of the problem is enormous. Those wireless-based vulnerabilities pose not only a technical threat but also increasingly an enterprise- and consumer-level security concern.

‍

Understanding AirBorne: What’s at Stake?

‍

AirBorne is the title given to a set of 23 vulnerabilities identified in the AirPlay communication protocol and its related SDK utilised by third-party vendors. Seventeen have been given official CVE designations. The most severe among them permit Remote Code Execution (RCE) with zero or limited user interaction. This provides hackers the ability to penetrate home networks, business environments, and even cars with CarPlay technology onboard.

‍

Types of Vulnerabilities Identified

AirBorne vulnerabilities support a range of attack types, including:

‍

• Zero-Click and One-Click RCE
• Access Control List (ACL) bypass
• User interaction bypass
• Local arbitrary file read
• Sensitive data disclosure
• Man-in-the-middle (MITM) attacks
• Denial of Service (DoS)

‍

Each vulnerability can be used individually or chained together to escalate access and broaden the attack surface.

‍

Remote Code Execution (RCE): Key Attack Scenarios

‍

‍

1. MacOS – Zero-Click RCE (CVE-2025-24252 & CVE-2025-24206) These weaknesses enable attackers to run code on a MacOS system without any user action, as long as the AirPlay receiver is enabled and configured to accept connections from anyone on the same network. The threat of wormable malware propagating via corporate or public Wi-Fi networks is especially concerning.
2. MacOS – One-Click RCE (CVE-2025-24271 & CVE-2025-24137) If AirPlay is set to "Current User," attackers can exploit these CVEs to deploy malicious code with one click by the user. This raises the level of threat in shared office or home networks.
3. AirPlay SDK Devices – Zero-Click RCE (CVE-2025-24132) Third-party speakers and receivers through the AirPlay SDK are particularly susceptible, where exploitation requires no user intervention. Upon compromise, the attackers have the potential to play unauthorised media, turn microphones on, or monitor intimate spaces.
4. CarPlay Devices – RCE Over Wi-Fi, Bluetooth, or USB CVE-2025-24132 also affects CarPlay-enabled systems. Under certain circumstances, the perpetrators around can take advantage of predictable Wi-Fi credentials, intercept Bluetooth PINs, or utilise USB connections to take over dashboard features, which may distract drivers or listen in on in-car conversations.

‍

Other Exploits Beyond RCE

‍

AirBorne also opens the door for:

‍

• Sensitive Information Disclosure: Exposing private logs or user metadata over local networks (CVE-2025-24270).
• Local Arbitrary File Access: Letting attackers read restricted files on a device (CVE-2025-24270 group).
• DoS Attacks: Exploiting NULL pointer dereferences or misformatted data to crash processes like the AirPlay receiver or WindowServer, forcing user logouts or system instability (CVE-2025-24129, CVE-2025-24177, etc.).

‍

How the Attack Works: A Technical Breakdown

‍

AirPlay sends on port 7000 via HTTP and RTSP, typically encoded in Apple's own plist (property list) form. Exploits result from incorrect treatment of these plists, especially when skipping type checking or assuming invalid data will be valid. For instance, CVE-2025-24129 illustrates how a broken plist can produce type confusion to crash or execute code based on configuration.

A hacker must be within the same Wi-Fi network as the targeted device. This connection might be through a hacked laptop, public wireless with shared access, or an insecure corporate connection. Once in proximity, the hacker has the ability to use AirBorne bugs to hijack AirPlay-enabled devices. There, bad code can be released to spy, gain long-term network access, or spread control to other devices on the network, perhaps creating a botnet or stealing critical data.

‍

The Espionage Angle

‍

Most third-party AirPlay-compatible devices, including smart speakers, contain built-in microphones. In theory, that leaves the door open for such devices to become eavesdropping tools. While Oligo did not show a functional exploit for the purposes of espionage, the risk suggests the gravity of the situation.

‍

The CarPlay Risk Factor

‍

Besides smart home appliances, vulnerabilities in AirBorne have also been found for Apple CarPlay by Oligo. Those vulnerabilities, when exploited, may enable attackers to take over an automobile's entertainment system. Fortunately, the attacks would need pairing directly through USB or Bluetooth and are much less practical. Even so, it illustrates how networks of connected components remain at risk in various situations, ranging from residences to automobiles.

‍

How to Protect Yourself and Your Organisation

‍

1. Immediate Actions:

• Update Devices: Ensure all Apple devices and third-party gadgets are upgraded to the latest software version.
• Disable AirPlay Receiver: If AirPlay is not in use, disable it in system settings.
• Restrict AirPlay Access: Use firewalls to block port 7000 from untrusted IPs.
• Set AirPlay to “Current User” to limit network-based attack.

2. Organisational Recommendations:

• Communicate the patch urgency to employees and stakeholders.
• Inventory all AirPlay-enabled hardware, including in meeting rooms and vehicles.
• Isolate vulnerable devices on segmented networks until updated.

‍

Conclusion

‍

The AirBorne vulnerabilities illustrate that even mature systems such as Apple's are not immune from foundational security weaknesses. The extensive deployment of AirPlay across devices, industries, and ecosystems makes these vulnerabilities a systemic threat. Oligo's discovery has served to catalyse immediate response from Apple, but since third-party devices remain vulnerable, responsibility falls to users and organisations to install patches, implement robust configurations, and compartmentalise possible attack surfaces. Effective proactive cybersecurity hygiene, network segmentation, and timely patches are the strongest defences to avoid these kinds of wormable, scalable attacks from becoming large-scale breaches.

‍

References

‍

• https://www.oligo.security/blog/airborne
• https://www.wired.com/story/airborne-airplay-flaws/
• https://thehackernews.com/2025/05/wormable-airplay-flaws-enable-zero.html
• https://www.securityweek.com/airplay-vulnerabilities-expose-apple-devices-to-zero-click-takeover/
• https://www.pcmag.com/news/airborne-flaw-exposes-airplay-devices-to-hacking-how-to-protect-yourself
• https://cyberguy.com/security/hackers-breaking-into-apple-devices-through-airplay/

‍