Red Hat Enterprise Linux 10: gdbserver Flaw Lets Unauthenticated Attackers Run Code Remotely (CVE-2026-121997), Plus Four More GDB Bugs

Cyber · 2026-11-05 · By H.A

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 QTDPsrc packet handler. The packet declares a source length that does not match the data actually sent. The hex2bin routine 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 :port or --multi running 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

1. Find running gdbserver instances and stop any you do not need:

ss -ltnp | grep -i gdbserver
pgrep -a gdbserver

1. 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.
2. Block debug ports at the host firewall and in security groups, and add an alert for listening gdbserver processes on servers.
3. Remove the package where it isn't needed: dnf remove gdb-gdbserver on production systems.
4. 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.