← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-4390 · CWE-119 · Disclosed 2026-05-27

A weakness has been identified in TeamSpeak 3 Server up to 3

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is an authenticated crash bug on a niche voice server, not a drop-everything internet RCE."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get onto the voice server as a normal user

The attacker first needs working access to a TeamSpeak 3 server instance and must authenticate as a low-privileged user. The exposed surface is usually the native TeamSpeak voice service on UDP 9987, with optional query/file-transfer ports; this is a public-facing service in many hobbyist and community deployments, but far less common in enterprise estates. No public exploit chain turns this into unauthenticated internet spray-and-pray from the material reviewed.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: External scanners can spot exposed TeamSpeak ports, but they generally cannot prove exploitability for this CVE without valid credentials; most coverage is version/banner-based.
STEP 02

Drive the connection state machine into the vulnerable path

Using a custom packet generator/fuzzer in the style of the modzero research, the attacker exercises the connection lifecycle until 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.
Conditions required:
  • Ability to speak the TeamSpeak protocol after authentication
  • A target version still running the vulnerable state-management code
Where this breaks in practice:
  • 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
Detection/coverage: Look for abnormal session churn, repeated reconnects, malformed traffic patterns, and crash-adjacent log entries; signature coverage is likely weak unless a product already fingerprints TeamSpeak protocol abuse.
STEP 03

Trigger the use-after-free and crash the process

If the state transition lands correctly, the server dereferences freed memory and enters a service instability / restart condition. TeamSpeak's own advisory frames impact as denial of service, and no primary-source evidence reviewed shows a public working RCE. In practice this is a reliable availability hit before it is anything more exotic.
Conditions required:
  • Successful reachability of the vulnerable code path
  • Server process not already patched to 3.13.8 or later
Where this breaks in practice:
  • 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
Detection/coverage: Best evidence is local: TeamSpeak service restarts, crash logs, watchdog restarts, and correlated drops in active sessions. Vulnerability scanners will usually miss the live exploitation attempt itself.
STEP 04

Cause localized outage, not broad estate compromise

The business effect is voice-service interruption for that TeamSpeak instance or tenant. That matters to operations teams using it for coordination, but the blast radius is typically one application service rather than domain-wide compromise. Without a demonstrated privilege-escalation or code-execution follow-on, the attack stops at availability degradation.
Conditions required:
  • The target actually depends on TeamSpeak for business or community operations
Where this breaks in practice:
  • Single-service blast radius
  • Restarts and failover can shorten outage duration
  • No published evidence in reviewed sources of lateral movement directly from this CVE
Detection/coverage: Service-monitoring platforms, uptime checks, and host logs should catch the outage; pure network IDS coverage will be inconsistent.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 statusNot KEV-listed in the CISA Known Exploited Vulnerabilities Catalog as reviewed.
Proof-of-concept availabilityNo 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.
EPSS0.00044 (user-supplied); that is effectively near-floor exploit probability and matches the absence of field exploitation evidence.
Scoring disagreementThere 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 interpretationAV: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 versionsTeamSpeak 3 Server 3.13.7 and below; TeamSpeak also lists SDK server-side integrations 3.3.1 and below as affected.
Fixed versionsTeamSpeak 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 realityThe 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 / reporterDisclosed 2026-05-27. TeamSpeak credits Michael Imfeld and the modzero team for coordinated disclosure.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.7/10)

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.

HIGH Attacker-position requirement is a major severity brake
HIGH Published impact is bounded to denial-of-service
MEDIUM Real-world exposure population across enterprise estates

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. Tighten account admission — Review public registration, invite links, shared credentials, and stale user accounts so PR:L is 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.
  3. 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.
  4. 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.
What doesn't work
  • 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:L gate 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: identify any TeamSpeak 3 Server instances, confirm whether they are 3.13.7 or earlier, and patch them to 3.13.8 during normal vulnerability operations. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use network restriction and account cleanup as optional exposure reduction, but the formal deadline from the noisgate remediation SLA is within 365 days unless your TeamSpeak deployment is mission-critical enough to justify a faster local standard.

Sources

  1. NVD CVE-2026-4390
  2. TeamSpeak Security Advisory TS-SA-2026-001
  3. TeamSpeak community announcement
  4. TeamSpeak downloads
  5. modzero advisory MZ-26-01
  6. CISA Known Exploited Vulnerabilities Catalog
  7. TeamSpeak support: server ports
  8. Public listings of TeamSpeak 3.13.7 servers
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.