Five of the Nine FreeSWITCH CVEs Are in One Module You Probably Do Not Use

Originally published at ictinnovations.com

Nine FreeSWITCH CVEs were published in June 2026. Two are critical, 9.8 and 9.1. If you read them as a list you get a patch-everything-now panic. If you group them by where they actually live, the job gets much smaller, and for a lot of installs the best move is not a patch at all.

Where they actually sit

I pulled all nine from the NVD API rather than a vendor bulletin, because scores and vectors get copied around with errors. Grouped by component, the distribution is lopsided.

Five of the nine are mod_verto or its WebSocket handling. That includes the worst one.

CVE-2026-49841, scored 9.8, is a heap overflow in the mod_verto HTTP request handler. It allocates a fixed 2 MiB buffer for a urlencoded POST body but accepts a Content-Length just under 10 MiB, and the read loop is bounded by the header value rather than the buffer. Unauthenticated, network reachable, no user interaction.

CVE-2026-49842 is more embarrassing than dangerous on paper but tells you something about the module. A hash-prefixed speed-test protocol, #SPU and friends, gets parsed before any authentication check, with the payload size read by atoi and only non-positive values rejected. CVE-2026-49847 is a single unauthenticated WebSocket frame with deeply nested JSON that drives the worker stack into the guard page and takes every call on the host with it.

The remaining two in that group, 49843 and 49848, are both auth-ordering bugs: state written from a client-supplied request before the credential check happens. Lower scores, same root cause.

The one that is not about the switch

CVE-2026-49840, scored 9.1, is in the Event Socket Library. Content-Length is parsed with atol and handed to malloc with no sign or magnitude check, so a negative length corrupts the heap.

The description is worth reading carefully. It affects any process linked against libesl, not just FreeSWITCH. That means the monitoring script somebody wrote four years ago, the little dashboard that tails events, the billing hook. Those are not usually on anyone's telephony patch list, and a man-in-the-middle on an ESL connection is a realistic position if ESL is not on loopback.

Two more sit in bundled XML parsing. CVE-2026-45771 is a billion-laughs expansion reached through the PIDF body of a SIP PUBLISH, before any digest check. CVE-2026-49472 is an expat clone inside the bundled xmlrpc-c that never received an upstream security patch. Vendored dependencies, aging quietly.

And CVE-2026-49475 is a STUN attribute whose declared length is shorter than the struct the parser casts to, giving an out-of-bounds access on the per-leg media buffer. Worth separating from the Verto group, because it lives in media handling. WebRTC traffic reaches it whether or not you run Verto.

So check the module list first

This is the actual recommendation, and it is not what a CVE list pushes you toward.

From fs_cli, run show modules and look for mod_verto. Plenty of installs carry it only because it sat in the default modules.conf.xml and nobody pruned it. If nothing on your network speaks Verto or connects a browser client to that box, unloading the module retires five of the nine, including the 9.8, with no maintenance window and no regression risk to your call path.

For the record, our own builds do not ship it. I checked the module list we stage for the ICTCore and ICTFax images: 53 modules, mod_event_socket present, mod_verto absent. That is not cleverness on our part, it is just that a fax and voice application server has no reason to serve browser clients.

Which leaves ESL as the one that does apply to us, and to most people reading this.

A caveat on version numbers, because this part is genuinely unclear

The advisories name the fixed versions as 1.11.0 and 1.11.1. Three issues are fixed in 1.11.0, the other six in 1.11.1, so landing on 1.11.0 and stopping leaves both criticals open.

Here is the part I cannot answer for you. The 1.11 line is FreeSWITCH master. Most production installs run the 1.10 stable line, and the advisories do not say whether the fixes were backported into a later 1.10 release. Our own Docker image pulls 1.10.12 from a Copr repository, and our older Ubuntu install script still pins 1.10.11, which is a mismatch we need to fix on our side regardless.

I am not going to tell you that 1.10.x is safe, and I am not going to tell you it is exploitable. Neither claim is supported by what the advisories actually say. Ask whoever packages your build whether these specific CVE IDs are addressed in the version you are running, and treat a shrug as a no.

What to do if you cannot upgrade this week

Unload modules you do not use. That is free and it is the biggest single reduction here.

Put ESL back where it belongs. Loopback, or an allowlist, or a tunnel. An event socket reachable from anywhere other than the host itself has been a bad idea for a decade and this batch adds a heap corruption bug to the argument.

Then check that your Verto and WebSocket ports are not answering from the open internet. We wrote a longer piece on the tooling and resources around both Asterisk and FreeSWITCH if you want the wider map, but the port question takes about a minute with nmap from outside and answers more than any list will.

FAQ

Is mod_verto safe to unload on a running system?

If no client connects over Verto, yes. Unloading it drops Verto and its WebSocket listener and touches nothing in the SIP path. Check show modules and your access logs before assuming nobody uses it.

Does this affect Asterisk too?

No. These are FreeSWITCH CVEs. Asterisk has its own advisory stream and its own release lines.

Why group by module rather than by score?

Because score tells you how bad something is if it applies, and the module tells you whether it applies at all. A 9.8 in code you do not load is not your problem. A 5.3 in code every one of your scripts links against might be.

Is CVE-2026-49840 really a problem if ESL is internal?

Lower risk, not zero. The bug is triggered by a malicious or man-in-the-middle peer, so it depends on who can reach the socket and what sits between. Internal is not the same as trusted on a flat network.

Were these actively exploited?

I have seen no evidence of exploitation in the wild and I am not going to imply any. Treat them on severity and reachability, not on rumour.

How do I check my version properly?

Run version in fs_cli for the build string, and check your package version separately, since a distribution package and the upstream tag do not always line up. The build date alone tells you very little.

Sources: NVD API records for CVE-2026-49841, 49840, 49847, 49842, 49475, 45771, 49843, 49472 and 49848, all published June 2026. Scores quoted are CVSS 3.1 base scores as recorded by NVD.