The Beta channel has been updated to 152.0.7977.54 for Windows, Mac and Linux.

A partial list of changes is available in the Git log. Interested in switching release channels? Find out how. 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.

Chrome Release Team
Google Chrome

Hi everyone! We've just released Chrome Beta 152 (152.0.7977.54) for Android. It's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

   Hi, everyone! We've just released Chrome 151 (151.0.7922.169) for Android. It'll become available on Google Play over the next few days. 

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

The Beta channel is being updated to OS version 16765.24.0 (Browser version 152.0.7977.51) for most ChromeOS devices.

The Extended Stable channel has been updated to 150.0.7871.250 for Windows and Mac which will roll out over the coming days/weeks.

 The Stable channel has been updated to 151.0.7922.169/.170 for Windows and Mac and 151.0.7922.169 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 15 security fixes. Please see the Chrome Security Page for more information.

[N/A][534923522] Critical CVE-2026-76034: Buffer overflow in WebGL. Reported by Google on 2026-07-15

[N/A][540087398] Critical CVE-2026-76036: Buffer overflow in Dawn. Reported by Google on 2026-07-28

[N/A][516715010] High CVE-2026-76033: Inappropriate implementation in CORS. Reported by Google on 2026-05-26

[N/A][517612295] High CVE-2026-76037: Link following in CredentialProvider. Reported by Google on 2026-05-28

[N/A][522732244] High CVE-2026-76044: Race condition in USB. Reported by Google on 2026-06-11

[N/A][525167753] High CVE-2026-76039: Incorrect reference resolution in Core. Reported by Google on 2026-06-18

[N/A][534862220] High CVE-2026-76040: Use after free in Browser. Reported by Google on 2026-07-14

[N/A][536439844] High CVE-2026-76035: Inappropriate implementation in Media. Reported by Google on 2026-07-19

[N/A][536460270] High CVE-2026-76042: Use of uninitialized resource in GPU. Reported by Google on 2026-07-19

[N/A][536581050] High CVE-2026-76046: Buffer overflow in ANGLE. Reported by Google on 2026-07-19

[TBD][539350801] High CVE-2026-76043: Incorrect calculation in V8. Reported by Raghav Maheshwari on 2026-07-27

[N/A][540027341] High CVE-2026-76041: Information leak in Skia. Reported by Google on 2026-07-28

[TBD][541251902] High CVE-2026-76047: Type confusion in V8. Reported by ywatanabee on 2026-07-31

[TBD][541926503] High CVE-2026-76038: Type confusion in V8. Reported by un3xploitable && GF on 2026-08-03

[TBD][543082390] High CVE-2026-76045: Use after free in WebGL. Reported by OpenAI Codex Security (amyb) on 2026-08-05

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.

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

by Sean Huh, Common Expression Language Team

We are rapidly entering an era where AI agents can autonomously draft, refactor, and deploy policies that protect our users and our systems. But this velocity introduces a vital question: How do we trust AI-generated policies?

Unit tests may fail to cover the infinite set of possible inputs that occur in production; thus, an AI agent that overfits its policy to existing tests may fail spectacularly in production. To secure automated policy authoring, we must combine heuristic testing with mathematical proofs.

We are thrilled to announce the Common Expression Language (CEL) Formal Verification Framework is now available. Powered by the Z3 theorem prover, this framework allows you to prove the correctness of your CEL expressions and policies, serving as the ultimate safety net for the agentic policy.

Automated reasoning definitively answers questions like:

• “Is there any combination of inputs that allows an unapproved request into production?”
• “Are we absolutely certain this AI-refactored policy matches the original behavior?”
• “Can a bad actor manipulate this rule to force an evaluation error?”

Formal verification establishes mathematical certainty across the infinite spectrum of inputs. Proven policies protect your users and system while giving auditors clear proof of compliance.

To see these capabilities in action, watch our video demonstrating how the CEL Verifier REPL catches subtle logic flaws in seconds:

Proving rules from the ground up

Getting started with formal verification doesn’t require learning complex architectures right away. You can evaluate simple standalone CEL expressions to catch edge cases that tests easily miss.

(Note: The examples below use our interactive REPL syntax—check out the REPL documentation to follow along!)

1. Catching logic bugs in simple expressions (Equivalence)

How do you guarantee a refactored rule behaves identically to the original? Suppose we have a policy that allows ports 80 or 443 in production. An agent might factor the is_prod check like so:

equiv
  (is_prod && port == 80) || (is_prod && port == 443) 
  <=>
  is_prod && port == 80 || port == 443

Because logical AND has a higher operator precedence than OR, the verifier immediately flags Violated, and outputs the exact exploit: in a non-production environment (is_prod = false), the rule mistakenly allows port 443. Fixing the grouping parentheses returns Verified.

2. Enforcing exhaustive guardrails (Validity)

This capability scales directly to use cases like Kubernetes Validating Admission Policies. Suppose an engineer writes a guardrail expression that assumes every request will either be on a low port (under 80) or a high port (over 1024):

valid request.port > 1024 || request.port <= 80

When we check validity (whether an expression holds true for all inputs), the verifier exhaustively searches the entire integer space, flags Violated, and outputs the exact counterexample:

[VIOLATED] Condition is not always true. Counterexample input:
  request.port = 81

3. Guaranteeing security invariants with CEL Policy

While the verifier works perfectly with standalone CEL expressions, complex environments compose multiple rules and variables. Here, the CEL policy format shines. Using assume and assert blocks, the verifier proves a mathematical implication: if the assumptions hold, the assertions must also hold.

name: workload_admission
rule:
  variables:
    - is_admin: 'request.auth.claims.groups.exists(g, g == "admin")'
  match:
    # A subtle flaw introduced during authoring:
    - condition: 'request.is_privileged && request.is_prod'
      output: 'true'
    - condition: 'variables.is_admin || request.has_approval'
      output: 'true'
    - output: 'false'
verification:
  invariants:
    - id: universal_no_unapproved_privileged_prod
      assume:
        - 'request.has_approval == false'
        - 'variables.is_admin == false'
      assert:
        - 'rule.result == false'

The first condition admits privileged workloads into production without checking for approval or admin status. The verifier flags this and provides an example that exploits the issue:

Invariant 'universal_no_unapproved_privileged_prod' violation detected. Counterexample input:
  request.is_privileged = true
  request.is_prod = true
  request.has_approval = false
  request.auth.claims.groups = []

Assertions and assumptions define the boundaries of acceptable agent behavior, allowing developers to configure CI/CD pipelines to validate AI-generated changes simply and securely.

Under the hood: High-fidelity mathematical modeling

Translating a dynamic language into the Satisfiability Modulo Theories (SMT) domain requires immense engineering rigor to prevent the solver from hanging or hallucinating bugs. Our engine provides:

Zero false positives via three-pass taint tracking

Traditional verification tools are prone to “solver hallucinations”—reporting fake bugs when encountering custom domain-specific functions or external variables they don’t fully understand. To eliminate this noise, if a potential issue relies on an unmapped custom function, the verifier isolates and flags it as Inconclusive rather than breaking your CI pipeline with a false alarm. This guarantees every Violation report is a 100% real, reproducible bug.

Deep structural extensionality

The Formal Verification Framework offers configurable-depth bounded-model checking to prevent infinite loops within SMT quantifiers. These configurable limits allow you to control the cost of verification when analyzing deep structure equivalence in expressions like [[1], [2]] == [[1], [2]].

The mandatory bridge of trust

In the agentic era, code writes code. Mathematical proof isn’t just a nice-to-have; it is the fundamental bridge of trust developers require to let AI operate autonomously in their most sensitive systems. Get started with the CEL Formal Verification Framework, to take the next step toward a more secure agentic future today!

Let us know what you think—issues, pull requests, and feedback are always welcome!

You can now protect your calendar from repeated calendar spam and unwanted invitations. When you block a user in Google Calendar, the current event is automatically removed and you no longer receive new calendar invitations from that person.

In addition, when you block an individual in Calendar, they’re added to your account-wide blocklist, and interactions across all supported Google products are blocked. Similarly, if the individual was blocked in another supported Google product, their Calendar invitations will now also be blocked.

This feature allows blocking invitations from users with a Google account. To block invitations from a non-Google Calendar user, use the Gmail blocking functionality. This will block all emails from them, including emails that create Calendar events.

Getting started

• Admins: There is no admin control for this feature.
• End users: Visit the Help Center to learn more.

Rollout pace

• Rapid & Scheduled Release domains: Gradual rollout (up to 15 days for feature visibility) starting on August 18, 2026

Availability

• Available to all Google Workspace customers and Workspace Individual subscribers

Resources

• Google Calendar Help: Block someone in Google Calendar
• Gmail Help: Block an email address in Gmail
• Google Account Help: Block or unblock people's account