CVE-2026-2329: The 64-Byte Stack That Answered the Phone

A pre-auth POST to /cgi-bin/api.values.get on a Grandstream GXP1600 VoIP phone smashes a 64-byte stack buffer in a root-owned CGI handler — a textbook unbounded copy that turns a desk phone into a root shell. CVSS 9.8, and the "fix reference" is a working exploit, not a patch.

The advisory in plain English

Grandstream's GXP16xx series (GXP1610/1615/1620/1625/1628/1630 — all one shared firmware image) exposes an HTTP "values" API. Hit the endpoint /cgi-bin/api.values.get with a crafted request parameter and you overflow a stack buffer inside the CGI binary, which Rapid7's Stephen Fewer (sfewer-r7) discovered runs as root. No credentials. Patched in firmware 1.0.7.81 (released January 30, 2026); everything below is vulnerable.

A note on sourcing, because it changes how to read this post. The repository I was handed is rapid7/metasploit-framework, and the linked PR (#20983) is the exploit module, not the vendor patch. The actual flawed function is compiled ARMv5 inside /app/bin/gs_web on the device — closed-source, not present here. I cannot read the vulnerable C. What I can read is the module the discoverer wrote, which documents the defect's shape precisely enough to reconstruct the lesson. Everything below is cited to that module at commit 08efa9cd.

The flawed function (as the exploit describes it)

The module tells us exactly how the target binary mishandles input. From modules/exploits/linux/http/grandstream_gxp1600_unauth_rce.rb @ 08efa9cd, L41:

'Privileged' => true, # /app/bin/gs_web runs as root

That comment is the whole reason this is a 9.8 and not a 7-point-something. The CGI that parses untrusted HTTP body runs in the most privileged context on the device.

The overflow target is a fixed 64-byte stack buffer. From …unauth_rce.rb @ 08efa9cd, L176:

overflow_buffer = Rex::Text.rand_text_alpha(64)

And the function's return path is the classic giveaway that the saved registers and return address sit just past that buffer. From …unauth_rce.rb @ 08efa9cd, L151:

# The vulnerable function returns via this function epilogue: POP {R4-R11,PC}

That epilogue is the signature of a function that spilled callee-saved registers R4–R11 plus the link register onto the stack on entry, then pops them back — including PC — on exit. Overrun the 64-byte buffer and you don't just corrupt locals; you overwrite eight saved registers and the program counter the function will jump to. The handler is, effectively, doing the moral equivalent of strcpy(buf, request) with no bound on request.

Why the check was insufficient

There was no bounds check worth the name. The request parameter is attacker-controlled and copied into a 64-byte frame buffer with a length the attacker chooses. That's the entire bug class in one sentence: the length came from the wire, the buffer was fixed, and nobody compared them.

But there's a subtler defect that the exploit leans on, and it's worth dwelling on because it reveals how the parser was written. The copy is null-terminated per field, and the input is treated as a colon-delimited list of identifiers. From …unauth_rce.rb @ 08efa9cd, L213:

# The vulnerability only allows for a single null terminator byte to be
# written during the overflow.

So each overflow event writes exactly one \x00 — the terminator the parser appends to the field it just processed. A single null byte is a miserable primitive for building an exploit payload full of zero bytes (ROP addresses on a 32-bit target are littered with nulls). The naive conclusion would be "this is hard to exploit reliably." It isn't, and the reason is instructive.

What the fix changed

The vendor's firmware 1.0.7.81 is the fix, and I want to be honest that I have not disassembled it — the binary isn't in this tree, and the sandbox is a source review, not a firmware diff. From the surrounding evidence, the corrective action is the obvious one: bound the copy into that 64-byte buffer (length-checked copy / reject oversized fields) so the saved-register/PC region is never reachable from request. The module's check method encodes the version boundary it expects the patch to land at — …unauth_rce.rb @ 08efa9cd, L104 compares the device's reported version against Rex::Version.new('1.0.7.81') and only flags older builds. That's the line in the sand.

What I can verify is how brittle exploitation of the unpatched binary is, and it's a nice illustration of why "hard to exploit" is not a security control. The discoverer chained the single-null-byte primitive into arbitrary null placement by re-triggering the overflow once per colon-delimited field, each pass laying down one terminator at a controlled offset. The module also ships a per-firmware-version table of ROP gadget addresses — a dozen-plus builds going back to a 2018 release — because the absence of ASLR-grade defenses in the binary means fixed offsets work. Two design facts (root CGI + no copy bounds) plus one parser quirk (per-field null write) compose into reliable root RCE. The "mitigations" were accidents of input format, and accidents don't hold.

A second tell: the module declares 'BadChars' => ':' (…unauth_rce.rb @ 08efa9cd, L59). The colon is special precisely because it's the field delimiter the vulnerable parser keys on — so it can't appear inside the payload. When your delimiter is your exploit's load-bearing wall, you're looking at a parser that conflated "tokenize" with "copy into a fixed frame."

The lesson

Three of them, really.

One: privilege is a multiplier, not a footnote. A 64-byte overflow in an unprivileged helper is a bug. The same overflow in a root CGI is a device takeover. gs_web parsing pre-auth HTTP as root is the architectural decision that set the blast radius. CGI handlers that touch untrusted bytes should drop privileges first; this one never did.

Two: "exploitation is fiddly" is not a defense. The single-null-byte write looks like it should frustrate attackers. It frustrated them for about as long as it took to realize the parser would happily re-run the overflow once per field. Defenders who bank on payload-construction friction are bringing inconvenience to a knife fight. The only real fix is making the corruption unreachable — bound the copy.

Three: fixed-size stack buffers fed by wire-length data are still, in 2026, the bug that pays the rent. The architecture is ARMv5 musl Linux on a desk phone, but the defect is the same one that's been on the OWASP-adjacent greatest-hits list since the Morris worm: a length the program trusted came from someone who wished it harm. The endpoint name even says values.get — it was supposed to get values, not take them.

If you ship embedded firmware: enumerate every binary that parses network input, find the ones running as root, and audit their copies first. That's where the 9.8s live.

References

• Rapid7 advisory: https://www.rapid7.com/blog/post/ve-cve-2026-2329-critical-unauthenticated-stack-buffer-overflow-in-grandstream-gxp1600-voip-phones-fixed
• Metasploit module PR #20983: https://github.com/rapid7/metasploit-framework/pull/20983
• Exploit module source (commit pin): https://github.com/rapid7/metasploit-framework/blob/08efa9cd16f254bfc8f2f4cee0550f3a851e0aa5/modules/exploits/linux/http/grandstream_gxp1600_unauth_rce.rb#L41
• Epilogue / 64-byte buffer notes: https://github.com/rapid7/metasploit-framework/blob/08efa9cd16f254bfc8f2f4cee0550f3a851e0aa5/modules/exploits/linux/http/grandstream_gxp1600_unauth_rce.rb#L151
• Single-null-byte primitive note: https://github.com/rapid7/metasploit-framework/blob/08efa9cd16f254bfc8f2f4cee0550f3a851e0aa5/modules/exploits/linux/http/grandstream_gxp1600_unauth_rce.rb#L213
• Vendor release notes (fixed 1.0.7.81): https://firmware.grandstream.com/Release_Note_GXP16xx_1.0.7.81.pdf
• Grandstream PSIRT: https://psirt.grandstream.com/