Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
VDS.net
InterServer VPS
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
CloudLinux
MeduzaVPN
Servury - Anonymous & Privacy-focused VPS Hosting
Animated Silicon Kiwi cloud ad featuring VPS from $4.90/month, 100 GB S3 storage from $1.49/month, Kiwi Apps from $12/month and cloud backup from $3/month

Categories

In this Discussion

Home › News › Security
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Another guest-to-host escape: "Pwnscape" (CVE-2026-99999, CVSS 9.3)

forestforest Member
edited October 16 in Security

By passing a malformed packet up VirtIO to the checksum offloader in the host kernel, a guest can achieve arbitrary code execution in the host by corrupting the network header. Virtually all KVM providers are affected.

All affected providers should upgrade as soon as possible.

Interesting details about the escape and its discovery:
https://pwn.ai/blog/pwnescape
https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge

Debian security tracker:
https://security-tracker.debian.org/tracker/CVE-2026-99999

And the CVE announcement:
https://lore.kernel.org/linux-cve-announce/2026101533-CVE-2026-99999-beee@gregkh/T/#u

Contents of CVE announcement (click to expand)

From: Greg Kroah-Hartman <[email protected]>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

ipv4: validate checksum_start before completing checksum

If a packet with bad checksum metadata gets into the ipv4 stack,
skb_checksum_help can corrupt the network header and cause a bunch of
mischief.

This was discovered and reported by Paulos, and has been reporoduced
by others independently since.

We really shouldn't allow such packets in, but as a defence
in depth measure, let's also check before we complete the checksum.

A more complete validation at input is forthcoming, but needs more work.

The Linux kernel CVE team has assigned CVE-2026-99999 to this issue.


Severity
========

  CVSS v3.1: 9.3 CRITICAL
  Vector:    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H


Affected and fixed versions
===========================

    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 5.10.272 with commit a464d950f31c89565cbaae038cc60db04fe01956
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 5.15.223 with commit 0fab003ef4698e0628060a45a48f14b43ba2a40a
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.1.190 with commit 94524b7b32691de2e2ce162c04d6cbc9106e5cbf
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.6.159 with commit a65f69e0f38ffbed1b128029e09097436416dc8b
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.12.113 with commit 32a8b0adaa18e52aaa0b246b5ffe683075354dbb
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.18.57 with commit f3e835af6226f1dd12160cbd696081e9b6155de0
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 7.2.11 with commit c3e33464746166264334641dc850a36eef7e6326
    Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 7.3-rc7 with commit 6785011f8b16abf40b1e9d8b2e332232b3e68822

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
    https://cve.org/CVERecord/?id=CVE-2026-99999
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
    include/net/ip.h
    net/bridge/netfilter/nf_conntrack_bridge.c
    net/ipv4/ip_output.c
    net/netfilter/nfnetlink_queue.c
    net/netfilter/xt_CHECKSUM.c
    net/xfrm/xfrm_output.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
    https://git.kernel.org/stable/c/a464d950f31c89565cbaae038cc60db04fe01956
    https://git.kernel.org/stable/c/0fab003ef4698e0628060a45a48f14b43ba2a40a
    https://git.kernel.org/stable/c/94524b7b32691de2e2ce162c04d6cbc9106e5cbf
    https://git.kernel.org/stable/c/a65f69e0f38ffbed1b128029e09097436416dc8b
    https://git.kernel.org/stable/c/32a8b0adaa18e52aaa0b246b5ffe683075354dbb
    https://git.kernel.org/stable/c/f3e835af6226f1dd12160cbd696081e9b6155de0
    https://git.kernel.org/stable/c/c3e33464746166264334641dc850a36eef7e6326
    https://git.kernel.org/stable/c/6785011f8b16abf40b1e9d8b2e332232b3e68822
    https://pwn.ai/blog/Pwnescape
    https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge

Thanked by 22nghialele Ssre tzuli rpqu frodothebearer Murv deafcon Hitori0221 JohnnySac bugabuga sh97 nullnothere Killix WyvernCo mandala BasToTheMax jsg Porlam jfrac layer7 TimboJones HostDZire
«1

Comments

  • deafcondeafcon Member

    Fuck?

    Thanked by 9monsoon73 rpqu forest bugabuga Nekopara WyvernCo meowwcc BasToTheMax Porlam
  • FubukiFubuki Member

    Another day

  • rpqurpqu Member

    Fuck indeed

    Thanked by 7forest mans_xd frodothebearer deafcon bugabuga WyvernCo BasToTheMax
  • forestforest Member
    edited October 16

    As of this comment, all Debian kernels are vulnerable.

    Switching all VMs to use e1000 would probably mitigate the issue, but would come with a massive performance hit in the form of high CPU overhead for networking and would require a reboot of all guests.

    Maybe adding csum=off,guest_csum=off to the QEMU virtio-net-pci device would mitigate it? But I don't know if that actually prevents a checksummed packet with NEEDS_CSUM from being processed by the vulnerable vNIC checksum offload code or if it just hides that capability from a well-behaved guest.

    Thanked by 1WyvernCo
  • servuryservury Member, Patron Provider

    fuck

    Thanked by 3forest deafcon bugabuga
  • ScreenReaderScreenReader Member

    Y 404?

  • forestforest Member

    @ScreenReader said:
    Y 404?

    Typo in original. It's https://pwn.ai/blog/pwnescape (lowercase "p").

  • rpqurpqu Member

    @forest said:

    @ScreenReader said:
    Y 404?

    Typo in original. It's https://pwn.ai/blog/pwnescape (lowercase "p").

    @angstrom

  • yoursunnyyoursunny Member, IPv6 Advocate

    GLWR

    R = Reboots

    Thanked by 4rpqu JohnnySac forest averagedatahoarder
  • ScreenReaderScreenReader Member

    @forest said:

    @ScreenReader said:
    Y 404?

    Typo in original. It's https://pwn.ai/blog/pwnescape (lowercase "p").

    gracias https://archive.is/81MXt

  • servers_guruservers_guru Member, Patron Provider

    Great...
    fleet wide reboot incoming..

    Thanked by 1forest
  • JohnnySacJohnnySac Member

    Ah man, another one :|

    Thanked by 1Arirang
  • forestforest Member
    edited October 16

    @servers_guru said:
    Great...
    fleet wide reboot incoming..

    Probably not too difficult to write a livepatch for this particular vuln, actually.

    A reboot is still better though, since it'll be fixing the hundreds of other (albeit less severe) bugs that have surely accumulated.

    And as annoying as these are, it's not like it didn't exist before its discovery. It was always there.

  • servers_guruservers_guru Member, Patron Provider

    @forest said:

    @servers_guru said:
    Great...
    fleet wide reboot incoming..

    Probably not too difficult to write a livepatch for this particular vuln, actually.

    A reboot is still better though, since it'll be fixing the hundreds of other (albeit less severe) bugs that have surely accumulated.

    And as annoying as these are, it's not like it didn't exist before its discovery. It was always there.

    We have already upgraded most of the fleet following the last few vulnerabilities. But we managed to do it without reboot.

    This time though it won't be possible, not enough spare room on most clusters.

    It seems there is already a kernel fix available so no need for patching.

  • brodiechilliambrodiechilliam Member

    @forest said:
    By passing a malformed packet up VirtIO to the checksum offloader in the host kernel, a guest can achieve arbitrary code execution in the host by corrupting the network header. Virtually all KVM providers are affected.

    All affected providers should upgrade as soon as possible.

    Interesting details about the escape and its discovery:
    https://pwn.ai/blog/Pwnescape
    https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge

    Debian security tracker:
    https://security-tracker.debian.org/tracker/CVE-2026-99999

    And the CVE announcement:
    https://lore.kernel.org/linux-cve-announce/2026101533-CVE-2026-99999-beee@gregkh/T/#u

    Contents of CVE announcement (click to expand)

    From: Greg Kroah-Hartman <[email protected]>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

ipv4: validate checksum_start before completing checksum

If a packet with bad checksum metadata gets into the ipv4 stack,
skb_checksum_help can corrupt the network header and cause a bunch of
mischief.

This was discovered and reported by Paulos, and has been reporoduced
by others independently since.

We really shouldn't allow such packets in, but as a defence
in depth measure, let's also check before we complete the checksum.

A more complete validation at input is forthcoming, but needs more work.

The Linux kernel CVE team has assigned CVE-2026-99999 to this issue.


Severity
========

  CVSS v3.1: 9.3 CRITICAL
  Vector:    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H


Affected and fixed versions
===========================

  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 5.10.272 with commit a464d950f31c89565cbaae038cc60db04fe01956
  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 5.15.223 with commit 0fab003ef4698e0628060a45a48f14b43ba2a40a
  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.1.190 with commit 94524b7b32691de2e2ce162c04d6cbc9106e5cbf
  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.6.159 with commit a65f69e0f38ffbed1b128029e09097436416dc8b
  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.12.113 with commit 32a8b0adaa18e52aaa0b246b5ffe683075354dbb
  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 6.18.57 with commit f3e835af6226f1dd12160cbd696081e9b6155de0
  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 7.2.11 with commit c3e33464746166264334641dc850a36eef7e6326
  Issue introduced in 2.6.27 with commit f43798c27684ab925adde7d8acc34c78c6e50df8 and fixed in 7.3-rc7 with commit 6785011f8b16abf40b1e9d8b2e332232b3e68822

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
  https://cve.org/CVERecord/?id=CVE-2026-99999
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
  include/net/ip.h
  net/bridge/netfilter/nf_conntrack_bridge.c
  net/ipv4/ip_output.c
  net/netfilter/nfnetlink_queue.c
  net/netfilter/xt_CHECKSUM.c
  net/xfrm/xfrm_output.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
  https://git.kernel.org/stable/c/a464d950f31c89565cbaae038cc60db04fe01956
  https://git.kernel.org/stable/c/0fab003ef4698e0628060a45a48f14b43ba2a40a
  https://git.kernel.org/stable/c/94524b7b32691de2e2ce162c04d6cbc9106e5cbf
  https://git.kernel.org/stable/c/a65f69e0f38ffbed1b128029e09097436416dc8b
  https://git.kernel.org/stable/c/32a8b0adaa18e52aaa0b246b5ffe683075354dbb
  https://git.kernel.org/stable/c/f3e835af6226f1dd12160cbd696081e9b6155de0
  https://git.kernel.org/stable/c/c3e33464746166264334641dc850a36eef7e6326
  https://git.kernel.org/stable/c/6785011f8b16abf40b1e9d8b2e332232b3e68822
  https://pwn.ai/blog/Pwnescape
  https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge

    not surprised

  • brodiechilliambrodiechilliam Member

    @forest said:
    As of this comment, all Debian kernels are vulnerable.

    Switching all VMs to use e1000 would probably mitigate the issue, but would come with a massive performance hit in the form of high CPU overhead for networking and would require a reboot of all guests.

    Maybe adding csum=off,guest_csum=off to the QEMU virtio-net-pci device would mitigate it? But I don't know if that actually prevents a checksummed packet with NEEDS_CSUM from being processed by the vulnerable vNIC checksum offload code or if it just hides that capability from a well-behaved guest.

    good thing i use rhel and ubuntu enterprise

  • forestforest Member

    @brodiechilliam said:

    @forest said:
    As of this comment, all Debian kernels are vulnerable.

    Switching all VMs to use e1000 would probably mitigate the issue, but would come with a massive performance hit in the form of high CPU overhead for networking and would require a reboot of all guests.

    Maybe adding csum=off,guest_csum=off to the QEMU virtio-net-pci device would mitigate it? But I don't know if that actually prevents a checksummed packet with NEEDS_CSUM from being processed by the vulnerable vNIC checksum offload code or if it just hides that capability from a well-behaved guest.

    good thing i use rhel and ubuntu enterprise

    Fedora just released a fix, but RHEL has not yet and neither has Ubuntu.

    Thanked by 2WyvernCo jsg
  • MainfrezzerMainfrezzer Member
    edited October 16

    guess all my vps will have some fun, thank god im using emulated devices on my other crap. e1000 for the rescue xD

  • angstromangstrom Moderator, Veteran

    @rpqu said:

    @forest said:

    @ScreenReader said:
    Y 404?

    Typo in original. It's https://pwn.ai/blog/pwnescape (lowercase "p").

    @angstrom

    Corrected

    Thanked by 3rpqu forest eliphas
  • mrerenkmrerenk Member

    @NovaCloudHosting seems to have already fixed it but my vps cannot boot so created a ticket. Email:

    Dear Customer,

To address CVE-2026-99999, we have scheduled emergency maintenance on selected hypervisor and game server nodes in both of our locations at short notice.

Scheduled time: 15 October 2026, 22:45 (UTC+2)

Expected impact:
Affected services may experience a short downtime due to host reboots. The following services may be affected:

Standard VPS (NL + de)
Premium VPS (NL only)
High-End VPS (NL only)
Storage VPS
Storage-Box
Game-Servers
Webspaces
Discord Bot instances

The estimated outage per affected VPS is approximately 10–15 minutes within the maintenance window.
No action is required on your side.

We understand that short-notice maintenance can be inconvenient and sincerely appreciate your understanding as we carry out this work to ensure the continued security and stability of our infrastructure.
  • ScreenReaderScreenReader Member
    edited October 16

    @mrerenk said:
    @NovaCloudHosting seems to have already fixed it but my vps cannot boot so created a ticket.

    doing a reboot feels like isn't a strong point for them. i have one vps in NL and i think this is already the 3rd time novacloudhosting had a botched reboot. if it's night time in my timezone then had to wait until next morning, manually start it, if lucky it can start again.

    i know proxmox can behave funny sometimes with certain storage, but if it's just a reboot why not sit and wait a bit and see if there's still clients vps having failed reboot? that's like basic todo list when you have to do update & reboot on production servers.

    edit: also just noticed apparently my ssh host key has been changed, that is very weird

    Thanked by 2mrerenk forest
  • stable_geniusstable_genius Member

    @forest said:

    @brodiechilliam said:

    @forest said:
    As of this comment, all Debian kernels are vulnerable.

    Switching all VMs to use e1000 would probably mitigate the issue, but would come with a massive performance hit in the form of high CPU overhead for networking and would require a reboot of all guests.

    Maybe adding csum=off,guest_csum=off to the QEMU virtio-net-pci device would mitigate it? But I don't know if that actually prevents a checksummed packet with NEEDS_CSUM from being processed by the vulnerable vNIC checksum offload code or if it just hides that capability from a well-behaved guest.

    good thing i use rhel and ubuntu enterprise

    Fedora just released a fix, but RHEL has not yet and neither has Ubuntu.

    Use almalinux.

  • mrerenkmrerenk Member

    @ScreenReader said:

    @mrerenk said:
    @NovaCloudHosting seems to have already fixed it but my vps cannot boot so created a ticket.

    doing a reboot feels like isn't a strong point for them. i have one vps in NL and i think this is already the 3rd time novacloudhosting had a botched reboot. if it's night time in my timezone then had to wait until next morning, manually start it, if lucky it can start again.

    i know proxmox can behave funny sometimes with certain storage, but if it's just a reboot why not sit and wait a bit and see if there's still clients vps having failed reboot? that's like basic todo list when you have to do update & reboot on production servers.

    edit: also just noticed apparently my ssh host key has been changed, that is very weird

    Turns out it was because some Debian kernel versions were incompatible with a specific virtualization setting on their side. Fixed now tho

  • yoursunnyyoursunny Member, IPv6 Advocate

    We disabled IPv4 on all the hypervisors.
    No IPv4 header, no vulnerability.

    Thanked by 7mrerenk itzsenu HostDZire itzgeo Zappie JohnnySac miHoYo
  • OhJohnOhJohn Member

    @mrerenk said: Turns out it was because some Debian kernel versions were incompatible with a specific virtualization setting on their side. Fixed now tho

    Had they been specific in their reply? So e.g. which kernel versions are affected (or maybe even the virtualization setting they have)?

  • mrerenkmrerenk Member
    edited October 16

    @OhJohn said:

    @mrerenk said: Turns out it was because some Debian kernel versions were incompatible with a specific virtualization setting on their side. Fixed now tho

    Had they been specific in their reply? So e.g. which kernel versions are affected (or maybe even the virtualization setting they have)?

    Nope. Just this:

    Hi,

This was caused because your OS loaded a new Kernel version, since the VPS was rebooted. This is just an incompatibility between some Debian Kernel versions and a specific virtualization setting on our side. No worries, I have changed the setting and your VPS is now up and running again!

Please let me know in case you experience any other issues.

    If im not mistaken I installed the backport kernel before the maintenance (6.12 something)

    Thanked by 1OhJohn
  • NeoonNeoon Community Contributor, Veteran

    Package : linux
    CVE ID : CVE-2025-38204 CVE-2025-40158 CVE-2026-52988 CVE-2026-72315
    CVE-2026-72463 CVE-2026-74347 CVE-2026-80935 CVE-2026-80937
    CVE-2026-80939 CVE-2026-80980 CVE-2026-81016 CVE-2026-89437
    CVE-2026-89441 CVE-2026-89445 CVE-2026-89452 CVE-2026-89467
    CVE-2026-89500 CVE-2026-89503 CVE-2026-89520 CVE-2026-89527
    CVE-2026-89633 CVE-2026-89638 CVE-2026-89766 CVE-2026-89795
    CVE-2026-89797 CVE-2026-89806 CVE-2026-89827 CVE-2026-89832
    CVE-2026-89837 CVE-2026-89838 CVE-2026-89840 CVE-2026-89859
    CVE-2026-89868 CVE-2026-89912 CVE-2026-89921 CVE-2026-89956
    CVE-2026-89971 CVE-2026-89972 CVE-2026-89996 CVE-2026-90002
    CVE-2026-90013 CVE-2026-90016 CVE-2026-90023 CVE-2026-90029
    CVE-2026-90030 CVE-2026-90146 CVE-2026-93179 CVE-2026-93196
    CVE-2026-93199 CVE-2026-93200 CVE-2026-93231 CVE-2026-93243
    CVE-2026-93244 CVE-2026-93285 CVE-2026-97527 CVE-2026-97528
    CVE-2026-97529 CVE-2026-97530 CVE-2026-97531 CVE-2026-97532
    CVE-2026-97534 CVE-2026-97535 CVE-2026-97536 CVE-2026-97537
    CVE-2026-97549 CVE-2026-97558 CVE-2026-97559 CVE-2026-97566
    CVE-2026-97567 CVE-2026-97571 CVE-2026-97574 CVE-2026-97594
    CVE-2026-97597 CVE-2026-97603 CVE-2026-97609 CVE-2026-97615
    CVE-2026-97618 CVE-2026-97619 CVE-2026-97620 CVE-2026-97901
    CVE-2026-97906 CVE-2026-97918 CVE-2026-97919 CVE-2026-97933
    CVE-2026-97934 CVE-2026-97935 CVE-2026-97938 CVE-2026-97939
    CVE-2026-97949 CVE-2026-97950 CVE-2026-98101 CVE-2026-98161
    CVE-2026-98167 CVE-2026-98168 CVE-2026-98169 CVE-2026-98170
    CVE-2026-98171 CVE-2026-98172 CVE-2026-98173 CVE-2026-98174
    CVE-2026-98175 CVE-2026-98179 CVE-2026-98181 CVE-2026-98182
    CVE-2026-98184 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187
    CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191
    CVE-2026-98192 CVE-2026-98193 CVE-2026-98194 CVE-2026-98195
    CVE-2026-98196 CVE-2026-98197 CVE-2026-98198 CVE-2026-98199
    CVE-2026-98200 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203
    CVE-2026-98204 CVE-2026-98205 CVE-2026-98206 CVE-2026-98207
    CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98211
    CVE-2026-98212 CVE-2026-98213 CVE-2026-98214 CVE-2026-98215
    CVE-2026-98216 CVE-2026-98217 CVE-2026-98218 CVE-2026-98221
    CVE-2026-98222 CVE-2026-98227 CVE-2026-98229 CVE-2026-98230
    CVE-2026-98231 CVE-2026-98232 CVE-2026-98233 CVE-2026-98234
    CVE-2026-98235 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238
    CVE-2026-98239 CVE-2026-98241 CVE-2026-98245 CVE-2026-98246
    CVE-2026-98247 CVE-2026-98248 CVE-2026-98249 CVE-2026-98251
    CVE-2026-98252 CVE-2026-98253 CVE-2026-98254 CVE-2026-98255
    CVE-2026-98257 CVE-2026-98260 CVE-2026-98261 CVE-2026-98262
    CVE-2026-98263 CVE-2026-98264 CVE-2026-98265 CVE-2026-98266
    CVE-2026-98267 CVE-2026-98269 CVE-2026-98270 CVE-2026-98271
    CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282
    CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98291
    CVE-2026-98293 CVE-2026-98295 CVE-2026-98297 CVE-2026-98298
    CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302
    CVE-2026-98303 CVE-2026-98306 CVE-2026-98307 CVE-2026-98308
    CVE-2026-98309 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314
    CVE-2026-98316 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322
    CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98327
    CVE-2026-98328 CVE-2026-98329 CVE-2026-98331 CVE-2026-98334
    CVE-2026-98335 CVE-2026-98336 CVE-2026-98337 CVE-2026-98339
    CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344
    CVE-2026-98345 CVE-2026-98346 CVE-2026-98347 CVE-2026-98348
    CVE-2026-98349 CVE-2026-98351 CVE-2026-98352 CVE-2026-98354
    CVE-2026-98357 CVE-2026-98358 CVE-2026-98359 CVE-2026-98360
    CVE-2026-98362 CVE-2026-98363 CVE-2026-98365 CVE-2026-98366
    CVE-2026-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370
    CVE-2026-98373 CVE-2026-98374 CVE-2026-98375 CVE-2026-98377
    CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381
    CVE-2026-98382 CVE-2026-98383 CVE-2026-98384 CVE-2026-98386
    CVE-2026-98403 CVE-2026-98406 CVE-2026-98407 CVE-2026-98409
    CVE-2026-98410 CVE-2026-98411 CVE-2026-98412 CVE-2026-98413
    CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421
    CVE-2026-98422 CVE-2026-98423 CVE-2026-98425 CVE-2026-98426
    CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432
    CVE-2026-99999
    Debian Bug : 1149499 1149564 1150891

    Thanked by 2jsg WyvernCo
  • sillycatsillycat Member

    Lucky number.

  • TimboJonesTimboJones Member

    @yoursunny said:
    We disabled IPv4 on all the hypervisors.
    No IPv4 header, no vulnerability.

    Next week will be malformed IPv6 CVE.

  • forestforest Member

    Fixed now in Debian with kernel 6.12.113-1.

    Thanked by 3iriska WyvernCo mrerenk
Sign In or Register to comment.