This is a bad gear tooth in the transmission, not a missing front door
CVE-2026-4390 is a use-after-free in TeamSpeak 3 Server connection state management, specifically the process_resend_queue path, affecting TeamSpeak 3 Server 3.13.7 and earlier; TeamSpeak also says the same flaw affects server-side SDK integrations 3.3.1 and earlier. The practical impact documented by TeamSpeak is authenticated remote denial of service: a logged-in remote user can send crafted traffic that destabilizes the service or forces a server restart.
The raw memory-corruption label makes this look scarier than the real-world path. Yes, use-after-free bugs can sometimes become code execution, but the published vendor impact for this CVE is DoS, not RCE, and the chain starts with low-privileged authenticated access on a relatively niche service. That attacker-position requirement, plus no KEV listing, no vendor-confirmed exploitation, and a near-floor EPSS, pushes this back into routine-but-real patching rather than emergency response.
4 steps from start to impact.
Get onto the voice server as a normal user
- A vulnerable TeamSpeak 3 Server version 3.13.7 or earlier
- The attacker can reach the TeamSpeak service over the network
- The attacker has valid low-privileged credentials or equivalent server access
- Requires authenticated remote access, which implies pre-existing access, credential theft, invited membership, or weak registration controls
- TeamSpeak is far less ubiquitous in enterprise fleets than browsers, VPNs, mail gateways, or remote management products
- Some private deployments restrict access by IP, password, or unpublished server listings
Drive the connection state machine into the vulnerable path
process_resend_queue hits an inconsistent state. This is not a normal admin action and depends on protocol-level traffic shaping rather than a simple one-shot request. The available advisories describe the bug as a connection state handling issue, which strongly suggests crafted sequencing rather than commodity recon tooling.- Ability to speak the TeamSpeak protocol after authentication
- A target version still running the vulnerable state-management code
- Requires protocol awareness and targeted malformed traffic, not just a login
- Rate limits, connection hygiene, or front-end filtering by hosting providers can reduce reliability
- The exploit path appears more brittle than ordinary application-layer bugs
Trigger the use-after-free and crash the process
- Successful reachability of the vulnerable code path
- Server process not already patched to 3.13.8 or later
- Memory-corruption bugs vary in reliability across builds and hosting environments
- Modern allocators and platform hardening often turn theoretical code-exec paths into plain crashes
- Operational impact is bounded to the TeamSpeak service, not automatic host takeover
Cause localized outage, not broad estate compromise
- The target actually depends on TeamSpeak for business or community operations
- Single-service blast radius
- Restarts and failover can shorten outage duration
- No published evidence in reviewed sources of lateral movement directly from this CVE
The supporting signals.
| In-the-wild status | No confirmed active exploitation in reviewed primary sources. TeamSpeak states in TS-SA-2026-001 that as of 2026-05-27 it was not aware of active exploitation. |
|---|---|
| KEV status | Not KEV-listed in the CISA Known Exploited Vulnerabilities Catalog as reviewed. |
| Proof-of-concept availability | No public weaponized PoC repository located in primary-source review. modzero published the disclosure and referenced deeper research, but not a public one-click exploit in the sources reviewed. |
| EPSS | 0.00044 (user-supplied); that is effectively near-floor exploit probability and matches the absence of field exploitation evidence. |
| Scoring disagreement | There are two baselines: the CNA/VulDB score shown in NVD is 5.4 MEDIUM with PR:L, while TeamSpeak's own advisory scores this CVE 7.1 HIGH with higher availability impact. Real-world prioritization should key off the attack path, not the spreadsheet argument. |
| CVSS interpretation | AV:N/AC:L/PR:L/UI:N/S:U/... means remote and easy once you already have a user account, but not internet-unauthenticated. That PR:L is the big severity brake. |
| Affected versions | TeamSpeak 3 Server 3.13.7 and below; TeamSpeak also lists SDK server-side integrations 3.3.1 and below as affected. |
| Fixed versions | TeamSpeak 3 Server 3.13.8 and TeamSpeak SDK 3.5.0. TeamSpeak also pointed container users to teamspeaksystems/teamspeak3-server:3.13.8 in the community announcement. |
| Exposure / scanning reality | The service is commonly exposed on UDP 9987 with optional TCP query/file-transfer ports. Public server-listing sites show many internet-visible 3.13.7 instances, but this is still a niche exposure population compared with mainstream enterprise software. |
| Disclosure / reporter | Disclosed 2026-05-27. TeamSpeak credits Michael Imfeld and the modzero team for coordinated disclosure. |
noisgate verdict.
The decisive factor is authenticated remote access is required. That means the attacker is already past an initial access gate on a niche service, and the documented impact remains a service crash/restart, not demonstrated host compromise.
Why this verdict
- Start at the vendor baseline, then cut for attacker position: TeamSpeak's own advisory calls this 7.1 HIGH, but the path requires authenticated remote access. That implies prior access, stolen creds, invited membership, or weak join controls; this is not an unauthenticated edge exploit.
- Population is narrower than the score implies: TeamSpeak servers are internet-exposed in some environments, but they are not a universal enterprise platform. The reachable population is materially smaller than for VPNs, browsers, email, remote desktop gateways, or hypervisors.
- Impact is operationally real but technically bounded: the vendor-documented outcome is service instability or restart. For a 10,000-host team, that is an application outage problem, not evidence of broad privilege escalation or domain compromise.
Why not higher?
Because the chain is post-access: low-privileged authenticated remote access is required before the bug matters. Also, the primary-source material reviewed does not show active exploitation, KEV inclusion, or a published working RCE, so there is no reason to treat this like an internet-wormable edge bug.
Why not lower?
It still deserves a real ticket because the target is often network-exposed and the bug class is memory corruption, not harmless input validation. If your organization actually relies on TeamSpeak for operations, even a DoS-only authenticated bug can disrupt coordination at the wrong moment.
What to do — in priority order.
- Restrict who can reach the service — Put TeamSpeak behind VPN, IP allowlists, or tight perimeter ACLs wherever possible so random internet users cannot even attempt the authenticated stage. For a MEDIUM verdict there is no noisgate mitigation SLA; use this as exposure reduction while you work inside the remediation window.
- Tighten account admission — Review public registration, invite links, shared credentials, and stale user accounts so
PR:Lis harder to obtain in practice. This directly attacks the biggest amplifier in the chain: the attacker needs a valid user context before the bug is reachable. - Watch for crash-and-reconnect patterns — Alert on repeated TeamSpeak process restarts, watchdog recoveries, and bursts of failed or churn-heavy session activity. This will not prevent exploitation, but it shortens detection time for abuse against still-unpatched instances.
- Segregate the host — Keep the TeamSpeak service on a non-privileged, isolated host/container with minimal adjacent trust. If the memory-corruption story ever evolves beyond DoS, you want the blast radius to stop at that service boundary.
- A WAF doesn't help much because this is not normal HTTP traffic; TeamSpeak commonly exposes a native UDP/TCP protocol surface.
- MFA assumptions don't save you if the deployment doesn't actually enforce MFA for TeamSpeak access; the CVSS
PR:Lgate is only as strong as your real account controls. - Security-by-obscurity alone—for example not publishing the server—reduces casual discovery but does not protect a publicly reachable IP from scanning.
Crowdsourced verification payload.
Run this on the Linux/macOS host that runs TeamSpeak 3 Server. Save it as check-ts3-cve-2026-4390.sh and run bash check-ts3-cve-2026-4390.sh /opt/teamspeak3-server or point it at a log directory/file; it needs read access only to the install path and logs.
#!/usr/bin/env bash
# check-ts3-cve-2026-4390.sh
# Determine whether a TeamSpeak 3 Server install is vulnerable to CVE-2026-4390
# by extracting the installed server version from logs, binary strings, or directory names.
# Exit codes:
# 0 = PATCHED
# 10 = VULNERABLE
# 20 = UNKNOWN
set -u
TARGET="${1:-.}"
FIXED="3.13.8"
FOUND_VERSION=""
SOURCE=""
verlte() {
[ "$1" = "$2" ] && return 0
local first
first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
[ "$first" = "$1" ]
}
extract_from_text() {
grep -Eo 'TeamSpeak 3 Server[[:space:]]+[0-9]+\.[0-9]+\.[0-9]+' 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1
}
if [ -f "$TARGET" ]; then
FOUND_VERSION=$(cat "$TARGET" | extract_from_text || true)
if [ -n "$FOUND_VERSION" ]; then SOURCE="file:$TARGET"; fi
fi
if [ -z "$FOUND_VERSION" ] && [ -d "$TARGET" ]; then
if [ -d "$TARGET/logs" ]; then
FOUND_VERSION=$(grep -RhoE 'TeamSpeak 3 Server[[:space:]]+[0-9]+\.[0-9]+\.[0-9]+' "$TARGET/logs" 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true)
if [ -n "$FOUND_VERSION" ]; then SOURCE="logs:$TARGET/logs"; fi
fi
fi
if [ -z "$FOUND_VERSION" ] && [ -d "$TARGET" ]; then
for bin in "$TARGET/ts3server" "$TARGET/ts3server.exe"; do
if [ -f "$bin" ]; then
FOUND_VERSION=$(strings "$bin" 2>/dev/null | extract_from_text || true)
if [ -n "$FOUND_VERSION" ]; then SOURCE="binary:$bin"; break; fi
fi
done
fi
if [ -z "$FOUND_VERSION" ] && [ -d "$TARGET" ]; then
FOUND_VERSION=$(basename "$TARGET" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true)
if [ -n "$FOUND_VERSION" ]; then SOURCE="dirname:$TARGET"; fi
fi
if [ -z "$FOUND_VERSION" ]; then
echo "UNKNOWN unable_to_determine_version target=$TARGET fixed=$FIXED"
exit 20
fi
if verlte "$FOUND_VERSION" "$FIXED" && [ "$FOUND_VERSION" != "$FIXED" ]; then
echo "VULNERABLE version=$FOUND_VERSION fixed=$FIXED source=$SOURCE cve=CVE-2026-4390"
exit 10
fi
if [ "$FOUND_VERSION" = "$FIXED" ] || ! verlte "$FOUND_VERSION" "$FIXED"; then
echo "PATCHED version=$FOUND_VERSION fixed=$FIXED source=$SOURCE cve=CVE-2026-4390"
exit 0
fi
echo "UNKNOWN version=$FOUND_VERSION fixed=$FIXED source=$SOURCE"
exit 20
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.