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.

Ericsson Data Breach: 15,000+ Employee and Customer Records Exposed

A significant data breach has impacted the US subsidiary of telecommunications giant Ericsson. The incident, stemming from a compromised third-party service provider, exposed the personal information of 15,661 employees and customers. This serves as a stark reminder of the risks that lurk within complex supply chains, even for industry leaders.

How the Ericsson Breach Unfolded

The breach didn’t originate within Ericsson’s own digital walls. Instead, attackers targeted a vendor responsible for storing sensitive data on the company’s behalf. The service provider first detected suspicious activity on its systems on April 28, 2025. A subsequent investigation traced the unauthorized access back to a window between April 17 and April 22 of that year.

Ericsson Inc. quickly engaged external cybersecurity experts and alerted the FBI. A meticulous review of the potentially affected files was completed months later, on February 23, confirming the exposure of personal data. The company has chosen not to publicly name the third-party provider at the center of the incident.

What Personal Information Was Compromised?

The scope of the data involved is extensive and deeply personal. For the thousands of affected individuals, the exposed information creates a substantial risk of identity theft and fraud. The compromised files contained a range of sensitive identifiers.

Types of Data Exposed

Names and home addresses were part of the haul, providing a basic profile for each victim. Far more concerning is the exposure of key government-issued identification numbers, including Social Security Numbers and driver’s license details.

The breach also reached into financial and medical privacy. Bank account or payment card numbers were accessible, alongside medical information and dates of birth. This combination of data points is a goldmine for cybercriminals looking to commit synthetic identity fraud.

Response and Protection for Victims

In filings with state authorities, including the Texas Attorney General, Ericsson stated that investigators have found no evidence the stolen data has been misused. The notification to over 4,300 Texas residents is part of a broader effort to inform all impacted parties.

Who is behind the attack? As of now, no cybercrime group has stepped forward to claim responsibility. The silence leaves questions about the attackers’ motives—was this a targeted theft for financial gain, or something else?

To mitigate the potential harm, Ericsson is offering complimentary identity protection services through IDX. Affected individuals who enroll by June 9 will receive credit monitoring, dark web surveillance, and identity theft recovery assistance. The offering includes a significant safety net: a $1 million identity fraud reimbursement policy.

“Please note that our service provider has represented to us that they have no evidence of the misuse of any potentially impacted information since the time of the incident,” Ericsson assured in its notification letter. For the 15,661 people involved, enrolling in those protective services is a crucial next step.

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.