It is the end of August, and we were supposed to take time off, enjoy the summer and recharge. The RTC security world did not cooperate, so this issue is a big one. I did still get proper time with the family in between, so it was not a bad month at all. Here is what would not wait.
In this edition, we cover:
- FreeSWITCH servers being taken over in the wild through api-chat, and why 1.11.3 is not optional
- What we found reproducing the coturn August advisory batch, and what the reports were actually worth
- The RTC and telecom research from Hacker Summer Camp, and voice AI as a telephony attack surface
- A five-euro domain that put a researcher in the path of Diego Garcia’s calls
- Zoom’s zero-click annotation bugs, pre-auth root on Cisco CUCM, TrueConf in CISA KEV, and a large short news section
The RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security. We cover both defensive and offensive security as they relate to Real-time Communications.
What is RTC security anyway? Real-time communications security determines if you can safely communicate in real time - whether it be with other humans or machines.
You may sign up to receive the RTCSec newsletter here. If you like what we’re doing, you’re most welcome to:
- Forward it to those who may find this newsletter particularly fruitful.
- Let us know if there are any RTC security news items we should cover.
To view past issues, please visit our website at https://www.enablesecurity.com/newsletter/.
Our news
Upgrade FreeSWITCH: api-chat is being abused for remote code execution in the wild
If you run FreeSWITCH or FusionPBX, upgrade to 1.11.3 now. SignalWire released it on 28 August and called it an important release containing critical security fixes. Servers are being taken over in the wild through the api-chat path, and we have seen it first-hand on a compromised box.
FreeSWITCH will accept a SIP MESSAGE addressed to a URI beginning with sip:api+ and treat what follows as a command to run. A public GitHub issue has documented this since 14 July. On an outdated FreeSWITCH that still has the old unauthenticated SIP MESSAGE behaviour (CVE-2021-37624, which we reported in 2021), the two combine into unauthenticated remote code execution. That is exactly what happened to a FusionPBX we were asked to look at: backdoor installed, full server takeover.
The fix is a switch. The api-chat proto now sits behind a new enable-chat-api-proto setting in mod_sofia and mod_verto. It is off unless you set it, and it ships commented out in the stock profiles, so upgrading is enough on its own. The thing to watch is what comes after: if anyone was using api-chat deliberately, the upgrade breaks it, and turning the setting back on puts you exactly where you started.
A CVE is coming, and credit for it goes to Örn Arnarson and gunnlaugurmani, who reported the same problem privately through the channel in FreeSWITCH’s security policy rather than through the public issue.
We reported it independently to SignalWire on 19 August, along with two related issues that need addressing separately, one reachable over SIP INFO and one over Verto. We will publish the full details shortly.
Thanks to the FreeSWITCH developers for their responses and updates!
What we found verifying the coturn August advisory batch
Last month I wrote that the finding is now the easy part and the impact is the job. Late July and early August gave us a bigger batch to test that on. We worked through the security reports sitting on coturn, reproducing them in a lab and writing up what we thought each one was actually worth. One of them is why you should already have upgraded. Two were worth a good deal less than their reports claimed, and none of that was apparent until we reproduced them.
The one that matters operationally is the DTLS state exhaustion (CVE-2026-73214), where coturn allocates a full per-peer SSL session before verifying the DTLS cookie. The report framed this as needing source spoofing or a botnet. It does not: coturn keys half-open sessions by the full source address and port, so changing UDP source ports from a single host is enough. Under a 1 GiB limit, 4.15.0 died to two waves of 20,000 packets while 4.16.0 survived the same workload with a cgroup peak of about 13.3 MB. We put it at 8.2 High. No credentials, no spoofing, and the process is killed along with every relay it was carrying.
The chained mobility-resume issue (CVE-2026-68555) is the same shape with credentials attached. One credential and one mobile allocation was enough to exhaust 4.15.0’s memory, where 4.16.0 stayed flat under the same run. Mobility is off by default, and there is a temptation to discount a bug because the feature is not commonly enabled. I do not think deployment prevalence belongs in a Base score: AT:P already says a non-default configuration is required, and that is what Environmental metrics are for. We put it at 6.0 Medium.
Then the two where the report was worth less than its headline. The peer IP ACL canonicalisation issue (CVE-2026-73212) arrived described as internal network SSRF, with internal root RCE claimed as proven. It is not an RCE. There is something real underneath, in that other IPv6 forms can route or translate to an IPv4 destination, but it is a topology-dependent peer-policy bypass that needs something like NAT64 in place to give those addresses meaning. We put it at 5.8 Medium. The format-string injection through TURN USERNAME and REALM (CVE-2026-68553) needs the exact username carrying the format conversions to already be provisioned as a valid credential, because MESSAGE-INTEGRITY stops an attacker editing a username after issuance. We reproduced a process crash, but could not substantiate the %n write or the information disclosure claims. We put it at 6.0 Medium.
One more came out of a report that bundled nine separate findings into one advisory. Bundling like that hides the real risk and makes independent CVE assignment and remediation harder, so we sent back a per-item assessment instead. The IPv6 range comparison bypass (CVE-2026-73213) came out of that as its own advisory, fixed in 4.16.0.
If you run coturn, the short version is to get to 4.17.2. The DTLS one alone justifies it and the rest of the batch comes with it. Thanks to Pavel and the coturn developers for the security fixes!
What’s happening?
Hacker Summer Camp 2026: the RTC and telecom research
August put Black Hat USA, DEF CON 34 and BSides Las Vegas in one week, ClueCon in Chicago the week after, and USENIX Security with its WOOT workshop in Baltimore from 12 to 14 August. Las Vegas was dominated by AI and supply chain, so most of the real-time communications material came from the academic venues. Not RTC, but worth knowing about: David Weston’s keynote The End of Rare: Defending When Offense Is Cheap argues that the offensive capability which used to be scarce and expensive is not scarce any more. Here is what is worth your time.
Consumer IoT is where WebRTC security goes to die. At WOOT, a team from DistriNet at KU Leuven presented Real-Time Compromise, comparing 11 consumer IoT products against 10 major web platforms with RTCInspect, an open-source framework that analyses packet captures for weaknesses in signalling, STUN/TURN/ICE, DTLS, certificates and ciphers. The web platforms have largely converged. The IoT side has not: only five of the 11 fully adopted WebRTC, six transmitted signalling with no integrity protection or encryption at all, and not one provided strict end-to-end encryption.
If you run TURN infrastructure, the credential findings are the ones to care about, because this is where the credentials that end up being used against your relays come from. Foscam and Petcam ship hardcoded TURN usernames, Tuya devices send long-term per-device credentials in cleartext, and Digitus, LSC, Foscam and Sygionix leak TURN credentials and session data through signalling that protects neither. The Eufy case study is the one to read in full. Every Homebase shares one static RSA key pair for its DTLS identity, and the private key came out of the firmware. The Homebase 2 also carries its signalling as unencrypted SIP over TCP, so a network-local attacker rewrites the certificate fingerprints and sits in the middle of the media.
A fibre tap that reaches SIP. gPWN, from Rithwik Jayasimha and Rithvik Vibhu, was presented at both Black Hat and DEF CON. GPON, the fibre-to-the-home standard, is a broadcast downstream: every subscriber’s ONU receives the whole neighbourhood’s traffic and is trusted to discard what is not addressed to it. With about $100 of hardware they made theirs keep all of it and read neighbours’ SIP calls, along with DNS and GTP-tunnelled 4G and 5G traffic from cellular towers on the same fibre. It works because downstream AES encryption is optional, OLT vendors ship it disabled, and the ISP has to opt in, which they found none of the seven-plus deployments they tested had done. If your trunks or your remote workers’ calls cross consumer fibre, assume GPON is not protecting them and check what encryption you have above it.
The SMS gateway nobody had audited. At DEF CON, Kyprianos Vasilopoulos and Nikos Vourdas presented Your OTP Never Arrived, an audit of Kannel, the open-source gateway between applications and carrier SMSCs. They found on the order of a thousand instances exposed, dominated by end-of-life 1.4.x, some still on default admin passwords.
SMPP dates to 1999 and assumed the SMSC was a trusted carrier node on a leased line. Today that upstream can be a cloud aggregator, a reseller or an attacker, and Kannel verifies none of it. Outbound TLS defaults to SSL_VERIFY_NONE, and even with a CA file configured the callback does no hostname check, so anyone in the middle reads the OTPs in cleartext. A generic_nack is a valid response Kannel cannot tell from a genuine failure, so messages vanish silently, and forged delivery receipts enable billing fraud on the same assumption. Worse, where a config uses an exec= sms-service, the message text reaches popen through /bin/sh, so a rogue SMSC sends one message and gets an interactive PTY. An SMS goes in and a shell comes out.
Voice AI got attention on both the deployment and the offensive side across the same fortnight, and we cover that separately in this issue. Also worth knowing about:
- 3.5 billion WhatsApp accounts enumerated from a single machine, presented at DEF CON, exposing profile pictures, public keys and device information, with keys reused across accounts.
- iFinder: implicit trust errors across seven open-source 5G core implementations, including a session hijack confirmed on commercial cores.
- CONSET: semantically contradictory RRC messages that reach handsets before authentication. Three high-severity CVEs, 64 chipsets, 542+ phone models.
- CATana: the SIM Toolkit’s RUN AT command tested across 26 phones and IoT modules. Four vulnerabilities, including forced 2G downgrade and code execution on the modem.
On the defensive side, ClueCon had Daniel-Constantin Mierla on running Kamailio as a security guardian for VoIP platforms, Fred Posner on what is new with APIBAN, and Hector Zelaya on using eBPF to make Python viable for a TURN server. Liviu Chircu covered the redesigned TCP and TLS subsystem in OpenSIPS 4.0, which is worth watching given the TCP message smuggling bug in the May batch.
Voice AI is now a telephony attack surface
Voice agents moved into production telephony this year, and August was the month the offensive research caught up. A voice agent is not a model with a phone number attached. It is call routing, speech-to-text, the model, text-to-speech, conversational state, whatever authentication sits in front of it, and whatever tools it can call. Testing the model in isolation tells you almost nothing about the system.
Willie Zhang gave For Prompt Injection, Press 1 at DEF CON’s Social Engineering Community Village, and earlier at BSides SATX, where it is on video. It comes with a tool. Yapper places real calls through Twilio, speaks attack utterances, captures the answers by speech recognition and judges the transcripts with an LLM, running thirty scenarios mapped to the OWASP Top 10 for LLM Applications. Excessive agency is the one to sit with: what the agent can actually do once persuaded, which in a contact centre means account lookups, transfers and refunds rather than rude words.
Sirens’ Whisper at USENIX reaches the same systems through the microphone instead. Prompts are hidden in near-ultrasound, above the range people hear, and microphones distort those frequencies in a predictable way, so the distortion itself rebuilds the audible instruction inside the device. Against commercial models the injected prompt got a compliant answer up to 94% of the time, in an entirely black-box setting, and listeners could not tell the audio from background noise. Jailbreaking was only the demonstration: the same channel carries any prompt injection or command. If your agent listens in a room somebody else can play sound into, that is your threat model.
Fred Heiding and colleagues’ study put 4,100 US adults in front of six AI voice models. Compliance reached 36.1% for emotionally personalised scams, such as a cloned relative in distress, and 16.5% across all categories. Neither AI familiarity nor voice assistant use improved anyone’s ability to detect it, which is worth keeping to hand the next time somebody proposes awareness training as the control. The real finding is that the constraint has moved. Human-operated vishing is unprofitable at US wages, while AI agents can run thousands of concurrent calls. Vishing used to be bounded by how many people you could pay to sit on phones. It is now bounded by trunk capacity.
What the three have in common is that the interesting failures are all at the seams: between the transcript and the model, between the model and its tools, and between the audio the caller sends and the audio the microphone believes it heard. None of them show up if you test the model on its own.
A five-euro domain put a researcher in the path of Diego Garcia’s calls
Lina bought an expired nameserver domain for five euros and found she had taken over the ENUM zones for three country codes.
ENUM maps E.164 telephone numbers into DNS under e164.arpa. A carrier or PBX asks DNS where to route a call and follows the NAPTR records it gets back. The delegations for 0.9.2.e164.arpa, 6.4.2.e164.arpa and 7.4.2.e164.arpa, which cover Saint Helena (+290), Diego Garcia (+246) and Ascension (+247), all pointed at nameservers under ns.enum.org.uk, a domain nobody had renewed. In her words: “when a carrier does an ENUM lookup for one of these numbers, they’re essentially asking ‘where do I route this call?’, and I could answer with whatever I wanted.”
Over six months she logged around 400,000 queries to those nameservers, about half of them ENUM lookups, and of those roughly 100,000 each for the Diego Garcia and Ascension zones. The source addresses were mostly American and consistent with the military bases there. She answered NXDOMAIN to all of them, so the calls fell back to the normal phone network. Answering differently is the interesting case: a NAPTR record decides where a SIP call goes, so controlling the zone means pointing calls at your own infrastructure, which is transparent interception rather than a denial of service.
Nothing was exploited and nothing was vulnerable. Everything worked as designed: a delegation outlived the organisation maintaining it, the registration lapsed, and the call path kept trusting it anyway. The only reason this is a write-up rather than an incident is who happened to buy the domain.
ENUM is infrastructure people configure once and stop thinking about. If you still do ENUM lookups against public e164.arpa delegations, work out which zones you actually query, who controls the nameservers behind them, and when those registrations expire. Monitoring NS expiry on the delegations in your call path costs very little.
Who found the Asterisk MWI NOTIFY overflow, and how bad is it really
Anthropic published the finding behind the unauthenticated MWI NOTIFY stack overflow we covered in June (GHSA-589g-qgf8-m6mx, CVE-2026-57191). Claude found it, Trail of Bits triaged and disclosed it, and the patch landed on 29 May.
The two sides rate it differently. Asterisk calls it a high-severity denial of service, CVSS 8.2: the crafted NOTIFY corrupts the SIP transport and Asterisk stops answering until a restart. Anthropic calls it critical and reports a 901-byte out-of-bounds write of attacker-controlled data, with control-flow hijack on the table. If you patched in June, this changes nothing, but the ceiling may be higher than the advisory suggested.
One bad SDP attribute takes you from a SIP INVITE to the Android kernel
SSD Secure Disclosure published the second stage of an exploit chain by 0x50594d that turns an answered VoLTE video call into code execution in the Android kernel on Unisoc modems. No CVE, no patch, and Unisoc never replied to the researcher.
The way in is an SDP parsing bug. The first stage, from March 2026, is unbounded recursion in the modem’s decoder for the acap SDP attribute: it reads the attribute name, finds acap in its table, and calls itself again with nothing limiting the depth. An SDP line repeating acap:1 enough times runs the SIP task’s stack into its neighbour and overwrites function pointers. The shellcode arrives split into 28-byte segments inside the SDP body. Answering the call triggers it. From there the modem can disable the memory protection unit and write into kernel memory, since the two processors share physical memory with no boundary.
The advisory says the attack needs “any smartphone” and only “the ability to place a video call”. The proof of concept ran on the researcher’s own Open5GS and Kamailio core with an SDR and programmable SIMs, but that is a lab, not a prerequisite. What nobody has answered is whether a real carrier’s P-CSCF or SBC would pass that SDP through untouched. If they do, the attack surface is anyone who can call you, and the parser is sitting in a baseband you cannot patch.
Zoomsday: zero-click RCE in Zoom’s annotation parser
On 11 August the offensive security firm A Security published Zoomsday, a set of memory corruption bugs in Zoom’s annotation feature that let one meeting participant execute code on another’s machine with no click and no prompt. Annotation opens a direct channel between whoever is sharing a screen and everyone watching, and all three bugs they found are in that parser. The headline one is a stack buffer overflow in CAnnoFormatBlock::Deserialize in libannotate.so (CVE-2026-53413, CVSS 8.3), where 32-bit character counts are read off the wire and never bounds-checked against fixed 128-byte buffers. With it come a use-after-free giving a write-what-where primitive (CVE-2026-53415) and a heap over-read useful for leaking what the others need (CVE-2026-53414). It works in both directions, viewer to presenter and back. Fixed in Workplace 7.1.5 and 7.0.6, Rooms and Meeting SDK 7.1.5, Video SDK 2.6.5.
The mitigation is the part worth sitting with. Zoom shipped server-side filtering to protect clients that had not updated, and that filtering cannot inspect anything inside an end-to-end encrypted meeting, so E2EE users stayed exposed until they patched locally. Turning on the strongest privacy setting took away the compensating control. End-to-end encryption protects you from the network, not from a participant who legitimately holds the meeting keys.
The researchers also say they went from analysis to a working exploit in under 24 hours with fewer than 20 prompts to public AI models. Bear in mind that automating exactly this is what they sell.
Cisco CUCM: pre-auth root in three HTTP requests
On 4 August an independent researcher going by 0xReadingSteiner published SKYLINE-2026-001/002/003, a chain that takes Cisco Unified CM 15.0.1 from unauthenticated network access to root in three HTTP requests. Self-scored CVSS 10.0.
The chain is three ordinary misconfigurations stacked on top of each other. RemoteIpValve accepts X-Forwarded-For from any source with no internalProxies restriction, so you claim to be 127.0.0.1. The Tomcat Manager then accepts a hardcoded credential pair that is identical on every CUCM 15.x installation and cannot be changed by an administrator. From the tomcat user, passwordless sudo on gdb with an attacker-controlled command file in /tmp gets you root, and the advisory lists three further independent paths (systemctl, PYTHONPATH, LD_PRELOAD) in case that one is closed.
There is a one-line test in the advisory: send a request with X-Forwarded-For: 127.0.0.1 and those credentials to /manager/text/list, and if you get back OK - Listed applications for virtual host [localhost], you are vulnerable.
Root on CUCM is about as bad as it gets in this space. It means SRTP key extraction and therefore call interception, silent activation of the CALEA lawful intercept that is already built in, voicemail access, complete CDR exfiltration, call routing manipulation, E911 disruption, and a foothold in the voice VLAN.
The disclosure story is the part worth reading twice. The researcher reports 17 CUCM submissions sitting unprocessed at ZDI, paused CUCM acquisitions at SSD because Cisco will not fix existing reports, no response from Cisco PSIRT since 4 August, and CVE IDs requested from MITRE as CNA of last resort. This is advisory 1 of 55 they say they have, published on a rolling basis.
Treat the specifics as unconfirmed until Cisco says something. What is not in doubt is that CUCM sits in federal agencies, hospitals, banks and telcos, and that nobody appears to be catching these before publication.
TrueConf Server: two exploited RCE flaws land in CISA KEV
CISA added two TrueConf Server flaws to the KEV catalogue and gave federal agencies until 3 September to patch. CVE-2026-72529 lets a remote unauthenticated attacker on 4307/TCP invoke an undocumented function and run an arbitrary script, and CVE-2026-72530 escapes the sandbox from there onto the host. Root on a self-hosted conferencing server gives you the conferences themselves: meetings, recordings and whatever else the platform holds.
Kaspersky attributes the exploitation to Head Mare, active since at least July 2026 against Russian organisations. Rather than stopping at the server, they replace the client installers with trojanised versions, so the conferencing server becomes a distribution point for everyone who downloads a client from it. That is the second time this year: Check Point reported the same trick in April, with CVE-2026-3502 exploited as a zero day.
The timing matters. TrueConf fixed both in June, in 5.3.9, 5.4.9 and 5.5.5, and Kaspersky puts Head Mare’s activity from July onwards, so this is not a zero-day story. The fix had been available for a month, and whoever got hit was necessarily running a server that had not applied it. The flaws go back through releases to 2022, so there was plenty of time in which to fall behind. April’s CVE-2026-3502 was the genuine zero-day; this one needed only a server nobody had updated.
Self-hosting is usually the argument for deploying TrueConf. That argument only holds while somebody patches it.
Short news
coturn: the rest of the August wave
Beyond the four we go through in our own news above, coturn published several more in August. Mobility disconnects can bypass allocation quotas and exhaust relay capacity (CVE-2026-73216), and with even-port enabled the server can reach a state where it accepts no further requests (CVE-2026-73215). addr_less_eq() compares IPv6 ranges component by component rather than in numeric order, so an authenticated client can relay to addresses inside a denied-peer-ip range, which is TURN-specific SSRF (CVE-2026-73213). A uint16_t truncation in stun_get_message_len_str() desynchronises TCP and TLS framing when the body length lands between 65520 and 65532 (CVE-2026-68552). And coturn acts on STUN attributes appearing after MESSAGE-INTEGRITY, which the HMAC does not cover, so an on-path attacker can append attributes to an already-authenticated request with no credentials (CVE-2026-68554). Upgrade to 4.17.2.
FreeSWITCH hardens STUN attribute parsing in ICE negotiation
FreeSWITCH merged hardening for STUN attribute parsing in ICE negotiation (PR #3112), addressing buffer overrun risks in handle_ice and switch_stun_lookup with bounds validation and safe NUL-termination of USERNAME fields. There is no CVE and this is hardening rather than a disclosure, but the accompanying commit is worth noticing: it adds unit tests for MESSAGE-INTEGRITY verification, checking that a packet signed with one key rejects any other and that an all-zero value does not pass. Somebody writing tests for HMAC verification on the ICE path is a better signal than the patch on its own.
0day Rubbish: six more RTC advisories
The group whose Brekeke SIP Server and Cisco CUCM work we covered in July published six more, all with public proofs of concept on the day of disclosure and all still CVE-pending. Brekeke PBX 3.19.1.8 has pre-auth RCE from the same fail-open Bean dispatch root cause we verified in July, now with XmlTransBean reflection as a third sink. Two Biamp products are affected: Devio SCR-20/25 has unauthenticated root RCE through DTP protocol quote injection, and Vocia MS-1 has pre-auth RCE via hardcoded FTPS credentials. Between them that covers conference room AV and public address systems. VitalPBX 4.5.2 lets an authenticated web administrator reach root through asterisk_cli. Output Messenger Server 2.0.x has pre-auth RCE via Zip Slip in plugin upload, and Voicent Call Center Suite 10.10.1 via authentication bypass and arbitrary file write. As in July, the self-assigned scores run high.
Toll fraud is a fifth of honeypot traffic
OffSeq published telemetry from its distributed Mirage sensor fleet putting SIP at 22% of the internet attack traffic it sees (5.24 million events), driven by automated International Revenue Share Fraud. The mechanism will be familiar: 401 Unauthorized versus 404 Not Found tells an attacker which extensions exist, followed by PIN brute forcing and prefix-guessing loops that route parallel calls to premium destinations. So is the hardening: alwaysauthreject=yes, allowguest=no, and outbound trunk concurrency limits with destination allowlists. The value here is the numbers, on a pattern usually described qualitatively.
TWINLOOT relays C2 through Microsoft Teams TURN servers
Ontinue described TWINLOOT, a Python implant that tunnels interactive operator commands through Microsoft Teams TURN servers over WebRTC DataChannels, with initial access through social engineering in Teams chat. The RTC part is the transport rather than the payload, since the actual work is credential harvesting, lateral movement and persistence on Windows hosts. It continues a theme we keep returning to: TURN infrastructure belonging to a trusted vendor makes an excellent relay precisely because nobody blocks it.
OpenSIPS: seven advisories, five of them high
OpenSIPS published seven on 5 August. The highs are a stack buffer overflow in the $(cT[*]) pvar (GHSA-w522-9gcp-274p), a heap overflow in the STIR/SHAKEN disengagement route function reachable from a SIP request (GHSA-qr87-6xwg-29p3), a zero-length BIN frame that livelocks a proto_bin worker (GHSA-cvh5-2j8j-w4rg), a heap overflow in reassemble_body_parts via a malformed multipart body (CVE-2026-54539), and a heap and global overflow in b2b_sca reachable through an attacker-controlled From display name (CVE-2026-54535). Three of the five highs are reachable from a SIP request or a peer you already accept.
The version metadata on all seven is broken: patched_versions is byte-identical to vulnerable_version_range, so the advisories do not tell you what to upgrade to. We went through the commit history instead. Five of the seven were already fixed and released before the advisories appeared, backported to 3.6.7 and 4.0.0-rc2 on 17 June, so anyone who took the June releases was covered seven weeks before being told. The other two are fixed only on master, and neither 3.6.8 nor 4.0.1, both released on 19 August, carries the fix. One of those two is CVE-2026-54539, the multipart heap overflow, which is one of the highs. As of the end of August there is no release that fixes it, or the imc boundary check (CVE-2026-62339). Get to 3.6.7 or 4.0.0 at minimum, and do not read 4.0.1 or 3.6.8 as closing the batch.
PJSIP: seven advisories in August, three of them high
PJSIP underpins Asterisk, FreeSWITCH and a lot of embedded VoIP, so these land widely. The first of the three highs is a pre-auth out-of-bounds read (GHSA-pjx6-7vrm-3w6f): a crafted multipart body makes the message serialiser miscompute the encoded body length, which hits anything that re-serialises a received SIP message. The second is the legacy RFC 3489-style STUN client in stun_simple.c (GHSA-893w-fmvw-qvg7), which checks neither MESSAGE-INTEGRITY nor the transaction ID nor the source address, so forged Binding Responses are accepted. The third is a NULL pointer dereference in match_offer() on an SDP offer combining an RFC 2198 RED codec with a static payload type (GHSA-wf9x-v65x-5qh3). All seven list versions up to 2.17 as vulnerable, and the only fixed release any of them names is 2.18, which is not out, so check with the project before planning an upgrade.
FreePBX: seven more advisories, and the module versions to move to
August brought a fresh batch, continuing the run we covered in July. None carry CVEs, only GHSA ids. The critical one is unauthenticated RCE via SQL injection in the Sangoma Connect RT API login (GHSA-h9vq-j62m-6m73, CVSS 9.3), and a second unauthenticated issue in UCP lets anyone reset or overwrite another user’s dashboard templates (GHSA-rgq3-mgw4-rcfh). The remaining five all need a login. Both unauthenticated ones are in the internet-facing components, which is the pattern to note. Fixed versions: sangomartapi 16.0.55 or 17.0.26, ucp 16.0.41 or 17.0.10, framework 16.0.49 or 17.0.32, backup 16.0.74 or 17.0.12.
SIPSorcery: five advisories across SIP-TLS, SRTP, ICE, TURN and SCTP
SIPSorcery is the main .NET SIP and WebRTC stack, and it published five in August, all in the RTC path and none with a CVE. The significant one is that SIPTLSChannel defaults to BypassCertificateValidation=true, so outbound SIP-TLS accepts any self-signed certificate and a man in the middle collects the whole signalling stream including digest credentials (GHSA-h6x7-h3p4-ff4p). TLS that validates nothing is worse than no TLS, because the operator believes the leg is protected. Two more are denial-of-service bugs: a malformed UDP datagram crashes the TurnServer receive loop (GHSA-pfvm-w89x-94jw), and unbounded SCTP SACK gap and duplicate counts kill the data channel receive thread (GHSA-jwjp-4649-v8jp). Upgrading to 10.0.16 covers all five.
Jitsi: an OCTO relay proxy bug and a JaaS entitlement bypass
Two Jitsi ecosystem issues surfaced through HackerOne rather than project advisories. An unsafe nginx regex in @jitsi/docker-jitsi-meet’s /colibri-relay-ws/ location accepted arbitrary domain names and IP addresses, so unauthenticated attackers could proxy requests to any destination through what is meant to be the OCTO relay for Videobridge clustering (report); the configuration was removed. On the hosted side, 8x8’s JaaS SIP gateway validated incoming requests without checking tenant subscription entitlements, permitting out-of-plan SIP calls (report). Jitsi published no security advisories at all in August, so the bug bounty is where this ecosystem’s findings are showing up.
Linux netfilter SIP NAT handler buffer overflow
The kernel’s SIP helper, nf_conntrack_sip, has an integer overflow in its NAT rewrite delta handling (CVE-2026-74569). When NAT-rewritten SIP messages exceed S16_MAX, the parser reads past the skb tail. Large Contact header lists are the trigger, and the bug is in sip_help_tcp(), so this affects any Linux box doing SIP NAT or ALG over TCP on calls that carry them. Also tracked at SUSE.
Chrome 152 fixes five WebRTC CVEs and two in GetUserMedia
Chrome 152 (152.0.7977.64 on Linux, .64/.65 on Windows and Mac) landed on 25 August with an unusually dense set of RTC fixes. Two are rated High and both are use-after-free in WebRTC: CVE-2026-79187, and CVE-2026-79027, which Mozilla reported. Three more WebRTC CVEs and two in GetUserMedia, the capture path feeding WebRTC, are Medium or Low. The density is the story rather than any single entry, and it matters for anyone shipping Electron or CEF.
Firefox 154: information disclosure in the WebRTC component
MFSA 2026-74 on 18 August lists CVE-2026-74958, “Information disclosure in the WebRTC component”, reported by Tomoya Nakanishi and rated moderate by Mozilla. Firefox 154 and ESR 153.1 carry the fix, and Thunderbird 154 and 153.1 inherit it through shared platform code. Mozilla publishes no numeric score; CISA-ADP put it at 7.5. There is no public technical detail yet.
The DTLS-SRTP authentication paper was presented at USENIX Security
Bach, Karadzic, Knittel, Merget and Degabriele presented “Analyzing the WebRTC Ecosystem and Breaking Authentication in DTLS-SRTP” at USENIX Security in Baltimore from 12 to 14 August. We covered the research in March when the preprint appeared, so this is an update: the final paper and conference media are now out, and it was named a Distinguished Paper runner-up.
The University of Naples RTC attack testbed gets a peer-reviewed paper
The RTC_Attacks lab we covered in May now has a journal paper behind it. It remains a reproducible testbed for experimenting with real-time communications attacks, and the peer review is a reasonable prompt to look again if you skipped it the first time.
Thanks to Vulners and other third parties for providing vulnerability source material.
This newsletter was prepared by Sandro Gauci and the Enable Security team for RTCSec newsletter subscribers. If you have someone in mind who would benefit from our content, please share.
To subscribe: here