Chrome 155 and GIMP Security Updates Fix Critical Memory Flaws

Two open source codebases, one week of patching

In the first week of October, two very different projects that both sit on top of open source code shipped urgent security fixes. Google released Chrome 155 with 247 vulnerability fixes. At the same time, Linux distributions sent out a series of GIMP updates for file-parsing bugs, some of which could let a malicious image run code on the machine that opens it. The two cases differ in scale and in how the fixes reach users. They share the same root problem, though: memory-unsafe code that processes untrusted input. That combination keeps producing high-risk bugs, and new tools are finding them faster than before.

Chrome 155: a very large patch batch

Google pushed Chrome 155 to the Stable channel on October 6. The fixed builds are 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 for Linux, and the rollout will continue over the coming days and weeks.22 Of the 247 fixes, four are rated Critical, 53 High, 122 Medium and 68 Low.2225 For comparison, the October 1 point release fixed 11 issues and the original Chrome 154 release on September 22 fixed 108.25

All four critical bugs are use-after-free flaws. They sit in the Chromecast, Browser, Navigation and Track components and are tracked as CVE-2026-106382, CVE-2026-106197, CVE-2026-106358 and CVE-2026-106347.16 Google found the Chromecast bug itself. Researcher Xinyang Ge reported the other three.1627 The most common bug types in the release were incorrect authorization (41), use-after-free (34) and missing authorization (34), followed by UI misrepresentation, information leaks and uninitialized resources.16

Google has not said that any of the 247 bugs were exploited in the wild, and technical details of the critical flaws remain restricted for now.1622 That is normal practice. Google keeps bug details private until most users have updated, and sometimes longer if a flaw affects a third-party library whose other users haven't patched yet.19

Where the coverage differs

Most outlets reported the same headline numbers. They differ on two points.

The first is how bad the critical bugs could be. Malwarebytes described CVE-2026-106197 and CVE-2026-106358 as flaws that could let a remote attacker run arbitrary code outside Chrome's sandbox through a crafted HTML page. It called the Navigation bug potentially widely exposed because navigation is part of everyday browsing.11 SecurityOnline listed three of the four critical bugs at a CVSS score of 9.6. CybersecurityNews was more careful. It pointed out that Google's own announcement only classifies the bugs as use-after-free and does not describe exploitation methods or confirm code execution.19 The cautious reading is the accurate one for now: until the bug reports are public, "code execution outside the sandbox" comes from CVE descriptions, not from a demonstrated exploit. Either way, users should update now.

The second is version numbers. Malwarebytes listed Windows and Mac builds as 154.0.8037.39/.40.11 Google's release figures, as reported by gHacks and others, put those platforms on 155.0.8059.39/.40.2219 The 154 figure appears to be a transcription error. Users who check chrome://settings/help should look for a version starting with 155.

AI-assisted bug finding shows up in the credits

The researcher credits are the most notable part of this release. Two of the critical bugs, CVE-2026-106358 and CVE-2026-106347, are credited to "Xinyang Ge of Anthropic, assisted by Claude."1922 IT-Connect counted the "assisted by Claude" note on 12 vulnerabilities in the bulletin: the two critical bugs plus ten high-severity issues in V8, PDF, WebRTC and Media. It also found OpenAI's Codex Security credited with two high-severity bugs in V8 and HTML.25 This started before Chrome 155. A WebRTC buffer overflow fixed in the October 1 Chrome 154 update had the same Ge and Claude credit.28

One likely reason the bulletin is so large is that AI-assisted auditing is now finding bugs at scale. Coverage tends to present the 247-bug count as a sign of risk. It is equally evidence of better discovery. Of the 53 high-severity bugs, 34 came from external researchers.16 Google still runs its standard tools as well: AddressSanitizer, MemorySanitizer, libFuzzer, AFL and Control Flow Integrity.19

The 2026 Chrome record so far

The large October release follows a year of steady Chrome patching. In September, Google fixed CVE-2026-87491, an actively exploited out-of-bounds write in the V8 JavaScript engine, in a 230-fix update to Chrome 153.13 Tech Insider's count lists five Chrome zero-days patched by early June and a sixth in-the-wild V8 bug, CVE-2026-85046, fixed in Chrome 152 in September.14 Chrome 151 in July fixed 370 vulnerabilities, seven of them critical.14 Chrome 154 fixed 108, including 11 critical bugs in ANGLE, WebGL, GPU and other components.12

None of the Chrome 155 bugs is a known zero-day, but that history explains why outlets urged quick updates. eSecurity Planet said security teams should confirm that browser patches actually reach managed devices, not just assume the auto-updater did its job.27

The Chromium angle

Chrome is a proprietary product built on the open source Chromium project. That matters for everyone using a different Chromium-based browser. SecurityOnline noted that other Chromium-based browsers will need to ship their own patches. Users of those browsers stay exposed until their vendor merges the upstream fixes and releases a build. Google's policy of keeping details private while third-party projects catch up partly exists to give downstream projects that time.19

GIMP: a steady stream of file-parser bugs

The GIMP situation is less visible but follows the same pattern. On October 1, SUSE released an update fixing ten GIMP vulnerabilities. Several are described as remote code execution bugs in TIF and SGI file parsing, caused by heap and stack buffer overflows and integer overflows. Another is an out-of-bounds write in the lighting effects plug-in.18 SUSE scores CVE-2026-18301 at CVSS 7.8. The vector string marks it as a local attack that needs the user to do something, which here means opening a crafted file.18 RHEL, AlmaLinux and Oracle Linux pushed an "Important" GIMP update on October 5 for out-of-bounds writes, heap overflows and integer overflows, including flaws in the GIMPressionist and lighting effects plug-ins.20

More Red Hat-assigned CVEs followed in the next few days:

• A heap overflow in the DirectDraw Surface (DDS) loader, caused by 32-bit integer overflow when calculating buffer sizes. VulDB's analysis says it could lead to code execution if a user opens a malicious DDS file.4
• A heap overflow in the DICOM export plug-in when exporting images with very large dimensions, scored CVSS 6.3.2
• Similar overflows in the raw data export plug-in and the Hot color filter.810
• A heap over-read in the X cursor thumbnail loader, rated Medium at CVSS 5.5, which can crash GIMP or corrupt memory.1

These follow earlier disclosures from August and September. They include a PSD-plugin integer underflow scored as high as 9.9 that can enable code execution, a DDS overflow scored 8.5, and high-severity heap overflows in the PSP and ICO loaders.796 One vulnerability tracker also lists a Zero Day Initiative advisory for a stack-based overflow in GIMP's APNG parser, marked with no patch as of mid-September.6

Nearly all of these bugs share one cause. Image dimensions are multiplied using 32-bit arithmetic, the result overflows, the program allocates a buffer that is too small, and GEGL then reads or writes past its end.124 Fixing that pattern one plug-in at a time produces a long series of CVEs. The sheer number suggests someone is auditing GIMP's many format handlers systematically, although the coverage doesn't say who.

How the fixes reach users

This is where the two cases differ. Chrome's auto-updater can reach most desktop users within days. GIMP fixes on Linux reach users through distribution maintainers, and they arrive at different times. Debian, Amazon Linux, SUSE, openSUSE, RHEL, AlmaLinux and TuxCare have all shipped GIMP packages since late August.520 Tracker pages still show "No Patch" or "Not reported" for several of the same CVEs.61 Whether you are protected depends on your distribution, not on when the bug was disclosed.

The risk is also different. A Chrome bug can be reached just by loading a web page. A GIMP bug needs someone to open a crafted image. That makes the GIMP flaws more useful for targeted attacks on designers and anyone else who opens images from outside sources than for mass exploitation. Those users should install their distribution's GIMP update now and be careful with unusual file types such as DDS, PSD and ICO from unknown senders until they have.

Bottom line

The main lesson from this week is not the 247-bug count. Bug discovery in large C and C++ codebases is speeding up, partly because of AI-assisted research, and patch distribution has to keep pace. Chrome's centralized updates can. GIMP's distribution-by-distribution model is slower, and Chromium's downstream browsers fall somewhere in between. In each case users are only protected once the fix is installed.