Stable Channel Update for Desktop

The Stable channel has been updated to 138.0.7204.168/.169 for Windows, Mac and 138.0.7204.168 for Linux which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log.

Security Fixes and Rewards

Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.


This update includes 3 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.


[$8000][430344952] High CVE-2025-8010: Type Confusion in V8. Reported by Shaheen Fazim on 2025-07-09

[TBD][430572435] High CVE-2025-8011: Type Confusion in V8. Reported by Shaheen Fazim on 2025-07-09


We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

As usual, our ongoing internal security work was responsible for a wide range of fixes:
[433331098] Various fixes from internal audits, fuzzing and other initiatives

Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.

Interested in switching release channels? Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista
Google Chrome

Increased flexibility for Google Ads API conversion imports

Starting on October 3, 2025, you will be able to set both the gclid and gbraid fields on your ClickConversion messages when importing them to the Google Ads API, by using the UploadClickConversions method.

Previously, setting both of these fields resulted in the following partial failure error:

Once this change is released, this error will no longer be returned. Instead you will see successful import responses.

- Ben Karl, on behalf of the Google Ads API Team

2025 Scholar Metrics Released


Scholar Metrics provide an easy way for authors to quickly gauge the visibility and influence of recent articles in scholarly publications. Today, we are releasing the 2025 version of Scholar Metrics. This release covers articles published in 2020–2024 and includes citations from all articles that were indexed in Google Scholar as of July 2025

Scholar Metrics include journals from websites that follow our inclusion guidelines and selected conferences in Engineering & Computer Science. Publications with fewer than 100 articles in 2020-2024, or publications that received no citations over these years are not included.

You can browse publications in categories such as Medical Informatics, Public Policy & Administration or Accounting & Taxation. You will see the top 20 publications ordered by their five-year h-index and h-median metrics. You also can browse the top 100 publications in several languages - for example, Portuguese and Spanish. For each publication, you can view the top papers by clicking on the h5-index.

Scholar Metrics include a large number of publications beyond those listed on the per-category and per-language pages. You can find these by typing words from the title in the search box, e.g., [bilingual], [geoinformation], [salud publica].

For more details, see the Scholar Metrics help page.

Posted by: Anurag Acharya

Stop Leaked Credentials in Their Tracks with Veles, Our New Open-Source Secret Scanner

Stop Leaked Credentials in Their Tracks with Veles, Our New Open-Source Secret Scanner

by Kevin Dungs, Charl de Nysschen & Sarah Lucas, Google

In today's complex software supply chain, a single leaked credential—an API key, a service account token, a password—can be all an attacker needs to breach your systems. These secrets can be accidentally committed to a source code repository, embedded in a container image, or attached to a support ticket, creating a critical and often invisible risk.

To help developers and security teams proactively find and fix these exposures, we are excited to announce Veles, a new open-source secret and credential scanner from Google.

Veles is designed to detect unintended exposure of sensitive credentials across your organization's internal systems. It helps you find secrets where they don't belong, so you can prevent them from being abused.

Why Veles? Key Features

Veles is a new, standalone module within our OSV-SCALIBR (Software Composition Analysis LIBRary) ecosystem, but it is built to be used independently. This means you can easily integrate it into your existing security tooling or use it as a standalone scanner.

In its initial release, Veles helps you find high-risk secrets in source code and user-provided artifacts. Our detection library currently identifies:

  • Google Cloud Platform (GCP) API Keys
  • GCP Service Account Keys
  • RubyGems API Keys

This is just the beginning. Veles is built to be extensible, allowing for the rapid addition of new secret types.

Battle-Tested at Google: Powerful Real-World Integration

At Google, we're not just releasing Veles; we're actively using it to protect our own systems and the open-source ecosystem.

  • Internal Protection: Veles is already scanning Google's internal source code repositories and artifacts, helping us find and remediate leaked secrets before they become a problem.
  • Securing the Open Source Ecosystem: The Google Open Source Security Team is incorporating Veles into its pipeline that powers deps.dev, scanning hundreds of millions of open-source artifacts (packages, Docker images, and repositories) to detect and remediate leaked credentials across the community.
  • Integration with Google Cloud Products: Veles is being integrated directly into Google Cloud security services to bring secret scanning to our customers:
    • Artifact Analysis & Artifact Registry: Veles will power secret scanning in Artifact Registry, with findings surfaced through the Container Analysis API and, eventually, in the Artifact Registry UI.
    • Security Command Center (SCC): SCC's integration will provide comprehensive secret detection across the entire cloud lifecycle. This means scanning "left" into the development pipeline (like Infrastructure as Code) and "right" into active runtime environments (like Compute Engine and GKE). SCC will then unify these findings, helping you prioritize the most critical exposures and visualize potential attack paths.

The Road Ahead: What's Next for Veles?

This first release is a foundational step. Our roadmap for Veles includes:

  • Broader Detection: We will continuously expand the library of supported secret and credential types.
  • Automated Validation: We plan to add functionality to intelligently validate if a discovered secret is active.
  • Remediation Workflows: In the future, we aim to help automate the revocation of confirmed, leaked secrets.

Get Started with Veles Today

Veles is open-source and ready for you to use. You can integrate it into your CI/CD pipeline, run it against your existing repositories, or contribute to its development. Protecting your organization from leaked credentials is a critical part of a strong security posture, and Veles is here to help.

Ready to start scanning? Head over to the Veles GitHub repository to get started!

Thumbnail previews will now show on video progress bar in Google Drive

What’s changing 

Starting today, when hovering over a newly uploaded video’s progress bar in Google Drive, you’ll see a thumbnail preview that allows you to quickly view and navigate to specific parts of a video. With the ability to find the right moments in videos, this update improves productivity and the overall video viewing experience in Google Drive. 

Thumbnail previews will now show on video progress bar in Google Drive

Getting started 

  • Admins: There is no admin control for this feature. 
  • End users: 
    • To use this feature, upload a new video to your Drive account (via web or mobile app) > open the newly uploaded video in Drive web > hover your mouse over the video progress bar to see thumbnail previews and drag your mouse along the progress bar to quickly scrub through the video using the thumbnails. 
    • Note: This feature is only available for newly uploaded videos. 
    • Visit the Help Center to learn more about finding specific video moments with thumbnail previews. 

Rollout pace 

Availability 

  • Available to all Google Workspace customers, Google Workspace Individual subscribers, and users with personal Google accounts 

Resources 

Conversational image segmentation with Gemini 2.5

Gemini's advanced capability for conversational image segmentation allows intuitive interaction with visual data by understanding complex phrases, conditional logic, and abstract concepts, streamlining developer experience and opening doors for new applications in media editing, safety monitoring, and damage assessment.

Introducing OSS Rebuild: Open Source, Rebuilt to Last

Posted by Matthew Suozzo, Google Open Source Security Team (GOSST)

Today we're excited to announce OSS Rebuild, a new project to strengthen trust in open source package ecosystems by reproducing upstream artifacts. As supply chain attacks continue to target widely-used dependencies, OSS Rebuild gives security teams powerful data to avoid compromise without burden on upstream maintainers.


The project comprises:


  • Automation to derive declarative build definitions for existing PyPI (Python), npm (JS/TS), and Crates.io (Rust) packages.

  • SLSA Provenance for thousands of packages across our supported ecosystems, meeting SLSA Build Level 3 requirements with no publisher intervention.

  • Build observability and verification tools that security teams can integrate into their existing vulnerability management workflows.

  • Infrastructure definitions to allow organizations to easily run their own instances of OSS Rebuild to rebuild, generate, sign, and distribute provenance.


Challenges

Open source software has become the foundation of our digital world. From critical infrastructure to everyday applications, OSS components now account for 77% of modern applications. With an estimated value exceeding $12 trillion, open source software has never been more integral to the global economy.


Yet this very ubiquity makes open source an attractive target: Recent high-profile supply chain attacks have demonstrated sophisticated methods for compromising widely-used packages. Each incident erodes trust in open ecosystems, creating hesitation among both contributors and consumers.


The security community has responded with initiatives like Security Scorecard, pypi's Trusted Publishers, and npm's native SLSA support. However, there is no panacea: Each effort targets a certain aspect of the problem, often making tradeoffs like shifting work onto publishers and maintainers.

Our Aim

Our aim with OSS Rebuild is to empower the security community to deeply understand and control their supply chains by making package consumption as transparent as using a source repository. Our rebuild platform unlocks this transparency by utilizing a declarative build process, build instrumentation, and network monitoring capabilities which, within the SLSA Build framework, produces fine-grained, durable, trustworthy security metadata.


Building on the hosted infrastructure model that we pioneered with OSS Fuzz for memory issue detection, OSS Rebuild similarly seeks to use hosted resources to address security challenges in open source, this time aimed at securing the software supply chain.


Our vision extends beyond any single ecosystem: We are committed to bringing supply chain transparency and security to all open source software development. Our initial support for the PyPI (Python), npm (JS/TS), and Crates.io (Rust) package registries—providing rebuild provenance for many of their most popular packages—is just the beginning of our journey.


How OSS Rebuild Works




Through automation and heuristics, we determine a prospective build definition for a target package and rebuild it. We semantically compare the result with the existing upstream artifact, normalizing each one to remove instabilities that cause bit-for-bit comparisons to fail (e.g. archive compression). Once we reproduce the package, we publish the build definition and outcome via SLSA Provenance. This attestation allows consumers to reliably verify a package's origin within the source history, understand and repeat its build process, and customize the build from a known-functional baseline (or maybe even use it to generate more detailed SBOMs).


With OSS Rebuild's existing automation for PyPI, npm, and Crates.io, most packages obtain protection effortlessly without user or maintainer intervention. Where automation isn't currently able to fully reproduce the package, we offer manual build specification so the whole community benefits from individual contributions.


And we are also excited at the potential for AI to help reproduce packages: Build and release processes are often described in natural language documentation which, while difficult to utilize with discrete logic, is increasingly useful to language models. Our initial experiments have demonstrated the approach's viability in automating exploration and testing, with limited human intervention, even in the most complex builds.


Our Capabilities

OSS Rebuild helps detect several classes of supply chain compromise:

  • Unsubmitted Source Code - When published packages contain code not present in the public source repository, OSS Rebuild will not attest to the artifact.

  • Build Environment Compromise - By creating standardized, minimal build environments with comprehensive monitoring, OSS Rebuild can detect suspicious build activity or avoid exposure to compromised components altogether.

  • Stealthy Backdoors - Even sophisticated backdoors like xz often exhibit anomalous behavioral patterns during builds. OSS Rebuild's dynamic analysis capabilities can detect unusual execution paths or suspicious operations that are otherwise impractical to identify through manual review.

For enterprises and security professionals, OSS Rebuild can...

  • Enhance metadata without changing registries by enriching data for upstream packages. No need to maintain custom registries or migrate to a new package ecosystem.

  • Augment SBOMs by adding detailed build observability information to existing Software Bills of Materials, creating a more complete security picture.

  • Accelerate vulnerability response by providing a path to vendor, patch, and re-host upstream packages using our verifiable build definitions.


For publishers and maintainers of open source packages, OSS Rebuild can...

  • Strengthen package trust by providing consumers with independent verification of the packages' build integrity, regardless of the sophistication of the original build.

  • Retrofit historical packages' integrity with high-quality build attestations, regardless of whether build attestations were present or supported at the time of publication.

  • Reduce CI security-sensitivity allowing publishers to focus on core development work. CI platforms tend to have complex authorization and execution models and by performing separate rebuilds, the CI environment no longer needs to be load-bearing for your packages' security.


Check it out!

The easiest (but not only!) way to access OSS Rebuild attestations is to use the provided Go-based command-line interface. It can be compiled and installed easily:


$ go install github.com/google/oss-rebuild/v0/cmd/oss-rebuild


You can fetch OSS Rebuild's SLSA Provenance:

$ oss-rebuild get cratesio syn 2.0.39


..or explore the rebuilt versions of a particular package:


$ oss-rebuild list pypi absl-py

..or even rebuild the package for yourself:


$ oss-rebuild get npm lodash 4.17.20 --format=dockerfile | \

   docker run $(docker buildx build -q -)

Join Us in Helping Secure Open Source

OSS Rebuild is not just about fixing problems; it's about empowering end-users to make open source ecosystems more secure and transparent through collective action. If you're a developer, enterprise, or security researcher interested in OSS security, we invite you to follow along and get involved!