Google lists all 213 Chrome 157 fixes and 7 Critical, but prints a dollar amount on only 9

Google's post lists every one of the 213 fixes, and puts a dollar amount on 9

Google's Chrome Releases post of Tuesday 3 November 2026 says Chrome 157 "includes 213 security fixes", and it prints 213 entry lines to match, one CVE each. By Google's own severity labels they split 7 Critical, 77 High, 75 Medium and 54 Low. Nine lines carry a dollar amount, and those nine add up to $31,000. Thirty nine lines say [TBD] and 165 say [N/A] (every count here is derived: this site parsed each line of the saved page, whose HTML holds the list twice, and the two copies are identical). This briefing was read on 4 November 2026 from 11:13 UTC, after reading the robots file of each site fetched. Google makes and updates Chrome and is writing about its own product.

That is a count of lines on a page. It is not a count of attacks, of exposed machines or of bugs a defender can look up, and the post stops well short of those. The table sets what the post states against what it leaves out.

What the post lists, by severity and by credit

The post prints one line per fix in the form bounty field, bug number, severity, CVE id, a component and a type, a credit and a reported on date. Counting those lines gives Table 2. Every figure in it is derived, and the severity words are Chrome's labels, not a score from anyone outside Google.

The post lists everything it counts, so a reader can do this arithmetic from the page itself. That is the more useful half of the page, and it is also where the limits begin: a label on each line, with no rule shown for how the label was chosen. The 84 Critical and High lines are 39.4% of the 213 (derived). The median gap from the printed reported on date to the post date of 3 November is 27 days for those 84 and 40 days for all 213 (derived; the post prints no build or fix date, so this is an age of the report, not the time to fix).

The seven Critical lines

Table 3 sets out the seven. Reporters' names are left out here; where the credit names an employer or an AI model that assisted, the credit is quoted as the post prints it and nothing more is added. By the post's own type words the seven are four use after free, two buffer overflow and one memory corruption (derived). SecurityWeek calls them "critical memory safety bugs", a grouping that is the outlet's, not the post's.

Two of the seven carry an amount, and five say [N/A], two of those five being Google's own finds. The reported on dates run from 8 September to 8 October, which is 26 to 56 days before the post date (derived). The post does not say whether any of the seven is being used in attacks. It does not rank the seven against each other either: Critical is one label.

The bounty field: $31,000 on 9 lines, and TBD on 39

The nine dollar amounts are three of $1,000, four of $2,000 and two of $10,000, which is $3,000 plus $8,000 plus $20,000, or $31,000 (derived). That matches the "$31,000 in rewards" that SecurityWeek reports, but the post itself prints no total, so $31,000 is the sum of the printed amounts and not a stated figure for money paid. SecurityWeek says Google "has not determined" the bounties for 39 flaws; the post prints [TBD] on 39 lines and does not define the word, so that is the outlet's reading of it.

Read across, the pattern is clean. All 130 Google lines say [N/A]. Of the 83 lines credited to someone else, 9 carry an amount (10.8%), 39 say [TBD] (47.0%) and 35 say [N/A] (42.2%), all derived. Every one of the 21 lines that name an AI tool says [N/A], and so does every one of the 11 name only lines described below. The post gives no reason for any [N/A]. For comparison, our briefing on Chrome 155 counted 11 of the 14 AI named lines in that release as [TBD] and 3 as [N/A]. In Chrome 157 the figures are 0 and 21. Nothing in either post explains the change, and this build did not re-read the Chrome reward rules, so it offers no explanation.

Zoom

Who is credited, and what an AI named credit does and does not show

The post's credit strings fall into five groups, shown in Table 5. The group names are this site's. The strings are Google's. "AI credited" is the credit text and not a finding about what any AI system can do: a credit line is the reporter's own statement, and the post does not say what "assisted by" covered.

On a strict reading, 21 of the 213 lines name an AI product in the credit (9.9%), and 17 of the 84 Critical and High lines do (20.2%), all derived. That is the count of people who chose to say so. It is not the share of AI in Chrome's security work: 130 lines say only Google, and the post does not say how Google found them. The same counting rule was used in our Chrome 155 briefing, where 14 of 247 lines named an AI product (5.7%) and Google's share was 74.9% against 61.0% here.

Anthropic sells Claude, OpenAI sells Codex Security, and Google sells Gemini and makes Chrome. Each has a commercial interest in how AI assisted security work is counted, which is a reason to count the credit strings as printed and to claim nothing more. A word on timing, also derived: the 21 AI named lines were reported between 24 September and 25 October. Fifteen are dated 24 to 30 September, 34 to 40 days before the post date, and six are dated 15 to 25 October, 9 to 19 days before it. Chrome 155's AI named lines were all reported within 12 days of that release, as that briefing counted. In this one the median age is 36 days, against 48 for the Google lines and 37 for the other outside lines. The post prints no fix date, so none of these is a time to fix.

SecurityWeek's figures against the post

SecurityWeek's article of 4 November 2026 is a secondary source, read on the same day. Its figures were each re-derived from the post, and Table 6 gives the result. Nearly everything matches. The differences are about words, and about one name.

One finding sits beneath that table. The 51 authorization lines are the largest class by label once the two are merged, and they are mostly low in Chrome's own ratings: Medium 27, Low 19 and High 5 (derived). The largest class is not mostly the most serious one. Counting the post's type words that name memory errors (use after free 45, out of bounds read 10, buffer overflow 7, memory corruption 2, out of bounds write 1, use of released resource 1) gives 66 lines, 31.0% of the 213, and includes all 7 Critical lines and 45 of the 77 High (derived, and this grouping is this site's, which leaves out type confusion and uninitialized resource).

Whose label is it?

None of these is a control. A Critical label does not tell you whether your build is exposed, and a count of 213 does not tell you whether the build on your laptop contains the fixes. The post's own sentence on rollout is the one that decides that: the update "will roll out over the coming days/weeks".

What to do, in order

Defender level only: the post gives no bug detail and none is added here. Items marked as this site's suggestion are standard practice, not statements in Google's post. The Android build and its sentence on shared fixes come from Google's Android post of the same date.

Technical details

The post prints versions, CVE ids, component names and type words. It prints no indicators, no queries, no configuration and no exploit detail, and none is added here. The first block is the version text as the Chrome Releases posts print it. The second is the seven Critical entries copied as printed from the CVE id onward, with the bounty field, the bug number and the reporter left out. A defender can use the first to set a version floor in a management tool, and the second to match CVE ids against an inventory scanner.

Chrome 157.0.8103.38 (Linux) 157.0.8103.38/.39 Windows/Mac
Chrome 157 (157.0.8103.38) for Android

Critical CVE-2026-121156: Buffer overflow in Dawn
Critical CVE-2026-121229: Memory corruption in ANGLE
Critical CVE-2026-121246: Use after free in WebGL
Critical CVE-2026-121035: Use after free in Prerender
Critical CVE-2026-121247: Buffer overflow in Dawn
Critical CVE-2026-121203: Use after free in Geometry
Critical CVE-2026-121126: Use after free in Core

CVE ids and records for these entries were not looked up on CVE.org or NVD for this briefing, so no score or affected range from those databases is stated. The ids are exactly as the post prints them.

The question that exposes the gap

Google's page counts 213 fixes, lists every one, prices nine of them and says nothing about whether anyone is attacking any of them. That is a good page for a statistician and a thin one for a defender.

For the laptop you are reading this on, does your inventory record the Chrome build that is installed, or the build that is running?