We had an amazing day on May 15, as we organized SCS Fay Day Experience #4! We welcomed fans of our games from all around the world to our office in Prague, where they had the opportunity to meet our team, tour the studio, and get a behind-the-scenes look at how our games are made.
After receiving a huge number of applications for this fourth edition of our SCS Fan Day, we had to narrow the list down to a smaller group of some of our most dedicated fans, including visitors who traveled all the way to Prague from countries such as Brazil.
As always, it turned into an unforgettable experience meeting and chatting with members of our #BestCommunityEver. Once everyone arrived, they took on the challenge of driving on our 4D motion simulator before heading out on a tour of the office. Along the way, we stopped by several departments where our colleagues gave them a behind-the-scenes look at what they are currently working on and how the development process looks at SCS Software.
Later in the afternoon, we hosted a special Q&A session with our developers and CEO Pavel Ε ebor, where we discussed the community's thoughts on our games and answered plenty of questions from our guests. The session was accompanied by delicious snacks and coffee before we gathered for a group photo, handed out bags filled with SCS merchandise, and unfortunately had to say goodbye - at least until we hopefully meet again someday!
We would like to thank everyone who took part in this year's Fan Day. We hope it was a memorable experience for you, because it was certainly unforgettable for us as well. Your passion, support, and willingness to travel such long distances just to meet us truly means the world to everyone here at SCS Software, and it continues to motivate us every day. We also hope to meet again with everyone who applied but was not selected or was unable to attend this time around.
We hope we will be able to host another Fan Day in the future and meet even more of our amazing fans. Don't forget to give ourΒ X/Twitter,Β Instagram,Β Facebook,Β Bluesky, andΒ TikTokΒ a follow, as you'll receive news from any upcoming events straight to your feed, orΒ subscribe to our newsletterΒ to stay informed.
Another very minor update, now at 0.3.15, for our nanotime
package is now on CRAN, and has
been built for r2u and
Debian. nanotime
relies on the RcppCCTZ
package (as well as the RcppDate
package for additional C++ operations) and offers efficient high(er)
resolution time parsing and formatting up to nanosecond resolution,
using the bit64
package for the actual integer64 arithmetic. Initially
implemented using the S3 system, it has benefitted greatly from a
rigorous refactoring by Leonardo who not only rejigged
nanotime internals in S4 but also added new S4 types for
periods, intervals and durations.
This release adjusts the package for the maybe overly hasty switch R 4.6.0 has undertaken with respect to using C++20 as a default C++ compilation standard. I am of course largely in favour of such a switch to more modern C++. But I am also cognizant of the fact that not all compilers and machines are ready. And just as I have already seen one other package fail to compile on a particular CRAN system (!!) under C++20, this package all of a sudden, and only on that same system, started to throw two (harmless) compiler warnings. We could call these erroneous as newer versions of the same compiler do not throw them but it does not matter. The decision to default to C++20 has been made, and now we live with it. But maybe some hardware platforms should be moved behind the barn. Either way, this release both adds an explicit cast to two lines that may not really need it (but this will not hurt) and also dials the compilation standard down to C++17 on one particular platform. So once again there are no user-facing changes, or behavioural changes or enhancements, in this release.
The NEWS snippet below has the fuller details.
Changes in version 0.3.15 (2026-05-21)
Add extra
const_castas one CRAN machine with more ancient setup whines otherwise and is obviously less C++20 ready than it thinks
tools/configurealso checks where this is being built and βas needed' downgrades the compilation to C++17
Thanks to my CRANberries, there is a diffstat report for this release. More details and examples are at the nanotime page; code, issue tickets etc at the GitHub repository β and all documentation is provided at the nanotime documentation site.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.
Fixed a crash experienced by users with Intel Raptor Lake CPUs. (Bug 1950764)
Fixed an issue on Windows where some websites using WebSerial to flash device firmware could fail unexpectedly. (Bug 2040754)
Reference link to 151.0 release notes.
This is a security release to address a brute-force based vulnerability related to multi-factor authentication, and to update project libraries to help avoid potential vulnerabilities that have been reported in those.
Upgrade is generally advised, but strongly so where multi-factor authentication is used & considered as a critical layer of defense.
Thanks to Stephen O. / Sakusen (Codeberg, Website) for responsibly reporting these issues.
VIENNA, Austria β May 21, 2026 β Proxmox Server Solutions GmbH today announced the immediate availability of Proxmox Virtual Environment 9.2, the latest version of its integrated open-source platform for enterprise virtualization. This major update introduces a dynamic load balancer, expanded software-defined networking (SDN) capabilities, and granular management of custom CPU models. By improving resource utilization through dynamic workload balancing and simplifying complex cluster maintenance workflows, Proxmox VE 9.2 enables organizations to scale their infrastructure with higher efficiency and significantly reduced operational complexity.
Dynamic Load Balancer
A highlight of version 9.2 is the introduction of the Dynamic Load Balancer, which utilizes an intelligent decision-making framework to optimize guest placement for maximum cluster balance and reliability. Operating in a new dynamic mode, the cluster resource scheduler (CRS) incorporates real-time node and guest resource utilization into every placement decision. The integrated load balancer can automatically migrate guests managed by the High Availability (HA) stack to reduce the imbalance across the cluster nodes while strictly respecting all user-defined HA rules. Administrators maintain granular control through configurable options that define the behavior and sensitivity of the load Balancer through various parameters, providing organizations with superior oversight of resource utilization in highly available environments.
Expanded software-defined networking (SDN)
This release significantly improves its SDN stack to support modern network architectures.
Further additions include route redistribution for OSPF fabrics, additional options for configuring EVPN controllers, and IPv6 underlay support for EVPN.
Custom CPU model management
To provide greater flexibility for specialized workloads, Proxmox VE 9.2 introduces a dedicated management interface for custom CPU models. Administrators can now create, edit, and remove custom CPU profiles directly in the web interface under the βDatacenterβ section. This makes it easier to tailor the virtual CPU features exposed to VMs, ensuring optimal workload performance. Additionally, the integrated CPU flags selector provides instant visibility into supported flags across all cluster nodes, helping administrators identify potential cluster-wide compatibility issues during the configuration phase.
Confident maintenance with HA Arm/Disarm
Addressing common administrative challenges during maintenance windows, Proxmox VE 9.2 introduces the ability to "disarm" and "arm" the HA Manager cluster-wide. Administrators can temporarily suspend the HA stack during planned cluster maintenance to prevent unwanted actions, such as fencing nodes. HA resource states are preserved during these disarm and arm cycles, ensuring HA resources return to their previous state and node placement automatically once maintenance is completed.
Updated technology stack
Proxmox Virtual Environment 9.2 is based on Debian 13.5 "Trixie" and features Linux kernel 7.0 as the new stable default. Along with the latest versions of QEMU 11.0, LXC 7.0, and ZFS 2.4, this release offers a high-performance open-source architecture for modern infrastructure.
As a complete data center ecosystem engineered for high-density virtualization and disaster recovery, version 9.2 provides businesses with a seamless management environment for compute, storage, and backup. This includes updated support for the storage layer, with Ceph Tentacle 20.2. now available as a stable option alongside Ceph Squid 19.2.
Proxmox Virtual Environment 9.2 is open-source software and immediately available for download at the official website. Users can obtain a complete installation image via ISO download, which contains the full feature set of the solution and can be installed quickly on bare-metal systems using an intuitive installation wizard.
Seamless distribution upgrades from older versions of Proxmox Virtual Environment are possible using the standard APT package management system. Furthermore, it is also possible to install Proxmox Virtual Environment on top of an existing Debian installation.
For enterprise environments, Proxmox offers comprehensive support plans that provide direct access to expert support services and stable and secure updates. These support contracts offer a cost-effective way to secure enterprise-grade stability, with pricing starting at EUR 120 per year and CPU.Β
Resources:
About Proxmox Virtual Environment
Powering over 2 million hosts globally, Proxmox Virtual Environment is a complete open-source platform for enterprise virtualization and hyper-converged infrastructure. It natively unifies KVM virtualization, LXC containers, software-defined storage, and networking on a single platform. Alongside its dedicated Backup Server and Datacenter Manager, the Proxmox ecosystem eliminates multi-site complexity as well as dependency on proprietary stacks. Backed by a global community of over 225,000 members, the platform serves as a scalable, cost-effective foundation for modern data centers.
About Proxmox Server Solutions
Proxmox Server Solutions provides powerful, intuitive open-source server software that guarantees vendor independence and minimizes total cost of ownership. Enterprises of all sizes rely on the companyβs reliable vendor support, certified training services, and a global network of 3,000 integration partners to ensure business continuity. Established in 2005 and headquartered in Vienna, Austria, tens of thousands of corporate customers worldwide trust Proxmox solutions to secure their mission-critical IT environments. To learn more visit https://www.proxmox.com or follow us on LinkedIn and YouTube.
Contact:Β Daniela HΓ€sler, Proxmox Server Solutions GmbH,Β marketing@proxmox.com
I've heard "containers are not a security boundary" enough times that it's started to feel like received wisdom, and my honest read (after 13+ years) is that it's technically defensible but practically sloppy β and the sloppiness matters.
The part that's true: containers share a kernel, and a kernel exploit crosses the container boundary where a VM would not. That difference is real and non-trivial, and the CVE history backs it up β CVE-2019-5736, CVE-2022-0492, and CVE-2024-21626 all happened in "correctly configured" production containers.
The part I'd push back on is that the comparison point is almost never stated. "Containers aren't a security boundary" is being used as shorthand for "containers aren't a VM boundary" β but the conclusion people seem to draw from that is "therefore don't bother", which doesn't actually follow. The more honest version is that default Docker doesn't provide strong isolation between mutually untrusting parties, but a hardened configuration does.
What ships by default in Moby is actually a pretty reasonable foundation: seccomp is enabled (with a builtin profile blocking ~50 syscalls β credit where it's due: this is mostly @jessfraz's work; she even ran contained.af as a public CTF for years daring people to escape a container under her seccomp profile, and to my knowledge it was never claimed), AppArmor is enabled (the docker-default profile), and several sensitive /proc paths are masked. What's not on by default: no-new-privileges (setuid binaries inside can escalate), CAP_NET_RAW is still granted to every container (even though the kernel has supported unprivileged ICMP sockets for over a decade, meaning most modern distributions no longer need CAP_NET_RAW for ping), and user namespace remapping β though user namespaces aren't quite the silver bullet they might sound like; Debian left them disabled by default for years because the kernel attack surface they exposed hadn't been hardened against unprivileged callers.
The boundary isn't absent β it doesn't come completely pre-assembled. With VMs, the hypervisor is there whether you asked for it or not; with containers, assembling the boundary is left as an exercise for the operator. That's a much more solvable problem than "the technology is incapable", but it does mean the work falls to whoever's running the containers.
So, some things you can do today without waiting for defaults to change:
--user (or USER in your Dockerfile) is worth calling out specifically, because I think it's arguably stronger than user namespace remapping in one important way β and partly for the same reason Debian was hesitant about user namespaces in the first place. User namespace remapping protects the host from a root-in-container escape: if you do escape, you land as an unprivileged user on the host. But you were still root inside the container the whole time. Running as a non-root user means you were never root anywhere. The blast radius of a compromised process is limited whether or not it escapes, including for things like reading secrets, modifying container contents, or lateral movement within the container itself. Most application containers have no legitimate reason to be root.
Beyond that, a short list of things that are easy to enable and hard to justify leaving off:
Log in
--security-opt no-new-privileges β prevents setuid binaries from escalating; can also be set daemon-wide in daemon.json with "no-new-privileges": true--read-only β a read-only root filesystem means a compromised process can't easily persist tooling or modify the container (pair with a writable tmpfs mount for /tmp etc as needed)--cap-drop NET_RAW β or --cap-drop ALL and add back only what you actually need; CAP_NET_RAW is almost never legitimately needed by application containers--privileged β if something seems to require it, the right answer is almost always a more targeted capability grant or bind mount, not the nuclear optiondocker run \
--user 1234:5678 \
--security-opt no-new-privileges \
--read-only \
--tmpfs /tmp \
--cap-drop ALL \
acme/untrusted-workload:latest
None of these require a daemon restart or infrastructure changes, and stacked together they go a long way toward actually building the boundary that the defaults leave unbuilt.
(this post was written with the assistance of "claude my eyes right out" but all thoughts and understanding are Tianon's)
We are pleased to announce the latest stable release of Jellyfin, version 10.11.9! This minor release brings several bugfixes to improve your Jellyfin experience. As always, please ensure you take a full backup before upgrading!
You can find more details about and discuss this release on our forums.
We are pleased to announce the latest stable release of Jellyfin, version 10.11.9! This minor release brings several bugfixes to improve your Jellyfin experience. As always, please ensure you take a full backup before upgrading!
You can find more details about and discuss this release on our forums.
The Stable channel has been updated to 149.0.7827.22/.23 for Windows and Mac (149.0.7827.29/.30) ,as part of our early stable release to a small percentage of users. A full list of changes in this build is available in the log.
You can find more details about early Stable releases here.
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
Full Changelog: v4.3.2...v4.3.3
This is bug-fix release for 1.29.0.
Feature highlightsβ¨:
.txt import of feed URLs in additional to e.g. OPMLBug fixes highlights π:
UI highlights πΌ:
This release has been made by @Alkarex, @Frenzie, @IEEE-754, @Inverle, @McFev, @ciro-mota, @cweiske, @polybjorn and newcomer @mzl2233
Full changelog:
lib_opml library #8652, #8853,
I was getting β<XF86AudioPlay> is undefinedβ in the status bar of Emacs displayed every 2-3 seconds. Nowhere else I noticed any misbehavior or problems, and also couldnβt find any related log entries. It didnβt stop, though didnβt want to reboot my system to see whether that would fix the problem, but it was driving me nuts.
Now, as a starting point I adjusted my sway configuration, to react to the XF86AudioPlay key press event:
bindsym XF86AudioPlay exec playerctl play-pause
After reloading sway, my music player started to play for 2-3 seconds, stopped playing, started again, etc. It wasnβt a Emacs bug, but something indeed seemed to send the XF86AudioPlay key event every 2-3 seconds. It wasnβt my USB keyboard or any stuck key on it, as verified also by unplugging it. So which device was causing this?
libinput from libinput-tools to the rescue:
% sudo libinput debug-events [...] -event12 KEYBOARD_KEY +0.000s KEY_PLAYPAUSE (164) pressed event12 KEYBOARD_KEY +0.000s KEY_PLAYPAUSE (164) released event12 KEYBOARD_KEY +2.887s KEY_PLAYPAUSE (164) pressed event12 KEYBOARD_KEY +2.887s KEY_PLAYPAUSE (164) released event12 KEYBOARD_KEY +5.773s KEY_PLAYPAUSE (164) pressed event12 KEYBOARD_KEY +5.774s KEY_PLAYPAUSE (164) released [...]
The `event12` device was sending this event, whatβs behind this?
% sudo udevadm info /dev/input/event12
P: /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
M: event12
R: 12
J: c13:76
U: input
D: c 13:76
N: input/event12
L: 0
S: input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: DEVPATH=/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
E: DEVNAME=/dev/input/event12
E: MAJOR=13
E: MINOR=76
E: SUBSYSTEM=input
E: USEC_INITIALIZED=12468722
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-0000:00:1f.3-platform-skl_hda_dsp_generic
E: ID_PATH_TAG=pci-0000_00_1f_3-platform-skl_hda_dsp_generic
E: XKBMODEL=pc105
E: XKBLAYOUT=us
E: XKBOPTIONS=lv3:ralt_switch,compose:rctrl
E: BACKSPACE=guess
E: LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
E: DEVLINKS=/dev/input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:
% sudo udevadm info -a /dev/input/event12 | grep -iE 'kernels|drivers|name'
KERNELS=="input17"
DRIVERS==""
ATTRS{name}=="sof-hda-dsp Headphone"
KERNELS=="card0"
DRIVERS==""
KERNELS=="skl_hda_dsp_generic"
DRIVERS=="skl_hda_dsp_generic"
KERNELS=="0000:00:1f.3"
DRIVERS=="sof-audio-pci-intel-tgl"
KERNELS=="pci0000:00"
DRIVERS==""
Behind this event12 is sof-hda-dsp Headphone, and evtest confirms that:
% sudo evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: AT Translated Set 2 keyboard /dev/input/event1: Sleep Button /dev/input/event10: ThinkPad Extra Buttons /dev/input/event11: sof-hda-dsp Mic /dev/input/event12: sof-hda-dsp Headphone /dev/input/event13: sof-hda-dsp HDMI/DP,pcm=3 /dev/input/event14: sof-hda-dsp HDMI/DP,pcm=4 /dev/input/event15: sof-hda-dsp HDMI/DP,pcm=5 /dev/input/event16: Yubico YubiKey OTP+FIDO+CCID /dev/input/event17: Apple Inc. Magic Keyboard with Numeric Keypad /dev/input/event18: Apple Inc. Magic Keyboard with Numeric Keypad [...] Select the device event number [0-24]: ^C
We can even get further information:
% sudo evtest /dev/input/event12
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "sof-hda-dsp Headphone"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 164 (KEY_PLAYPAUSE)
Event code 582 (KEY_VOICECOMMAND)
Event type 5 (EV_SW)
Event code 2 (SW_HEADPHONE_INSERT) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1779295060.175766, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1779295060.175766, -------------- SYN_REPORT ------------
Event: time 1779295061.951168, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295061.951168, -------------- SYN_REPORT ------------
Event: time 1779295061.951194, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295061.951194, -------------- SYN_REPORT ------------
Event: time 1779295064.548671, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295064.548671, -------------- SYN_REPORT ------------
Event: time 1779295064.548689, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295064.548689, -------------- SYN_REPORT ------------
Event: time 1779295067.437172, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295067.437172, -------------- SYN_REPORT ------------
Event: time 1779295067.437187, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295067.437187, -------------- SYN_REPORT ------------
Event: time 1779295070.323775, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295070.323775, -------------- SYN_REPORT ------------
Event: time 1779295070.323790, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295070.323790, -------------- SYN_REPORT ------------
Event: time 1779295073.200350, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295073.200350, -------------- SYN_REPORT ------------
Event: time 1779295073.200373, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295073.200373, -------------- SYN_REPORT ------------
Event: time 1779295076.076228, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295076.076228, -------------- SYN_REPORT ------------
Event: time 1779295076.076250, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295076.076250, -------------- SYN_REPORT ------------
Event: time 1779295078.961740, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295078.961740, -------------- SYN_REPORT ------------
Event: time 1779295078.961754, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295078.961754, -------------- SYN_REPORT ------------
Event: time 1779295081.850156, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295081.850156, -------------- SYN_REPORT ------------
Event: time 1779295081.850175, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295081.850175, -------------- SYN_REPORT ------------
Event: time 1779295083.306612, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1779295083.306612, -------------- SYN_REPORT ------------
So when I plug in my headphone (see the `SW_HEADPHONE_INSERT` event), the unexpected behavior starts, unplugging stops the problem.
Good! But what was totally unexpected for me: my headphone, being a Beyerdynamic DT-990 Pro, does not have any keys. 8-)
As it turned out, the headphone jack seemed to have been not entirely clean. The analog side of the jack triggers a behavior within the audio codec, where it seems to interpret the fluctuating impedance as a play button of the headset, being pressed, again and again.
I cleaned the jack of my headphone and my XF86AudioPlay problem is gone, case closed.
Following the series of various Linux exploits of the last three weeks, the bug of today is PinTheft [CVE-2026-43494] which is local root privilege escalations.
The vulnerability can be mitigated by unloading and blocking rds modules, linux-vulnerability-mitigation as of 20260519-1 (uploaded to sid, trixie-fastforward-backports and people.debian.org/~daniel) does that automatically for you.
Updates:
default Debian kernels (bullseye, bookworm, trixie, and testing/unstable, experimental) are not directly affected because autoloading of the rds modules is disabled by rds-Disable-auto-loading-as-mitigation-against-local.patch
Added references to CVE-2026-43494
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
orcpt.$ or { prefixes as secure secrets.acl-principal-prop-set REPORT enforced the wrong privilege.Thread/get did not filter by per-mailbox ACLs on shared accounts.UID FETCH N:* could miss messages moved into a SELECTed mailbox by another connection.v=spf1 a -all records for apex domains.TXT records when they exceed 255 characters.defaultCertificateId when renewing a certificate that is currently set as default.DNS-01 authorizations sequentially to avoid race conditions in some DNS providers.replace action adds an extra From header.
The Stable channel has been updated to 148.0.7778.178/179 for Windows/MacΒ and 148.0.7778.178 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 16 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.
[N/A][504551032] Critical CVE-2026-9111: Use after free in WebRTC. Reported by Google on 2026-04-20
[N/A][503551154] Critical CVE-2026-9110: Inappropriate implementation in UI. Reported by Google on 2026-04-20
[$11000][489791425] High CVE-2026-9112: Use after free in GPU. Reported by c6eed09fc8b174b0f3eebedcceb1e792 on 2026-03-05
[$3000][489585044] High CVE-2026-9113: Out of bounds read in GPU. Reported by c6eed09fc8b174b0f3eebedcceb1e792 on 2026-03-04
[N/A][495798630] High CVE-2026-9114: Use after free in QUIC. Reported by Google on 2026-03-24
[N/A][495999481] High CVE-2026-9115: Insufficient policy enforcement in Service Worker. Reported by Google on 2026-03-25
[N/A][497436273] High CVE-2026-9116: Insufficient policy enforcement in ServiceWorker. Reported by Google on 2026-03-29
[N/A][497542537] High CVE-2026-9117: Type Confusion in GFX. Reported by Google on 2026-04-01
[N/A][498702233] High CVE-2026-9118: Use after free in XR. Reported by Google on 2026-04-14
[N/A][502661101] High CVE-2026-9119: Heap buffer overflow in WebRTC. Reported by Google on 2026-04-17
[N/A][504620824] High CVE-2026-9120: Use after free in WebRTC. Reported by Google on 2026-04-20
[N/A][496280532] Medium CVE-2026-9126: Use after free in DOM. Reported by Google on 2026-03-25
[TBD][488064108] Medium CVE-2026-9121: Out of bounds read in GPU. Reported by David Korczynski (Adalogics)Β on 2026-02-26
[TBD][489579953] Medium CVE-2026-9122: Out of bounds read in GPU. Reported by c6eed09fc8b174b0f3eebedcceb1e792 on 2026-03-04
[N/A][495988507] Medium CVE-2026-9123: Heap buffer overflow in Chromecast. Reported by Google on 2026-03-25
[N/A][496375695] Medium CVE-2026-9124: Insufficient validation of untrusted input in Input. Reported by Google on 2026-03-29
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
