SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

Chrome 155's 247 fixes: 14 credits name an AI tool, all reported 6 to 12 days before release

Chrome 155's notes of 6 October list 247 security fixes, 4 critical and 53 high. Fourteen credit lines name Claude or OpenAI Codex Security, all reported 6 to 12 days before release, against a median of 97 days for all 247.

By Parminder Kumar Sharma · · 19 min read

A dark room with a graphite laptop on a walnut desk at the right. Its screen shows a generic browser window with an empty address bar above a long, tightly packed list of rows, each a small coloured pill and a grey bar with no writing: four coral rows at the top, then amber rows, then cyan and slate ones, the list running off the bottom of the screen.

Fourteen of the 247 credits name an AI tool, and all 14 were reported within 12 days of release

The Chrome 155 release notes of 6 October 2026 list 247 security fixes, each with a CVE and a credit line. Fourteen credit lines name an AI product: 12 read "[name] (Anthropic), assisted by Claude" (the reporter's name is left out here) and 2 read "OpenAI Codex Security", followed by a short handle in brackets. Every one of the 14 was reported 6 to 12 days before the release. For all 247 entries the median gap between the "Reported on" date and release day is 97 days, and for the 233 entries without an AI credit it is 115 (all derived: 6 October minus each reported-on date, counted by script).

The 14 include 2 of the 4 Critical entries and 12 of the 53 High ones, so 14 of the 57 Critical and High fixes, about one in four (24.6%, derived). Across all 247 they are 5.7%. That is the checkable fact. Here is what it does not establish:

  • A count of AI-found bugs. A credit line is the reporter's own statement of assistance. It is not an audit of how each bug was found, and the notes do not say what "assisted by" covered.
  • The share of AI in Chrome's security work. 185 entries are credited only to "Google", with no tool named. Google's own account of 30 July 2026 says it uses AI to find, triage and fix Chrome bugs, so 14 is the part outside reporters chose to name.
  • That AI-credited bugs are worse. Severity is Google's own rating. CISA-ADP's CVSS score disagrees with Google's label for 23 of the 53 entries it had scored.
  • That any of the 247 is exploited, or is not. The notes carry no exploitation statement. That is the absence of a sentence on one date, and the CISA catalogue we checked was published just under two days before the notes.
  • That AI explains the speed. Report-to-release days measure when Google was told, not when a fix was written or merged, and not when your browser received it. All 14 are Critical or High.

The notes' HTML lists every entry twice, so a naive count gives 494. De-duplicated by CVE there are 247, the same number as Google's sentence: Critical 4, High 53, Medium 122, Low 68. For the comparison with earlier releases, the OpenSSH 10.6 notes credited an AI model by name in 2 of 48 entries, as our earlier briefing counted.

SecurityWeek's figures against the notes

SecurityWeek's report of 7 October is a pointer, not a source, so each of its figures was re-derived from the notes. Table 1 gives the result. Nearly everything matches. Two claims go beyond what the notes establish.

Table 1. SecurityWeek's 7 October article checked against the Chrome Releases notes of 6 October 2026. Counts are ours, made by script.

  1. SecurityWeek says
    247 vulnerabilities
    The notes give
    247 unique CVEs, each once. The HTML repeats the list
    Result
    Matches
  2. SecurityWeek says
    Four critical, all use-after-free, in Chromecast, Browser, Navigation and Track
    The notes give
    The same four CVEs and labels
    Result
    Matches
  3. SecurityWeek says
    53 high, 34 from external researchers. 62 external reports in all
    The notes give
    53 High, 19 credited to Google. 247 minus 185 Google is 62
    Result
    Matches (derived)
  4. SecurityWeek says
    About $33,000 paid. Amounts not disclosed for almost 50
    The notes give
    16 amounts totalling exactly $33,000. 41 are [TBD] and 5 are [N/A]
    Result
    Matches if the 5 [N/A] join the 41 [TBD]
  5. SecurityWeek says
    Top types: 41, 34, 34, 20, 17, 16, 9, 9
    The notes give
    The same, with race condition at 12 missing from its list. Incorrect authorization is 40 plus 1 by capital letter
    Result
    Matches, one omission
  6. SecurityWeek says
    About a dozen High flaws from one reporter, many found using AI
    The notes give
    10 of the 53 High carry the Claude credit, 12 if two other forms of the name are one person. The credit says "assisted by"
    Result
    Roughly. "Found using" is stronger than the credit
  7. SecurityWeek says
    Google will not reward the researcher for some of them
    The notes give
    [N/A] on 3 of the 12 Claude-assisted entries, [TBD] on 9. Neither marker is defined in the notes or the rules page
    Result
    Not established. An inference from [N/A]
  8. SecurityWeek says
    No mention of exploitation
    The notes give
    No such wording anywhere in the notes
    Result
    Matches (an absence)

Our method for types: the text before " in " in each entry, compared without regard to capital letters. That gives 32 distinct types. Compared with capitals, "Incorrect authorization" is 40 entries and "Incorrect Authorization" is 1, which is how a count of 40 can arise. The two authorization labels together are 75 entries (30%, derived), more than the 34 use-after-free entries.

What the credit lines say, and what they leave out

Table 2 sets each kind of credit beside what the notes state and leave out. The grouping and counts are ours. The credit strings are Google's, and for outside researchers other than the two AI credits we print no names.

Table 2. The 247 credit lines by kind, from the Chrome 155 notes of 6 October 2026. Severity counts are Google ratings.

  1. Credit as printed (entries)
    "Google" (185)
    Stated in the notes
    A name only. 1 Critical, 19 High, 107 Medium, 58 Low. Reports dated 5 to 194 days before release
    Not stated
    Which team or tool, how many separate finders, any use of AI. Google says elsewhere that it uses AI
  2. Credit as printed (entries)
    "[name] (Anthropic), assisted by Claude" (12)
    Stated in the notes
    A reporter, an employer and a named AI model that assisted. 2 Critical, 10 High, all use-after-free
    Not stated
    What the assistance was: finding, a proof of concept, triage. How many of the 12 the model found
  3. Credit as printed (entries)
    "OpenAI Codex Security", then a handle in brackets (2)
    Stated in the notes
    An OpenAI product name as the credit. Both High: one use-after-free, one type confusion
    Not stated
    That the product is AI (the notes do not say). What it did. Who ran it
  4. Credit as printed (entries)
    The same name without the employer or "assisted by" (2), and a lower-case one-word form (2)
    Stated in the notes
    Four use-after-free entries: Critical, High, High and Low
    Not stated
    Whether these are the same person, or used AI. We count none of the four as AI-named
  5. Credit as printed (entries)
    A research-team credit that includes "CodeBuddy Security" (1)
    Stated in the notes
    A product name inside a company credit. One type confusion
    Not stated
    That it is AI. A report of Tencent Cloud's June launch calls it AI-based. We count it apart: 15 on a wider reading
  6. Credit as printed (entries)
    All other outside credits (43, including 3 "Anonymous")
    Stated in the notes
    A name or pseudonym, and in a few cases a company or team
    Not stated
    Any method. None names an AI product, a model vendor or the word "AI"

The word "AI" appears in no credit line. It appears twice in the notes as part of a component name, "Autofill AI", in two entries credited to Google. No credit names Gemini, GPT, Big Sleep, an agent or an LLM. Two credits are product names, Codex Security and CodeBuddy Security, not statements of method. OpenAI's Codex Security launched on 6 March 2026 as an AI application security agent, per unite.ai. That is a secondary report, as is the one on Tencent's tool, so those identifications rest outside the notes. On the strict reading, 14 credits name an AI product. On the wider one, 15.

The 14 are concentrated. Thirteen are use-after-free, the label on 34 entries in all, so 13 of 34 use-after-free entries carry an AI-named credit (38%, derived). The fourteenth is a type confusion. Two of the four Critical entries, both use-after-free, carry the Claude credit. The notes do not say whether this reflects what these tools find well, what the reporter chose to target, or something else.

On method versus accusation: Anthropic and OpenAI sell the tools named in these credits, and Google sells a competing model, Gemini. Each has a commercial interest in how AI-assisted security work is counted. That is not evidence about any single report. Every figure here is Google's, counted by us, and a credit line is a statement by the reporter, not a finding by Chrome.

Fast, and the notes do not say why

Table 3 and the diagram show the gap by credit group. The AI-named reports sit at the left edge: all 14 within 12 days. The non-AI Critical and High entries are the fairer comparison, because severity may govern how fast a fix ships. For those 43 entries the median is 40 days (range 5 to 123), against 8 for the 14, so severity alone does not account for the gap (derived).

Table 3. Days from the "Reported on" date to release day, 6 October 2026, by credit group (derived). Counts by script from the 247 entries.

  1. Credit group
    Names an AI tool (Claude 12, Codex 2)
    Entries
    14
    Median days
    8
    Range
    6 to 12
  2. Credit group
    Other outside reporters, including Anonymous
    Entries
    48
    Median days
    41.5
    Range
    7 to 680
  3. Credit group
    Credited to Google
    Entries
    185
    Median days
    125
    Range
    5 to 194
  4. Credit group
    All 247
    Entries
    247
    Median days
    97
    Range
    5 to 680
  5. Credit group
    Critical or High with no AI credit
    Entries
    43
    Median days
    40
    Range
    5 to 123
Three bar charts to one scale of days from report to release, in 10 day bins from 0 to 200 plus 200 and over. Entries whose credit names an AI tool, 14: 8 at 0 to 9 days and 6 at 10 to 19, median 8. Other outside reporters, 48: median 41.5, range 7 to 680, 6 at 200 or more. Credited to Google, 185: median 125, range 5 to 194, spread from 20 to 200 days with peaks near 40 and 140 to 180.
Drawn from the 247 entries of the Chrome Releases notes of 6 October 2026. Days are the release date minus the reported-on date, counted by script.

Only 21 of the 247 entries were reported 12 days or fewer before release. Fourteen are the AI-named credits, 2 are credited to Google and 5 to other named researchers and teams. What the notes do not give is the reason. One fact bounds it: Chrome 155's first early stable build went out on 23 September, and all 14 AI-named reports are dated 24 to 30 September, after it. Google's March plan for Chrome 154 cuts the stable branch 14 days before stable release, and the 23 September build is consistent with the same gap for 155. Google's 30 July post says it merges security fixes into the active stable branch according to severity. Our inference, not Google's statement: these fixes were merged late because they were Critical or High, and the speed may owe as much to that rule as to any tool.

The Google median of 125 days is not a slow fix either. It is the time since Google's own staff or tools filed each report. The 185 entries fall on 64 distinct report dates, and 32 of them on two consecutive days, 26 and 27 August. One credit, many separate filings. The reported-on dates are as printed and we could not check them against the issue tracker, which Google keeps restricted until most users are updated.

"Critical" and "247" are labels, not attacks

"247 vulnerabilities" counts CVE entries in one build. It is not 247 attacks and not 247 ways in. The notes give no bug details, and say access may stay restricted until most users are updated. "Critical" is Chromium's own severity rating of a use-after-free, set under Google's guidelines, with no exploit reported. Table 4 shows how thin the label can be: NVD carries Google's rating in each record's text, and CISA-ADP scores each CVE on its own.

Table 4. The four Critical entries in the Chrome 155 notes, with CISA-ADP CVSS v3.1 base scores as read in NVD between 18:16 and 18:24 BST on 7 October 2026.

  1. CVE and label in the notes
    CVE-2026-106382, use after free in Chromecast
    Credit and bounty field
    Google, [N/A]
    Google rating, CISA-ADP score
    Critical, 9.6 Critical
  2. CVE and label in the notes
    CVE-2026-106197, use after free in Browser
    Credit and bounty field
    The reporter name alone, [TBD]
    Google rating, CISA-ADP score
    Critical, 9.6 Critical
  3. CVE and label in the notes
    CVE-2026-106358, use after free in Navigation
    Credit and bounty field
    Claude-assisted credit, [TBD]
    Google rating, CISA-ADP score
    Critical, 9.6 Critical
  4. CVE and label in the notes
    CVE-2026-106347, use after free in Track
    Credit and bounty field
    Claude-assisted credit, [N/A]
    Google rating, CISA-ADP score
    Critical, 8.8 High. The record describes code running inside the sandbox

CISA-ADP had scored 53 of the 57 Critical and High CVEs. For 30 the label matches Google's (3 Critical, 27 High). For 23 it does not: 9 that Google calls High score 9.6, which is Critical, 13 score 4.3 to 5.3, which is Medium, and the Critical use-after-free above scores 8.8 (all derived). A severity label is a vendor's rating, and CVSS is a different scale with different inputs. Neither tells you whether anyone is attacking it.

On exploitation, the notes say nothing. Compare the notes of 3 and 8 September 2026: each ended with a sentence saying Google was aware of an exploit in the wild for one named CVE, and CISA added those two CVEs to KEV on 4 and 9 September. The 6 October notes have no such sentence. CISA-ADP's SSVC data record exploitation as none for 53 of the 57 Critical and High CVEs, dated 6 October, and the other four had no CISA-ADP entry at 18:24 BST. KEV version 2026.10.04 (1,734 entries, released 4 October at 18:52 UTC) contains none of the 247 and no CVE-2026-106xxx at all, read at 18:09 and 18:29 BST. That is the weakest signal, because the catalogue predates the notes by just under two days. The three together say: not stated as exploited, on 7 October.

Is 247 unusual? Not in 2026

Bar chart to one scale of security fixes stated in the first stable post of each Chrome major release. 142: 26. 143: 13. 144: 10. 145: 11. 146: 29. 147: 60 listed, the post saying only multiple. 148: 126. 149: 429. 150: 433. 151: 371. 152: 327. Two-week releases begin at 153: 230. 154: 108. 155, 6 October 2026: 247, highlighted.
Counted by script from the Chrome Releases Stable Channel Update for Desktop posts, using the figure each post states. Chrome 147 states none, so its row is the count of entries it lists.

Against the last eight major releases, 247 is fifth: 433, 429, 371, 327, 247, 230, 126, 108. It is roughly 8 to 25 times the 10 to 29 stated for Chrome 143 to 146 (derived). The step up came in Chrome 148 and 149. The cadence changed too: four weeks between majors until Chrome 152, two weeks from Chrome 153 on 8 September, as Google announced on 3 March. Weekly security updates add more: Chrome 154's first post said 108, and updates on 29 September and 1 October added 32 and 11.

Google's explanation is on the record. Its 30 July post says Chrome 149 and 150 fixed 1,072 security bugs, more than the 23 milestones before them combined, that outside reports by March exceeded all of 2025, and that more bugs found and fixed is not a sign of failure. Its 8 September post says automated AI discovery tools and community reports are producing higher patch volume, and that shorter cycles make that volume easier to manage. Neither says how many of the 247 came from which source, and the "Google" credit cannot tell you.

So 247 is a normal size for this year and an abnormal one against last year. A volume figure is a bookkeeping result until someone says what it counts, the lesson of one Debian kernel update that listed 1,313 CVEs. On the other side of the same trend, Google has paused its open-source bounty for product flaws over automated submissions.

The bounty column, and the sentence the rules do not contain

Table 5. The bounty field of the 247 entries, Chrome 155 notes of 6 October 2026. Dollar amounts as printed.

  1. Field in the notes
    A dollar amount
    Entries
    16
    Breakdown
    Total $33,000: one $5,000, two $3,000, nine $2,000, four $1,000. None to an AI-named credit, none on a Critical
  2. Field in the notes
    [TBD]
    Entries
    41
    Breakdown
    All outside reporters. 11 are AI-named credits (9 Claude-assisted, 2 Codex), 2 are Critical
  3. Field in the notes
    [N/A]
    Entries
    190
    Breakdown
    185 credited to Google. 5 outside, 3 of them Claude-assisted, all dated 30 September

SecurityWeek wrote that Google will not reward the researcher for some of the flaws. The notes do not say so. They print [N/A] on 3 of the 12 Claude-assisted entries and [TBD] on 9, and define neither. [N/A] is also on all 185 Google entries and on 2 other outside entries, so on its own it does not mark AI-assisted reports, and the notes give no reason for any of them.

The Chrome VRP rules page, read in a browser at 18:13 BST on 7 October, has no sentence about AI-assisted or AI-generated reports. Its AI sections concern vulnerabilities in Chrome's own Gemini and AI features. It does say what could explain an [N/A] on any outside report: Google is likely not to reward a bug it would have fixed without the report, reports may be duplicated against internal tooling for up to seven days after submission, bugs in code that landed in the last seven days are ineligible, and the decision is at Google's discretion. The Chromium VRP FAQ adds that a bug found by an internal tool within seven days of a report counts as already known. A separate Chromium document gives advice to AI agents that audit Chromium and says it is not part of the VRP rules. The three [N/A] Claude-assisted entries are the three dated 30 September, the last day in the group, and all three outside reports dated that day carry [N/A]. Whether a seven-day rule applies is not stated.

For UK estates: 57 Critical and High CVEs, one browser update, one clock

Table 6. Which clock applies to a Chrome 155 update released on 6 October 2026. Dates computed from the rules; the Edge row is Microsoft's plan.

  1. Clock
    NCSC best practice, operating systems and applications
    Rule
    Apply automatically as soon as published, phased, within 7 days
    Date
    13 October 2026
  2. Clock
    Cyber Essentials v3.3, critical or high fixes
    Rule
    Update within 14 days of release
    Date
    20 October 2026
  3. Clock
    Microsoft Edge (a separate vendor release)
    Rule
    Planned stable week of 8 October. 6 October notice: working on a fix
    Date
    Our reading: the clock starts on Microsoft's release

The NCSC's browser guidance (version 2.1, reviewed 13 May 2025) tells administrators to install updates promptly and consider a way to monitor which browser version each device runs. Its patch-wave blog of 1 May 2026 asks organisations to prepare to deploy updates quickly, more often and at scale. Chrome's two-week cycle and counts in the hundreds are the case for automating rather than scheduling.

Four places the Chrome number does not reach on its own. Edge: Microsoft's security notes were last updated on 6 October with a notice that it is aware of the Chromium fixes and working on a security fix, and its newest build is 154.0.4258.62, from 5 October. Its schedule puts Edge 155 stable in the week of 8 October, approximate. On the last three majors Edge's stable build followed Chrome's by two days (25 to 27 August, 8 to 10 September, 22 to 24 September, derived), which would also be 8 October. Other Chromium browsers and embedded runtimes: Brave, Opera, Vivaldi and Electron-based desktop apps ship their own builds, and a Chrome update does not patch them. We read none of their notes. Extended Stable: Google's 6 October post for that channel is build 152.0.7977.158, lists no CVEs, and does not say which of the 247 it carries; Google's 8 September blog post says security fixes there are backported weekly. Mobile: Chrome 155 for Android is 155.0.8059.39 on Google Play over the next few days, and Google says Android releases carry the same fixes as desktop unless noted. The iOS build is 155.0.8059.37, and the iOS post says nothing about security fixes.

What to do, in order

Defender level only. The notes give no bug details and we add none. The point of the order is that Chrome stages an update on disk and applies it at the next restart, as Google's 30 July post explains, so an installed build is not a running build.

Take this with you

Checklist, in the order worth doing

  • Set the floor: Chrome 155.0.8059.39 or later on Windows, macOS and Linux (the notes give .39 and .40 for Windows and Mac), 155.0.8059.39 for Android, and 155.0.8059.37 for iOS as Google released it.
  • Count what is running, not what is installed. Use Chrome Enterprise Core or your endpoint tool for fleet versions, and chrome://version on a sample. A laptop that has not relaunched since 6 October is not patched.
  • Force the relaunch. Google recommends the RelaunchNotification policy, which escalates from a reminder to a forced restart over a period you set. Set the deadline inside the 7 day NCSC practice if you can, and never later than 20 October.
  • Find the other Chromium builds: Edge (check Microsoft's notes on the day it ships), Brave, Opera, Vivaldi, Electron-based apps and any kiosk or digital signage runtime. Ask each vendor which Chromium it carries and when it takes the fixes.
  • Check Extended Stable. Confirm the channel has the latest 152 build, ask the admin console or Google which of the 247 it includes, and record why it is not on 155.
  • Chase the slow devices: browsers left open for weeks, VDI golden images, contractor and BYOD devices, kiosks, and Linux hosts that take Chrome from a package repository.
  • Record the decision: the date each group reached the fixed build against 20 October, who decided, and what stays behind and why. Keep the AI-credit count out of your priority call: patch the build, and take severity from your own policy rather than the label.
chrome://version      the running build and its update status
chrome://management   whether the browser is managed
chrome://policy       whether RelaunchNotification is set

The question that exposes the gap

Fourteen credits name an AI tool, 185 name only Google, and the notes cannot say which bugs were found how. The count tells you who chose to say so. It tells you nothing about which of your devices are exposed.

For a laptop that has not been restarted since 6 October, does your inventory record the Chrome build installed on disk, or the build running in memory?

Key facts

Sources

  1. PrimaryStable Channel Update for Desktop, Tuesday 6 October 2026 (feed time 10:17 PDT), read in full at 18:09 BST with a browser User-Agent: 155.0.8059.39/.40 and .39, 247 security fixes, all 247 entries parsed by script (the HTML repeats the list), severity, credit, bounty field and reported-on date of each, no exploitation wordingChrome Releases (Google)accessed 2026-10-07
  2. PrimaryBlog index and its Atom feed, read by label and date range at 18:11 BST: the first stable post of each major release from Chrome 142 to 155 with its stated fix count and date, the weekly updates for Chrome 154, the Android and iOS posts of 6 October, and the 3 and 8 September posts that carry an in-the-wild sentenceChrome Releases (Google)accessed 2026-10-07
  3. PrimaryExtended Stable Update for Desktop, 6 October 2026: build 152.0.7977.158 for Windows and Mac, no CVE listChrome Releases (Google)accessed 2026-10-07
  4. PrimaryChrome for Android update, 6 October 2026: 155.0.8059.39, on Google Play over the next few days, same security fixes as desktop unless notedChrome Releases (Google)accessed 2026-10-07
  5. PrimaryChrome Stable for iOS update, 6 October 2026: 155.0.8059.37, stability and performance improvements, no security statementChrome Releases (Google)accessed 2026-10-07
  6. PrimaryStable Channel Update for Desktop, 8 September 2026 (Chrome 153): 230 security fixes and the sentence saying Google was aware of an in-the-wild exploit for one named CVEChrome Releases (Google)accessed 2026-10-07
  7. PrimaryStable Channel Update for Desktop, 3 September 2026 (Chrome 152 point release): the in-the-wild sentence for one named CVEChrome Releases (Google)accessed 2026-10-07
  8. PrimaryStronger with every update, 30 July 2026, read in full: AI used for discovery, triage and fixing, 1,072 security bugs fixed in Chrome 149 and 150, outside reports by March above all of 2025, the update applied at next restart, RelaunchNotification and Extended Stable adviceGoogle (Chrome Security team)accessed 2026-10-07
  9. PrimaryThe two-week release cycle is here, 8 September 2026: Chrome 153 first, automated AI discovery tools and community reports raising patch volume, Extended Stable security fixes backported weeklyChrome for Developers (Google)accessed 2026-10-07
  10. PrimaryAnnouncement of 3 March 2026 of the two-week cycle from 8 September 2026, with the Chrome 153 and 154 timetable showing the stable cut 14 days before stable releaseChrome for Developers (Google)accessed 2026-10-07
  11. PrimaryChrome Vulnerability Reward Program Rules, read in a browser at 18:13 BST: no sentence on AI-assisted or AI-generated reports, the AI sections concern Gemini and AI features in Chrome; the seven-day rules, the would-have-fixed-anyway rule, reward discretion, the changelog to 2026-09Google Bug Huntersaccessed 2026-10-07
  12. PrimaryChrome VRP FAQ, main branch: a bug found by an internal tool within seven days of a report counts as already known; a CVE can be issued and the report later found to have no security impactChromium projectaccessed 2026-10-07
  13. PrimarySecurity for Agents, main branch: advice to AI agents auditing Chromium, stated as not part of the VRP rulesChromium projectaccessed 2026-10-07
  14. PrimaryNVD API records for all 57 Critical and High CVEs, read 18:16 to 18:24 BST on 7 October: published 6 October, 30 Analyzed and 27 Undergoing Analysis, Google CNA text with Chromium severity, CISA-ADP CVSS v3.1 for 53 and SSVC exploitation none for 53; the Track entry scored 8.8 against Google CriticalNIST NVDaccessed 2026-10-07
  15. PrimaryKnown Exploited Vulnerabilities catalogue version 2026.10.04, released 4 October 2026 18:52 UTC, 1,734 entries, read at 18:09 and 18:29 BST: none of the 247 CVEs, no CVE-2026-106xxx, and the Chromium-family entries added in 2026CISAaccessed 2026-10-07
  16. PrimaryRelease notes for Microsoft Edge Security Updates, read 18:15 and 18:30 BST: 6 October notice that Microsoft is working on a security fix for the Chromium fixes, newest build 154.0.4258.62 from 5 OctoberMicrosoft Learnaccessed 2026-10-07
  17. PrimaryMicrosoft Edge release schedule, page updated 6 October 2026 23:17 UTC: Edge 155 stable planned for the week of 8 October, approximate; Edge 152 to 154 stable datesMicrosoft Learnaccessed 2026-10-07
  18. PrimaryCyber Essentials requirements for IT infrastructure v3.3, April 2026: updates within 14 days of release where the vendor says critical or high risk, CVSS v3 of 7 or above, or gives no detailNational Cyber Security Centreaccessed 2026-10-07
  19. PrimaryVulnerability management, update by default (version 2.1, reviewed 1 May 2026): operating systems and applications applied automatically, phased, within 7 daysNational Cyber Security Centreaccessed 2026-10-07
  20. PrimaryManaging web browser security (version 2.1, published 29 June 2021, reviewed 13 May 2025): install updates promptly and monitor which browser version each device hasNational Cyber Security Centreaccessed 2026-10-07
  21. PrimaryPreparing for a vulnerability patch wave, 1 May 2026: prepare to deploy updates quickly, more often and at scaleNational Cyber Security Centreaccessed 2026-10-07
  22. Reported byChrome 155 Update Patches 247 Vulnerabilities, 7 October 2026: a pointer only; every figure re-derived from the notes, see Table 1SecurityWeekaccessed 2026-10-07
  23. Reported byReport that OpenAI launched Codex Security on 6 March 2026 as an AI application security agent; used only to identify the product named in two credits, which the notes do not describeUnite.AIaccessed 2026-10-07
  24. Reported byReport of Tencent Cloud launching CodeBuddy Security on 5 June 2026 with an AI audit engine; used only to identify the product named inside one credit, which the notes do not describeAI Baseaccessed 2026-10-07

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.