Google issued a Chrome 150 stable update fixing 4 high-risk flaws, including 3 UAF bugs and 1 out-of-bounds write, with staged rollout across platforms.
After releasing Chrome 150.0.7871.181 and 150.0.7871.182 earlier, Google issued another stable-channel update within two days, providing 150.0.7871.186 and 150.0.7871.187 for Windows and macOS, and 150.0.7871.186 for Linux and Android, with the goal of fixing 4 high-risk vulnerabilities. All of these vulnerabilities were discovered and reported internally by Google, indicating that this update was a proactive fix from Google rather than a response forced by known large-scale exploitation.[1][2][9]
Three of the four vulnerabilities are Use-After-Free (UAF) flaws, and the remaining one is an out-of-bounds write. The report states that, if left unpatched, these vulnerabilities could be exploited by remote attackers.[1][9]
In terms of severity, CVE-2026-16805 and CVE-2026-16807 were rated as high-risk vulnerabilities with a score of 8.8, CVE-2026-16804 was rated 8.3, and CVE-2026-16806 was rated 8.1.[1]
The technical focus of this update is memory-safety defects. A UAF occurs when a program continues to access an object or memory block after it has already been freed, which can cause browser crashes, data corruption, or even let attackers interfere with execution flow through carefully arranged memory allocation.[2][4][5]
In the Chromium architecture, the browser core and surrounding components are highly complex, and any memory-management mistake can be turned into a pathway for further code execution. Existing data shows that Google has also fixed multiple UAF vulnerabilities in other Chrome 150 updates, including issues affecting Ozone, CameraCapture, GPU, and Network components, reflecting that memory safety remains one of the most common attack surfaces in Chrome’s core security posture.[3][4][5][7]
Among the four newly added vulnerabilities, three are UAF flaws and one is an out-of-bounds write, meaning the attack surface covers both typical high-risk defect classes: lifecycle-management errors and boundary-check failures. From a defensive perspective, both types of issues are often triggerable through malicious web content, so even without browser extensions, a browser may fall into an attack path while parsing HTML, processing the DOM, or handling other page elements.[1][2][9]
Notably, the source says these vulnerabilities can be triggered through specially crafted HTML pages. This means attackers do not necessarily need complex phishing attachments; simply getting a user to open a malicious page may be enough to trigger the weakness while the browser processes the content.[1][9]
On the other hand, third-party compiled information says that as of July 24, Google had not stated whether these four vulnerabilities had actually been exploited, and NVD had no record of real-world exploitation. In other words, what can be confirmed at this stage is that the risk level is high and the patch priority is high, but there is not yet evidence to describe these as publicly verified zero-day attacks.[2]
The affected version is any Chrome version earlier than 150.0.7871.186. Windows and macOS must be updated to 150.0.7871.186 or 150.0.7871.187, Linux must be updated to 150.0.7871.186, and Android users must also wait for and install the corresponding version. Google also stated that the update will roll out in stages, so some devices will not receive the new version at the same time.[2][6][9]
In practical terms, the impact is not limited to enterprise PCs; it also includes individual users, mobile devices, and any workflow that depends on the Chrome browser. Because the trigger condition is opening a webpage containing specially crafted content, the risk is especially relevant in everyday browsing, link opening, webmail, document platforms, and internal web systems.[1][9]
In addition, Google issued several rounds of updates for Chrome 150 in the same week, and the earlier versions had already fixed many vulnerabilities, with multiple major or high-risk flaws appearing repeatedly. This shows that Chrome’s patch cadence has been very dense in a short period, and administrators who do not establish a fast-update process may accumulate exploitable exposure between patch waves.[1][3][5][7]
The first priority is to immediately update Chrome to the appropriate secure version, and restart the browser after updating, otherwise the patch will not take full effect. Official guidance and security notices clearly recommend that users complete the upgrade through automatic updates or by manually opening the "About Google Chrome" page.[8][9]
Second, in enterprise environments, Chrome updates should be integrated into endpoint patch-management workflows, with priority given to devices still running versions earlier than 150.0.7871.186. Because Google rolls out updates in stages, IT staff should not rely only on whether an update prompt appears on the endpoint; they should verify the actual deployed version through version inventory checks.[6][9]
Third, protection against external links and unknown web content should be strengthened. Because these vulnerabilities can be triggered by specially crafted HTML pages, user awareness, email controls, browser policies, DNS filtering, and web filtering can reduce the chance of clicking malicious pages.[1][9]
Fourth, for highly sensitive environments, browser least privilege and layered defenses should be maintained to avoid linking a single browser vulnerability directly to higher-privilege assets. Although the sources do not provide further exploit-chain details, it is already known that such vulnerabilities can lead to more serious security impacts, so strengthening isolation and privilege boundaries remains necessary.[1][9]
Fifth, security teams should continue monitoring Google’s later announcements and updates from government or CERT organizations, especially for signs of real-world exploitation. If in-the-wild exploitation information appears later, the response level should be raised immediately and exposed endpoints should be rechecked.[2][9]