#FactCheck: No, PM Modi Did Not Appear in Royal Attire,Image Is AI-Generated
A photograph showing Prime Minister Narendra Modi holding a trident and dressed in royal attire is being widely shared on social media. Users circulating the image are claiming that it shows PM Modi in a regal outfit.
However, a verification by the Cyber Peace Foundation’s Research Desk has found that the claim is false. The investigation established that the viral image is not authentic and has been generated using Artificial Intelligence (AI).
Claim:
On January 11, 2026, several Instagram users shared the image with captions describing it as a photograph of Prime Minister Modi in royal attire.
Links and archived versions of the posts, along with screenshots, are provided below.
Fact Check:
To verify the claim, relevant keywords such as “PM Modi holding trishul” were searched on Google. This led to a report published by Navbharat Times on January 10, 2025. The report features photographs of Prime Minister Modi holding a trident during his visit to the Somnath Temple. However, in the original images, he is seen wearing normal attire, not royal clothing as shown in the viral image. Link and screenshot
In the next step of the investigation, the original photograph was traced to the official Instagram account of BJP Gujarat, where it was posted on January 11, 2026. The post clearly identifies the image as being from Somnath Temple. Link and screenshot: https://www.instagram.com/p/DTVlb-9Da1V
A close examination of the viral image raised suspicion about digital manipulation. The image was then analysed using the AI detection tool TruthScan. The tool’s assessment indicated a 97 percent likelihood that the image was AI-generated.
Further comparison between the viral image and the original photograph revealed that all visual elements match except the clothing, confirming that the attire was digitally altered using AI tools.
Conclusion
The claim that Prime Minister Narendra Modi appeared in royal attire is false. The Cyber Peace Foundation’s research confirms that the viral image was created using AI by altering the clothing in an original photograph taken during PM Modi’s visit to Somnath Temple. The manipulated image was shared online to mislead users.
Related Blogs
Executive Summary
Amid the ongoing tensions in West Asia between the United States–Israel alliance and Iran since February 28, 2026, a video is rapidly going viral on social media. The clip shows buildings engulfed in flames and thick plumes of smoke following an attack. Several users are sharing it with the claim that it depicts Iran’s recent strike on Tel Aviv, Israel. However, an research by the CyberPeace found the claim to be misleading. The viral video is actually from August 2025, when Israel carried out airstrikes in Sanaa, the capital of Yemen. It has no connection to the current conflict.
Claim:
An Instagram user ‘iran_.news24’ posted the video on March 27, 2026, with the caption: “Iran has turned Israel’s largest city Tel Aviv into hell—fears that 200,000 people have died in the war so far.”
Fact Check
To verify the viral claim, keyframes of the video were extracted and searched using Google Lens. The same video was found posted on August 24, 2025, by a Facebook user ‘Mhmdmhywbalshrby5’. The accompanying text, when translated, stated that it showed Israeli bombardment of Sanaa, Yemen.
Similarly, another Instagram user ‘ae5ce’ had also shared the same video on August 24, 2025, identifying it as footage from Sanaa.
Media reports further support this finding. According to a report published by Egypt Today on August 24, 2025, Israel carried out multiple airstrikes in Sanaa targeting key locations, including an oil station, a power facility, and the presidential palace. Casualties were also reported. The strikes were said to be in response to attacks by Houthi forces.
Additionally, the New York Post shared another video of the same incident from a different angle on its X (formerly Twitter) handle on August 25, 2025.
Conclusion
The video being circulated with the claim of Iran attacking Tel Aviv is actually old footage from Israeli airstrikes in Yemen in August 2025. It is unrelated to the ongoing conflict.
Introduction
Meta has announced that E2EE in Instagram direct messages is ending entirely. Every day, billions of people send messages they consider private. A medical update to a family member. A photograph meant for one person. A conversation they would never have in public. For years, end-to-end encryption (E2EE) was the technology that made that privacy possible: the digital equivalent of a sealed envelope that only the sender and receiver could open. After May 8, 2026, this will change.
Understanding the Adoption Gap
Meta pointed to low user adoption as the reason for this change. Few people were using encrypted messaging on Instagram, the company said, so the feature was not worth keeping. That explanation raises some questions. Encryption was never switched on by default. Users had to find it and turn it on themselves. It was not advertised. And it was only available in certain regions to begin with, something Meta noted on its own Help Centre page. Features that require users to actively seek them out tend to get used far less than those that simply work from the start. WhatsApp demonstrates this clearly; encryption has been on by default since 2016, for every user, with no action required. Back in 2019, Mark Zuckerberg spoke publicly about building privacy into Meta’s messaging platforms as a core direction for the company. The current decision shows a different vision for the company.
The Commercial Dimension
Encrypted message content is not accessible for advertising purposes by design. In December 2025, Meta updated its privacy policy to allow interactions with its Meta AI assistant to inform personalized advertising recommendations across its platforms. With encryption removed from Instagram direct messages, the content of those conversations enters a data environment that already serves Meta’s advertising systems. Meta has not made a direct public statement connecting these two decisions, but technology analysts and privacy researchers have noted the commercial implications of making previously inaccessible message content available within that ecosystem.
What This Means for Users
From May 8, 2026, the content of Instagram direct messages will be accessible to Meta’s systems. This includes messages relating to personal matters that users may have previously sent under the assumption of encryption. A related concern is the question of data security. Unencrypted message content stored on platform servers creates a larger surface area of sensitive information that could be exposed in the event of a security breach. As platforms collect and retain greater volumes of personal data, the potential consequences of unauthorised access grow correspondingly.
But, there is an argument on the other side. Law enforcement agencies and child safety organisations have long maintained that end-to-end encryption limits their ability to detect and act on harmful content. Removing encryption does make certain forms of platform-level content moderation technically feasible where they were not before.
India’s Supreme Court: The Warning Nobody Heeded
India’s Supreme Court said it plainly when hearing the case against Meta’s 2021 WhatsApp privacy policy, which forced hundreds of millions of users to accept data sharing with Facebook or lose access entirely. Chief Justice Surya Kant called it “a decent way of committing theft of private information” and asked how ordinary people could meaningfully consent to policies written in language they cannot understand. He made it human with one line: “A poor woman selling fruits on the streets — will she understand the terms of your policy?” The court ordered Meta not to share a single word of user data until the case is resolved. When Meta’s lawyers argued that encryption protects users anyway, the bench pushed back: encryption protects message content, not the metadata surrounding it. Who you talk to, how often, at what time, from where: all of it is still harvested. The Competition Commission’s own advocate summarised the entire arrangement in four words: “We are the products.”
WhatsApp: A Question Worth Asking
Instagram, Messenger, and WhatsApp are three products inside one ecosystem, owned by Meta, serving one business model. Instagram’s encryption is already gone. Is WhatsApp next in line ?
WhatsApp has over 850 million monthly active users in India alone. People do not use it for entertainment, it is how families talk, how businesses run, how essential daily communication happens. It is infrastructure, not an app. Meta acquired it in 2014 promising no ads, no data exploitation. By 2021 that promise was already bending. By 2025 ads appeared in the Status section. Both original co-founders had long since left the company over exactly these concerns. Instagram’s encryption survived until it conflicted with revenue and regulation. WhatsApp’s encryption exists today under the same ownership, the same business model, and the same tightening global regulatory pressure. That is not a reason to panic. It is a reason to pay attention.
Conclusion
Encryption is not permanent. It is a design choice, and like any design choice, it can be undone when priorities shift. After May 8, 2026, Instagram direct messages will no longer be protected the way they once were. For most users, this change will pass unnoticed. But the data those conversations contain will now be accessible in ways it previously was not. What platforms do with user data is rarely announced loudly. Paying attention to the quiet changes matters.
References
- https://help.instagram.com/491565145294150
- https://www.theguardian.com/technology/2026/mar/18/instagram-to-remove-end-to-end-encryption-for-private-messages-in-may
- https://www.androidpolice.com/why-meta-is-getting-rid-of-e2ee/
- https://digitalpolicyalert.org/change/13307
- https://www.skadden.com/insights/publications/2025/06/take-it-down-act
- https://timesofindia.indiatimes.com/india/you-cant-play-with-right-of-privacy-of-citizens-scs-big-warning-to-whatsapp-meta-over-take-it-or-leave-it-policy/articleshow/127878524.cms#
- https://proton.me/blog/instagram-end-to-end-encryption
- https://www.forbes.com/sites/parmyolson/2018/09/26/exclusive-whatsapp-cofounder-brian-acton-gives-the-inside-story-on-deletefacebook-and-why-he-left-850-million-behind/
Introduction
Web applications are essential in various sectors, including online shopping, social networks, banking, and healthcare systems. However, they also pose numerous security threats, including Cross-Site Scripting (XSS), a client-side code injection vulnerability. XSS attacks exploit the trust relationship between users and websites, allowing them to change web content, steal private information, hijack sessions, and gain full control of user accounts without breaking into the core server. This vulnerability is part of the OWASP Top 10 Web Application Security Risks.
What is Cross-Site Scripting (XSS)?
An XSS attack occurs when an attacker injects client-side scripts into web pages viewed by other users. When users visit the affected pages, their browsers naively execute the inserted scripts. The exploit takes advantage of web applications that allow users to submit content without properly sanitising inputs or encoding outputs. These scripts can cause a wide range of damage, including but not limited to stealing session cookies for session hijacking, redirecting users to malicious sites, logging keystrokes to capture credentials, and altering the DOM to display fake or phishing content.
How Does XSS Work?
- Injection: A malicious user submits code through a website input, like a comment or form.
- Execution: The submitted code runs automatically in the browsers of other users who view the page.
- Exploitation:The attacker can steal session information, capture credentials, redirect users, or modify the page content.
The fundamental cause behind the XSS vulnerabilities is the application of:
- Accepting trusted input from the users.
- After users' input, web pages have the strings embedded without any sanitisation.
- Not abiding by security policies like Content Security Policy (CSP).
With such vulnerabilities, attackers can generate malicious payloads like: <script>alert('XSS');</script>
This code might seem simple, but its execution provides the attacker with the possibility to do the following:
- Copy session tokens through hidden HTTP requests.
- From attacker-controlled domains, load attacker scripts.
- Change the DOM structure to show fake login forms for phishing.
Types of XSS Attacks: XSS (Cross-Site Scripting) attacks can occur in three main variations:
- Stored XSS: This type of attack occurs when an attacker injects an administered payload into the database or a message board. The script then runs whenever a user visits the affected board.
- Reflected XSS: In this attack, the danger lies in a parameter of the URL. Its social engineering techniques are attacks, in which it requires tricking people to click on a specially designed link. For example:
- DOM-Based XSS: This technique injects anything harmful without the need for server-side scripts, in contrast to other approaches. It targets JavaScript client-side scripts such as `document.write` and `innerHTML`. Without carrying out any safety checks, these scripts will alter the page's look (DOM stands for Document Object Model). If the hash is given a malicious string, it is run directly within the browser.
What Makes XSS a Threat?
A Cross-Site Scripting attack is only a primary attack vector, and can lead to significant damage that includes the following:
- Statement Hijacking. This uses scripts to steal cookies, which are then used to pose as authorized users.
- Theft of Credentials. Users’ passwords and usernames are wrenched from keystroke trackers.
- Phishing. Users are prompted with deceitful login forms that are used to capture sensitive details.
- Website Vandalism. Modified website material lowers the esteem of the brand.
- Monetary and Legal Consequences. There are compounding effects to GDPR and DPDP Act compliance in case of Data breaches, which incur penalties and fines.
Incidents in the Real World
In 2021, an XSS Stored attack occurred on a famous e-commerce platform eBay, through their product review system. The malicious JavaScript code was set to trigger every time an infected product page was accessed by customers. This caused a lot of problems, including account takeovers, unauthorised purchases, and damage to the company’s reputation. This example further worsens the fact that even reputed platforms can be targeted by XSS attacks.
How to Prevent XSS?
Addressing XSS vulnerabilities demands attention to detail and coordinated efforts across functions, as illustrated in the steps below:
Input Validation and Output Encoding:
- Ensure input validation is in place on the client and server.
- Perform output encoding relative to context: HTML: <, >, &.
- JavaScript: Escape quotes and slashes
Content Security Policy (CSP): CSP allows scripts to be executed only from the verified sources, which helps diminish the odds of harmful scripts running on your website. For example, the Header in the code could look to some degree like this: Content-Security-Policy: script-src 'self';
Unsafe APIs should be dodged: Avoid the use of document.write(), innerHTML, and eval(), and make sure to use:
- TextContent for inserting text.
- CreateElement() and other DOM creation methods for structured content.
Secure Cookies: Apply the HttpOnly and Secure cookie flags to block JavaScript access.
Framework Protections: Use the protective features in frameworks such as:
- React, which escapes data embedded in JSX automatically.
- Angular, which uses context-aware sanitisation.
Periodic Security Assessment:
- Use DAST tools to test the security posture of an application.
- Perform thorough penetration testing and security-oriented code reviews.
Best Practices for Developers: Assume a Secure Development Lifecycle (SDLC) integrating XSS stoppage at each point.
- Educate developers on OWASP secure coding guidelines.
- Automate scanning for vulnerabilities in CI/CD pipelines.
Conclusion:
To reduce the potential danger of XSS, both developers and companies must be diligent in their safety initiatives, ranging from using Content Security Policies (CSP) to verifying user input. Web applications can shield consumers and the company from the subtle but long-lasting threat of Cross-Site Scripting if security controls are implemented during the web application development stage and regular vulnerability scans are conducted.
References
- https://owasp.org/www-community/attacks/xss/
- https://www.paloaltonetworks.com/cyberpedia/xss-cross-site-scripting
- https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting
- https://www.cloudflare.com/learning/security/threats/cross-site-scripting/
