Does Your VoIP Provider Even Know What Phones You're Running?

Does Your VoIP Provider Even Know What Phones You're Running?

🔭 Scout's Take

Everyone patches their servers. Almost nobody patches their desk phones. A new Grandstream CVE gives unauthenticated root access to a phone series that's everywhere in small business deployments, but the real problem isn't one vulnerability. It's a white label supply chain where providers can't tell you what's deployed, can't push firmware updates, and shipped every phone as "plug and play" onto flat networks with zero segregation.

Rapid7 disclosed CVE-2026-2329 last week: a critical unauthenticated buffer overflow in Grandstream GXP1600 series phones that gives an attacker root access from the network. No credentials required. The phone keeps working normally while someone else controls where your calls go. But the vulnerability itself isn't really the story here.

What does CVE-2026-2329 actually do?

The GXP1600 series is an older Grandstream line, but it's still out there. A lot of it is out there. Grandstream sells volume into the channel, and these phones ended up in offices, call centers, and conference rooms across thousands of small and mid-size businesses.

The exploit is about as bad as it gets for a network device: unauthenticated, stack-based buffer overflow, root privileges on success. Once an attacker has root, they can modify the phone's SIP configuration to route calls through an attacker-controlled proxy. The interception is transparent. Users see a working screen, hear a dial tone, make and receive calls normally. They have no idea their voice traffic is being copied somewhere else.

Most of these devices sit behind NAT, which limits remote exploitation. But if an attacker already has a foothold inside the network, a VoIP phone is a quiet pivot point. It blends in with normal SIP traffic. It's not running endpoint detection. Nobody is watching it.

Who's actually responsible for patching these phones?

Grandstream will release a firmware fix. That part is straightforward. The question is whether anyone pushes it.

The VoIP channel has a supply chain problem that nobody talks about. There are a lot of "VoIP providers" in the market who aren't really VoIP providers. They're MSPs or IT shops that added voice to round out their offering. They signed up with a white label platform like SkySwitch, CoreDial, White Label Communications, or Viirtue, got access to a portal, and started selling phone service.

Some of these providers are good. They manage their deployments, track their hardware, and pay attention to security advisories. But a lot of them don't. Voice was a line item they needed for competitive positioning. They configured it once and moved on. They don't know what phone models are deployed to which customers. They don't have a firmware management process. They don't monitor CVE databases for their hardware.

Here's where it gets worse: the white label platforms themselves can make it difficult to audit your own deployment. Figuring out what hardware is in the field, what firmware versions are running, and whether a patched image is even available on the master platform can be genuinely complex. Some providers make this easy. Others don't. And the reseller sitting between the platform and the end customer often has limited visibility into either side.

The providers most likely to have vulnerable phones deployed are the same providers least likely to know about it, least equipped to find the devices, and least motivated to push a firmware update.

Why are most VoIP phones sitting on flat networks?

The major UCaaS providers, your RingCentrals and 8x8s, ship phones as plug-and-play devices. That's the selling point. Unbox it, plug in the ethernet cable, it registers and starts working. Nobody from RingCentral is calling the customer and saying "hey, you should set up a voice VLAN and segment this traffic from your production network."

So the phones sit on the same network as workstations, file servers, and everything else. In businesses with scaled IT management, maybe someone sets up proper segregation. In a 30-person company with an MSP that comes in twice a month? The phones are on the same subnet as the accounting software.

This is fine until it isn't. A compromised phone on a flat network isn't just a voice security problem. It's a network access problem. That device can see everything on the same broadcast domain, and it's running firmware that nobody has looked at since it was unboxed.

What's the realistic threat from unpatched VoIP phones?

Sophisticated call interception gets the headlines, but the threat most businesses actually face from unpatched VoIP phones is simpler: toll fraud.

Someone compromises a phone or a SIP registration, reconfigures it to make international calls, and runs up thousands of dollars in charges before anyone notices. This happens constantly. It's been happening for years. And it's bad for everyone involved. The customer gets a bill they didn't expect. The provider gets a support nightmare. The carrier eats some of the cost. Insurance may or may not cover it.

I've seen toll fraud hit businesses that had no idea their phone system was even capable of making international calls. The exposure was there in the configuration, nobody had reviewed it, and an attacker found it before the provider did.

With a vulnerability like CVE-2026-2329 that gives root access, the attacker doesn't even need to guess SIP credentials. They own the device. They can add whatever dial plan entries they want.

What should you ask your VoIP provider right now?

If you're a business running VoIP phones, here's the conversation to have with your provider:

Ask for a hardware inventory. Your provider should be able to tell you every phone model and firmware version deployed to your account. If they can't produce this quickly, that's your answer about how well they're managing your deployment.

Ask about their firmware update process. How do they push updates? How often? When was the last time they updated firmware on your phones? If the answer is "we don't" or "we haven't," you have a problem that goes well beyond this one CVE.

Ask about network segregation. Are your voice devices on their own VLAN? If not, why not? This is basic network hygiene, and your provider should have recommended it during deployment. If they didn't, they were optimizing for easy installation over security.

Check your international calling exposure. Review your dial plan. If international calling is enabled and you don't need it, disable it. If you do need it, make sure there are rate limits and alerts in place. A $4,000 toll fraud bill on a Sunday morning is a bad way to find out your configuration was wide open.

If you're a provider, the bar is even more basic: know what you've deployed. If you can't produce an inventory of phone models and firmware versions across your customer base within an hour, you're not managing a deployment. You're hoping nothing goes wrong.

Why do we still treat phones like furniture?

The core issue here is that VoIP phones are computers running network services, and most organizations treat them like furniture. They get plugged in, configured once, and forgotten. Nobody patches them. Nobody monitors them. Nobody includes them in security audits.

The CVE will get patched. Some providers will push the update. A lot won't, because they don't know they need to, or because they can't. And the phones will keep sitting there on flat networks, running old firmware, waiting for the next vulnerability to show up in a Rapid7 blog post.

If you manage phones for other people, treat them like the networked computers they are. If your provider manages phones for you, make sure they're treating them that way too. A five-minute conversation now is cheaper than a toll fraud bill or a breach disclosure later.

Worried about your VoIP security posture? Let's take a look.

Get in Touch