The LeakyLooker Vulnerabilities in Google’s Analytics Platform

Imagine a business intelligence tool designed to visualize data becoming a backdoor to the cloud itself. That was the startling reality uncovered by Tenable Research, which identified a cluster of nine security flaws in Google Looker Studio. Dubbed ‘LeakyLooker,’ these cross-tenant vulnerabilities resided in the platform formerly known as Google Data Studio.

Looker Studio is a popular service for creating dashboards and reports. It pulls data from sources like Google BigQuery, Sheets, and other SQL databases. This deep integration with Google’s cloud infrastructure, however, painted an unexpectedly large target for attackers. The platform’s architecture inadvertently created a broad attack surface where a single compromised report could have far-reaching consequences.

Two Paths to Exploitation: Zero-Click and One-Click Attacks

Tenable’s investigation pinpointed weaknesses in the platform’s authentication and data connector systems. The core issue? Looker Studio can run queries using either the report creator’s credentials or the viewer’s credentials. This design flaw opened up two distinct avenues for malicious activity.

The first path required no user interaction. In a ‘0-click’ attack, a threat actor could craft server-side requests that triggered SQL queries executed with the report owner’s high-level permissions. No button click needed; the damage could be done remotely.

The second method was a ‘1-click’ attack. Here, a victim only needed to open a manipulated report or a malicious link. Upon viewing it, malicious SQL queries would run using the viewer’s own database credentials, potentially compromising their data.

Underlying Flaws That Enabled the Attacks

These attack techniques were powered by several critical underlying issues. Researchers found SQL injection flaws in the platform’s database connectors. Sensitive data could also leak through seemingly benign report elements like hyperlinks or embedded images. A particularly concerning flaw, dubbed a ‘denial-of-wallet’ issue, could have allowed attackers to run up massive bills on a victim’s BigQuery resources.

Potential Impact and the Path to Remediation

The scope was significant. Connectors for BigQuery, Cloud Spanner, PostgreSQL, MySQL, Google Sheets, and Cloud Storage were all affected. An attacker could have scoured the web for publicly shared Looker reports. These reports could then serve as a launchpad to steal data, insert false records, or even delete entire tables in connected databases.

One subtle but dangerous feature was the report copy function. When a viewer duplicated a report, it sometimes preserved the original database credentials. The new owner of the copied report could then run custom SQL queries against the original database, all without ever knowing the password.

Tenable responsibly disclosed all nine vulnerabilities to Google. The tech giant collaborated with the researchers to investigate and roll out fixes. Since Looker Studio is a fully managed service, Google deployed the patches globally. Customers did not need to take any action to be protected.

Securing Your Business Intelligence Front

This episode serves as a crucial reminder. Analytics and business intelligence platforms are often overlooked in security assessments. They are powerful tools that connect directly to crown-jewel data stores, making them attractive targets.

Organizations should proactively manage this risk. Regularly audit report-sharing settings and ensure only necessary individuals have access. Limit or remove unused data connectors to shrink the attack surface. Most importantly, treat BI and analytics integrations as a core component of your cloud security strategy, not an afterthought. The line between data visualization and data vulnerability can be thinner than it appears.

Russian Hackers Target WhatsApp and Signal in Global Espionage Campaign

A sophisticated Russian espionage operation is systematically hijacking accounts on encrypted messaging platforms. Dutch intelligence services have exposed a global campaign where state-backed hackers are targeting government employees, military personnel, and journalists.

The goal is simple: bypass the end-to-end encryption of Signal and WhatsApp by stealing the accounts themselves. Once inside, attackers can read private conversations and impersonate trusted contacts.

How the Russian Account Hijacking Works

The attacks are clever and multi-pronged. One primary method involves impersonation. Hackers send messages pretending to be a ‘Signal Support’ chatbot. The message claims suspicious activity on the user’s account and urgently requests their SMS verification code or Signal PIN.

Signal has been unequivocal in its warning. “Signal Support will *never* initiate contact to ask for your verification code or PIN,” the company stated. If anyone asks for these codes, it is definitively a scam.

Another technique exploits the ‘linked devices’ feature. Attackers trick victims into scanning a malicious QR code or clicking a link, which grants the hacker access to the messaging account from their own device. This method was previously used against Ukrainian officials.

Why Encrypted Apps Are Still Vulnerable

End-to-end encryption protects message content in transit, but it cannot protect against account takeover. If a hacker gains control of your account, they effectively become you within the app. They see all your messages and can communicate with your contacts.

“Despite their end-to-end encryption option, messaging apps such as Signal and WhatsApp should not be used as channels for classified, confidential or sensitive information,” warned Vice-Admiral Peter Reesink, director of the Dutch Military Intelligence and Security Service (MIVD).

Security experts note a fundamental mismatch. “Third party consumer-oriented platforms like Signal and WhatsApp are ultimately not developed with state-level usage in mind,” explained Ben Clarke, SOC manager at CybaVerse. They lack the stringent protocols of bespoke government systems, making them attractive targets for well-resourced nation-state actors.

How to Spot and Stop an Account Takeover

Dutch intelligence (AIVD and MIVD) has published clear guidance for high-risk users. Vigilance within group chats is critical. Check if any contact appears twice in your group member list—this duplication could signal a malicious actor has cloned an account.

If you see this, contact the group administrator. They should remove both identical-looking accounts, allowing the legitimate user to request re-entry. Also, watch for sudden display name changes, like a contact’s name switching to ‘Deleted Account.’ A notification of such a change is a major red flag.

The core defense is simple: never, under any circumstances, share your SMS verification code or app-specific PIN with anyone. No legitimate support service will ever ask for them.

This campaign is a stark reminder. The strongest lock is useless if someone steals your key. For sensitive communications, the platform’s trustworthiness is just as important as its encryption.

The New Front Door for Cloud Attacks

For years, the story was simple. Attackers wanted your passwords. They phished for credentials, hunted for misconfigured access, and relied on human error to slip into cloud environments. That story has changed dramatically. According to Google Cloud’s latest threat intelligence, the playbook has been rewritten.

The data from the second half of 2025 reveals a startling pivot. Threat actors are now overwhelmingly choosing a different path of least resistance. Instead of trying to steal a key, they’re kicking down the door by exploiting known but unpatched software flaws. This isn’t a minor trend—it’s a fundamental shift in how cloud infrastructure is being targeted.

By the Numbers: A Dramatic Reversal

The statistics tell a clear story of evolution under pressure. In the first half of 2025, exploiting third-party software vulnerabilities was a minor tactic, accounting for just 2.9% of initial access incidents. By the second half of the year, that figure had skyrocketed to 44.5%. It became the dominant attack vector almost overnight.

Conversely, the abuse of weak or missing credentials—long the staple of cloud breaches—plummeted from 47.1% down to 27.2% over the same period. Attackers are rational. They follow the path of greatest reward for the least effort. Right now, that path leads straight through unpatched applications and permissive firewall rules that organizations have left open.

The Poster Child: React2Shell

One vulnerability exemplifies this new era: CVE-2025-55182, known as React2Shell. This critical flaw in React Server Components allows remote code execution. Think of it as a digital skeleton key for servers. Attackers linked to nation-state groups from North Korea and China were among those who weaponized it, but they weren’t alone.

What makes React2Shell particularly telling is the speed of its weaponization. Within a mere 48 hours of its public disclosure in December 2025, multiple criminal groups had already exploited it to install cryptocurrency mining malware on victim systems. It wasn’t a targeted espionage tool for weeks; it was a commodity exploit in days.

The Collapsing Window for Defense

This speed is the core of the new challenge. Google Cloud reports that the window between a vulnerability being disclosed and it being mass-exploited has collapsed “by an order of magnitude.” We’ve moved from having weeks to patch, to having just days. Sometimes, only hours.

If your organization’s patching cycle is measured in weeks or months, you are operating on borrowed time. Your cloud services are functionally vulnerable from the moment a critical flaw is announced until your patch is deployed. Attackers have automated their exploitation pipelines. Defense can no longer be a manual, slow-moving process.

Building a Modern Cloud Defense

So, what’s the answer? The strategy must evolve as quickly as the threat. Relying solely on manual patching is a recipe for failure. Google’s advice is to pivot toward automated, proactive defenses that can act at the speed of the attack.

One key recommendation is to use Web Application Firewalls (WAF) with automated rule updates. These can neutralize exploit attempts at the network edge, buying crucial time to deploy the actual software patch. It’s a stopgap, but a vital one. Centralized visibility tools are also non-negotiable. You can’t defend what you can’t see. Knowing exactly what’s running in your environment, and its patch status, is the first step to closing these digital doors.

Finally, don’t abandon identity controls. While they’re no longer the primary entry point, strong access management remains essential for limiting an attacker’s movement *after* they breach your perimeter. The goal is to build layers of defense that assume a breach will occur and work to contain it. The cloud threat landscape has shifted. Our defenses must do the same.