Red Hat Enterprise Linux 10: gdbserver Flaw Lets Unauthenticated Attackers Run Code Remotely (CVE-2026-121997), Plus Four More GDB Bugs
A heap overflow in gdbserver gives anyone who can reach its port code execution, and four related GDB bugs hit debuggers that connect to malicious targets, with no fix shipped yet.
What Happened
Red Hat has disclosed a group of vulnerabilities in the GNU debugger (GDB) and its remote companion gdbserver, as shipped in Red Hat Enterprise Linux 10. The most serious, CVE-2026-121997, lets an unauthenticated remote attacker run code inside a gdbserver process simply by sending it a crafted packet. Red Hat rates it Important, with a preliminary CVSS score of 8.1.
Four related bugs were published on 5 November 2026 alongside it. One more gdbserver flaw leaks memory that helps attackers defeat ASLR (address space layout randomisation). The other three are stack overflows in the GDB client that a malicious debug target can trigger. According to Red Hat, the issue was reported on 21 October and made public on 5 November.
Technical Details
The gdbserver bugs: attacker connects to you
- CVE-2026-121997 (High): a heap buffer overflow in gdbserver's
QTDPsrcpacket handler. The packet declares a source length that does not match the data actually sent. Thehex2binroutine then writes past the end of the heap buffer, giving native code execution in the gdbserver process. - CVE-2026-121996 (High): a length validation flaw in gdbserver's agent-expression parser. A remote attacker can read uninitialised heap memory and crash the server. The leaked data includes memory addresses that make further exploitation, such as chaining with CVE-2026-121997, more reliable.
gdbserver has no authentication at all. Anyone who can reach its TCP port can talk to it, so Red Hat notes the only thing limiting exposure is network access to that port.
The GDB client bugs: you connect to an attacker
- CVE-2026-121994 (High): a stack buffer overflow in
fetch_register_using_p. A malicious debug target can send an oversized register reply and run code in the GDB process. - CVE-2026-121995 (High): a stack buffer overflow in the tracepoint upload handler. It triggers automatically during connection setup, before the user does anything.
- CVE-2026-123151: another stack overflow while parsing a remote target's replies. It can crash GDB or potentially run code with the privileges of the user running the debugger.
Who Is Affected
gdbserver is a debugging tool. It does not run on a normal server unless someone starts it, so most production RHEL 10 systems are not exposed. The real risk is in places where it is started and forgotten:
- development and test machines where someone left
gdbserver :portor--multirunning for remote debugging - CI runners, lab VMs and containers that expose a debug port
- embedded and appliance development setups that debug over the network
The client-side bugs affect developers and analysts who connect GDB to a remote target they do not fully trust. That includes embedded devices, third-party hardware, malware analysis sandboxes and CTF or training targets.
Red Hat filed the CVEs against RHEL 10. Third-party trackers list the same gdbserver flaw against older RHEL releases too, so check Red Hat's CVE pages for the exact status of the versions you run.
Patch Status
At the time of writing, Red Hat states there is no mitigation inside gdbserver itself. Fixed gdb and gdb-gdbserver packages had not yet been announced. Watch Red Hat's errata for the gdb package and update as soon as they ship with dnf update gdb gdb-gdbserver.
What To Do Now
- Find running gdbserver instances and stop any you do not need:
ss -ltnp | grep -i gdbserver
pgrep -a gdbserver- Never expose gdbserver to untrusted networks. Bind it to localhost (
gdbserver 127.0.0.1:2345 ...) and reach it through an SSH tunnel (ssh -L 2345:127.0.0.1:2345 host) instead of opening the port. - Block debug ports at the host firewall and in security groups, and add an alert for listening gdbserver processes on servers.
- Remove the package where it isn't needed:
dnf remove gdb-gdbserveron production systems. - Be careful what you attach GDB to. Until fixed packages arrive, avoid connecting GDB to remote targets you do not control, or do it from a disposable VM.
Why It Matters
Debugging tools are easy to overlook in vulnerability management because they "only run sometimes". A gdbserver left listening on a network port is an unauthenticated remote shell waiting to happen, and this bug removes the need for an attacker to know anything about the program being debugged.
The client-side bugs are a reminder that the debugger trusts whatever it connects to. That matters more and more as teams debug cloud VMs, embedded devices and untrusted samples remotely.
