Your Office Phone Is a Spy: CVE-2026-2329 and the Grandstream Vulnerability Explained

A desk phone sits in the corner of your conference room. It has been there for years — trusted, forgotten, ignored. It connects to your internal network, shares the same VLAN as your servers, and nobody has touched its settings since it was plugged in. That phone may now be a door wide open to attackers. CVE-2026-2329, disclosed on February 18, 2026, is a critical unauthenticated vulnerability in the Grandstream GXP1600 series of VoIP phones that allows a remote attacker to take complete root-level control of the device, harvest credentials, and silently intercept phone calls — all without a single valid login.

CVE ID	CVE-2026-2329
CVSS v4 Score	9.3 — Critical
Vulnerability Type	Stack-based Buffer Overflow (CWE-121)
Authentication Required	None
Affected Devices	Grandstream GXP1610, GXP1615, GXP1620, GXP1625, GXP1628, GXP1630
Vulnerable Firmware	Version 1.0.7.79 and earlier
Fixed Firmware	Version 1.0.7.81
Discovered By	Stephen Fewer, Senior Principal Security Researcher at Rapid7
Public Disclosure	February 18, 2026
PoC / Exploit	Metasploit module publicly available

Researchers at Rapid7 Labs published their findings on February 18, 2026, following a responsible disclosure process that began on January 6, 2026, when researcher Stephen Fewer first reported the flaw to Grandstream. The vulnerability had already been patched in firmware version 1.0.7.81 by the time full technical details and working exploit code were made public. That sequence matters, but it does not reduce the urgency — many of these phones likely remain unpatched in the field, and the Metasploit exploit modules are now publicly available for anyone to run.

What Is This Vulnerability and Why Does It Matter?

CVE-2026-2329 is a stack-based buffer overflow affecting the web-based API service built into Grandstream GXP1600 series desk phones. The flaw is classified under CWE-121 (Stack-based Buffer Overflow) and carries a CVSSv4 score of 9.3, placing it firmly in the Critical severity tier. To put that in plain terms: this is about as bad as a vulnerability gets without requiring physical access to the device.

What makes it particularly alarming is that the vulnerable endpoint requires no authentication. An attacker does not need a username, a password, a token, or any kind of credential. The flaw lives in a web API that is exposed by default on every phone in the GXP1600 family — meaning a device fresh out of the box and plugged into your network is already vulnerable.

"The vulnerability is present in the device's web-based API service, and is accessible in a default configuration." — Stephen Fewer, Senior Principal Security Researcher, Rapid7 (Rapid7 Blog, February 18, 2026)

The vulnerable API endpoint is /cgi-bin/api.values.get, which listens on TCP port 80 by default. This endpoint is designed to let callers retrieve configuration values from the phone — things like the firmware version number or the device model name. The problem is in how it processes those requests.

How the Attack Actually Works

To understand the flaw technically, you need to understand what the endpoint does and how it fails. The /cgi-bin/api.values.get API accepts an HTTP POST parameter called request. That parameter is supposed to contain a colon-delimited list of configuration identifiers. For example, a legitimate request might look like this:

curl -ik http://[phone-ip]/cgi-bin/api.values.get --data "request=68:phone_model"

The API processes each identifier by parsing the input character by character, copying characters into a small 64-byte buffer on the stack until it hits a colon delimiter or reaches the end of the input. The critical failure is here: at no point does the code check whether the data being copied into that 64-byte buffer actually fits within it. No bounds check. No length validation. Nothing.

According to Rapid7's technical write-up, the vulnerable function copies characters into small_buffer[64] one at a time without ever verifying that part_length stays below 63. An attacker who sends a request parameter longer than 64 bytes writes past the end of that buffer and into adjacent stack memory — a textbook stack-based buffer overflow.

What makes the exploitation especially clever is how Rapid7's researcher solved the null-byte problem. Because the binary is not PIE, its code segment is loaded at a virtual address of 0x00008000, meaning every ROP gadget address within gs_web contains at least one null byte. Normally this would stop a basic string-based overflow dead in its tracks, since null bytes terminate C strings. Fewer's solution was elegant: since the API processes a colon-delimited string and writes a single null terminator after each segment, the attacker can trigger the overflow multiple times in a single request — once per colon-separated identifier — placing null bytes precisely where needed in the constructed ROP chain.

"Finally, we can leverage our RCE capabilities to reconfigure the target device to use a malicious SIP proxy, allowing an attacker to transparently intercept phone calls to and from the device, and eavesdrop on the audio." — Stephen Fewer, Rapid7 (Rapid7 Blog, February 18, 2026)

The result is reliable, unauthenticated remote code execution with root privileges. Rapid7 demonstrated this with a working Metasploit exploit module — tested against a GXP1630 running firmware 1.0.7.79 — that produces a full Meterpreter shell on the device, confirmed by running arbitrary OS commands as root.

What Attackers Can Do Once Inside

Root access on a VoIP phone is not a minor incident. These devices sit inside corporate networks with trusted access to voice infrastructure, and they store credentials that open doors well beyond the phone itself. Rapid7 demonstrated three specific post-exploitation capabilities, each released as its own Metasploit module alongside the initial exploit module.

1. Credential Theft

A companion post-exploitation Metasploit module — released alongside the exploit module — can extract credentials stored on a compromised GXP1600 device. This includes local administrator account passwords and SIP account credentials. SIP credentials are particularly valuable: they authenticate the phone to the organization's voice infrastructure and, in many deployments, are reused or allow access to PBX systems, call routing, and other internal telephony services. Harvested credentials can fuel further lateral movement across the network.

2. Silent Call Interception

With root access, an attacker can reconfigure the phone to route all calls through an attacker-controlled SIP proxy server. Session Initiation Protocol (SIP) is the signaling standard used by VoIP systems to set up and tear down calls. By redirecting the phone's SIP registrar to a malicious proxy, the attacker becomes a transparent man-in-the-middle for every call the device makes or receives. The phone continues to function normally. Calls go through. Nothing looks wrong to the user. But the audio stream — the actual conversation — is being captured and forwarded by the attacker in real time.

3. Long-Term Covert Access

With root access, an attacker can also modify firmware or device files to establish persistence. VoIP phones are rarely rebooted, rarely monitored by endpoint security tools, and rarely included in vulnerability scan scopes. A compromised phone could serve as a persistent foothold inside a corporate network for months or years without detection.

"This lowers the barrier in a way that should concern anyone operating these devices in exposed or lightly-segmented environments." — Douglas McKee, Director of Vulnerability Intelligence, Rapid7 (Rapid7 Blog, February 18, 2026)

Who Is Affected?

All six models in the Grandstream GXP1600 series are affected: the GXP1610, GXP1615, GXP1620, GXP1625, GXP1628, and GXP1630. Because every model in this product line shares a single common firmware image, no device in the family was spared. Any of these phones running firmware version 1.0.7.79 or earlier is vulnerable.

The GXP1600 series is a widely-deployed line of entry-level and mid-tier desk phones aimed at small offices and enterprise deployments. These phones are common in reception areas, conference rooms, open-plan offices, and remote employee setups. They are frequently left on internal networks with web management enabled and forgotten about. Some organizations also expose the management interface to the internet to support remote administration — a configuration that removes the attacker's last barrier entirely.

Because the Metasploit exploit modules are now publicly available, the sophistication bar for exploitation is meaningfully low. An attacker with basic familiarity with Metasploit could run this exploit against any reachable vulnerable phone today. The window between Rapid7's public disclosure and widespread attacker awareness is essentially closed.

Responsible Disclosure: How This Came to Light

This vulnerability was handled through a coordinated responsible disclosure process. The timeline, published by Rapid7, is as follows:

• January 6, 2026: Stephen Fewer of Rapid7 makes initial contact with Grandstream to report the vulnerability.
• January 20, 2026: After no initial response, Rapid7 follows up. Grandstream replies the same day.
• January 21, 2026: Rapid7 and Grandstream establish a secure communication channel.
• January 22, 2026: Rapid7 provides the full technical write-up and proof-of-concept exploit code to Grandstream, who confirms receipt.
• February 2, 2026: Grandstream notifies Rapid7 that a patch is available in firmware version 1.0.7.81.
• February 3, 2026: Grandstream reaffirms the fix is complete in 1.0.7.81.
• February 6, 2026: Rapid7 indicates to Grandstream that a CVE has not been assigned and offers to be the CNA for this disclosure. Rapid7 highlights that no public disclosure has occurred, and that it is Rapid7's intention to disclose publicly in the coming days.
• February 7, 2026: Grandstream agrees that Rapid7 can be the CNA and requests additional CVE record information.
• February 11, 2026: Rapid7 provides the requested CVE record information to Grandstream. Rapid7 confirms that firmware version 1.0.7.81 does remediate the vulnerability, as shown by Rapid7 Labs reverse engineering the publicly available firmware. Rapid7 sets February 18, 2026 as the public disclosure date.
• February 18, 2026: Full public disclosure, including technical analysis and Metasploit modules.

From first contact to patch availability was roughly 27 days. From patch availability to public disclosure was another 16 days, during which Rapid7 and Grandstream coordinated CVE assignment and validated the fix. That is a reasonably tight and professional timeline on both sides. Grandstream earned credit here for responding and shipping a fix before details went public. The challenge now is getting that fix applied to the devices actually deployed in the field.

What You Should Do Right Now

If your organization uses any Grandstream GXP1600 series phone, this is not a vulnerability you can schedule for the next quarterly patch cycle. The Metasploit modules are public. The technical details are public. The fix exists and is free. Here is what to do:

Update Firmware Immediately

Upgrade all affected devices to firmware version 1.0.7.81 or later. Grandstream's latest firmware for the GXP1600 series is available directly from their support portal at grandstream.com/support/firmware. The direct download URL for the patched release is https://firmware.grandstream.com/Release_GXP16xx_1.0.7.81.zip. For additional vendor guidance and the official security advisory, see Grandstream's PSIRT page.

Inventory Your Devices

If you do not have a current, accurate inventory of every VoIP device on your network, this is the moment to build one. Use network scanners or your IPAM system to identify every Grandstream device. Confirm firmware versions. Do not assume devices updated themselves — the GXP1600 series does not always auto-update reliably in practice.

Segment Your VoIP Network

VoIP phones should be isolated on a dedicated VLAN with strict access controls. The web management interface — which hosts the vulnerable API — should not be reachable from general corporate subnets, let alone from the internet. If your phones are on the same network segment as your workstations or servers, fixing the firmware vulnerability alone is not enough: you need to address the broader architectural risk.

Block Internet Exposure of Management Interfaces

Audit your firewall rules. No phone management interface (TCP port 80 on these devices) should be reachable from outside your network perimeter. If remote management is required, gate it behind a VPN.

Rotate Credentials After Patching

If there is any possibility that a device on your network was compromised before the patch was applied, assume its stored SIP and local credentials are stolen. Change them. Check your SIP registrar logs for unexpected new registrations, unusual proxy configurations, or connections to unfamiliar SIP servers.

Monitor SIP Traffic

If you have the tooling, look for anomalous SIP proxy registration changes or calls routing through unexpected servers. These would be indicators of post-exploitation activity related to the call interception capability demonstrated by Rapid7.

The Bigger Picture: VoIP as a Security Blind Spot

CVE-2026-2329 is a specific, patchable vulnerability in a specific product line. But it also illustrates a broader problem that security teams have been slow to address: VoIP phones and other voice infrastructure devices are largely invisible to the tools and processes organizations use to manage endpoint security.

These devices run full operating systems — typically Linux-based embedded systems — with web servers, APIs, and network services exposed on the LAN. They store credentials. They have long lifecycles and are rarely replaced or updated proactively. They are trusted inside networks designed around the assumption that anything on the internal voice VLAN is legitimate. And because they are "just phones," they are often excluded from patch management programs, vulnerability scanning schedules, and endpoint detection and response deployments.

Attackers have learned to look for exactly this kind of blind spot. A compromised VoIP phone is an ideal persistence mechanism: it is always on, always connected, rarely scrutinized, and sits inside the network perimeter. Unlike a compromised laptop, there is no user on the phone who might notice strange behavior. Unlike a server, there is no operations team running monitoring agents on it. The phone just sits there, trusted and forgotten, potentially forwarding every conversation in the room to an attacker's infrastructure.

This is not a theoretical concern. Rapid7 demonstrated a full, working attack chain for CVE-2026-2329 — from initial unauthenticated HTTP request to silent real-time call interception. The gap between "this is theoretically possible" and "here is a Metasploit module that does it" is now closed.

"This isn't a one-click exploit with fireworks and a victory banner." — Douglas McKee, Rapid7 (Rapid7 Blog, February 18, 2026)

McKee's point is well taken. Exploiting this vulnerability reliably requires some understanding of ARM binary exploitation and ROP chain construction. It is not something a complete novice would pull off without the Metasploit module. But with that module now publicly available, the bar drops considerably. Anyone who can point Metasploit at a target IP and fire a module can exploit this. That is the reality organizations need to plan around.

The broader lesson is that security programs need to extend their scope to include voice infrastructure with the same rigor applied to servers, workstations, and cloud assets. VoIP phones need to be in your asset inventory. They need to be in your patch management workflow. Their management interfaces need to be in your network segmentation design. And their firmware needs to be treated with the same urgency as a critical server OS update — because the consequence of ignoring them is not a disconnected call. It is a bugged conference room and stolen credentials.

Key Takeaways

1. Patch immediately. Any Grandstream GXP1600 series phone running firmware 1.0.7.79 or earlier is fully exploitable with publicly available tools. Firmware 1.0.7.81 fixes the vulnerability. There is no reason to wait.
2. No authentication is required. This is not a post-authentication privilege escalation flaw. An attacker who can reach the phone's web management port — from anywhere on the network, or from the internet if the port is exposed — can exploit it with zero credentials.
3. The impact is severe and stealthy. Root access, credential theft, and silent call interception are all demonstrated, working attack capabilities. The phone continues to look and behave normally while compromised.
4. All six GXP1600 models share the same firmware and are all affected. There is no model in this product line that was spared. If you have any GXP16xx device on your network, check its firmware version now.
5. VoIP security deserves a place in your security program. This vulnerability is a case study in what happens when network-connected embedded devices are excluded from standard patching, monitoring, and segmentation practices. Address the gap before the next CVE, not after.

Grandstream acted quickly once contact was established, and Rapid7 followed a responsible disclosure process that gave the vendor time to produce and validate a patch before technical details and exploit code went public. That part of the story reflects the coordinated disclosure process working as intended. The remaining risk is in the field — in conference rooms, reception desks, and remote offices where phones are still running vulnerable firmware. Closing that gap is now squarely in the hands of IT and security teams. The tools are available on both sides of this: attackers have the exploit, and defenders have the patch. Act accordingly.