Skip to navigation

Threat reportVulnerabilityTL-2026-4906

CVE-2025-43504: Remote Pre-Authentication Buffer Overflow in LLDB debugserver (Xcode / iOS Developer Disk Image)

mediumPATCHED

CVE-2025-43504 is a global (.bss) buffer overflow in LLDB's debugserver, triggered by a crafted qSpeedTest:response_size:<hex>; packet that is processed before any authentication. The attacker controls only the overflow length (fixed 'a' bytes), so practical impact is denial of service; Apple fixed it in Xcode 26.1 and a public PoC exists. First disclosed .

Key facts for LLDB debugserver overflow

IdentifiersTL-2026-4906, CVE-2025-43504
SeverityMEDIUM
CVSS4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
First disclosed
Exploitation statusPublic proof-of-concept exploit
EPSSCVE-2025-43504: 0.3% (31.3th percentile)
Affected productsApple Xcode (LLDB debugserver); LLVM Project LLDB debugserver (lldb/tools/debugserver/source/RNBRemote.cpp)
Weaknesses (CWE)CWE-119
MITRE ATT&CK techniquesT1190 Exploit Public-Facing Application, T1203 Exploitation for Client Execution, T1499.004 Application or System Exploitation
MotivationUNKNOWN
Target sectorstechnology, software development
Target regionsGlobal
Detection rules9 (1 shown free)
Sources6 cited sources

Detection coverage for LLDB debugserver overflow

As of 2026-10-31, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-4906 across Splunk SPL, Microsoft KQL and Sigma, covering 5 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: CVE-2025-43504 debugserver qSpeedTest Oversized response_size Packet — Exploitation

Detects a GDB-remote qSpeedTest:response_size:<hex>; packet whose response_size is 4MB (0x400000) or larger, the size the upstream fix (LLVM ac8e7be) rejects. Sent to LLDB debugserver (commonly TCP/1234) it overflows the static g_data buffer in RNBRemote::HandlePacket_qSpeedTest before any authentication, corrupting g_log_callback and g_LogThreadedMutex and crashing debugserver (denial of service). A public PoC exists; no in-the-wild use is reported.

  • Languages: Splunk SPL, Microsoft KQL, Sigma
  • ATT&CK: T1190, T1203, T1499.004
  • Data sources: stream:tcp, suricata_eve, network_traffic
  • Severity: medium
  • Confidence: high

Splunk SPL

index=network sourcetype="stream:tcp" "qSpeedTest:response_size:" earliest=-24h
| eval response_size_hex=replace(src_content,"(?s).*qSpeedTest:response_size:([0-9A-Fa-f]+);.*","\1")
| eval response_size=tonumber(response_size_hex,16)
| where response_size>=4194304
| stats count as packets min(_time) as first_seen max(_time) as last_seen max(response_size) as max_response_size values(dest_port) as dest_ports by src_ip dest_ip
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL

CommonSecurityLog
| where TimeGenerated > ago(24h)
| where Message has "qSpeedTest:response_size:" or AdditionalExtensions has "qSpeedTest:response_size:"
| extend Payload = strcat(Message, " ", AdditionalExtensions)
| extend ResponseSizeHex = extract(@"qSpeedTest:response_size:([0-9A-Fa-f]+);", 1, Payload)
| extend ResponseSize = tolong(strcat("0x", ResponseSizeHex))
| where ResponseSize >= 4194304
| summarize Packets = count(), MaxResponseSize = max(ResponseSize), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort
| project FirstSeen, LastSeen, SourceIP, DestinationIP, DestinationPort, Packets, MaxResponseSize

Sigma

title: LLDB debugserver qSpeedTest Oversized response_size Overflow Attempt (CVE-2025-43504)
id: 3b0a8c1e-4906-4f21-a001-5d1e7c2b9a01
status: experimental
description: Detects an IDS alert payload containing a GDB-remote qSpeedTest packet with response_size of 4MB or more, which overflows the static g_data buffer in LLDB debugserver pre-authentication.
references:
    - https://objective-see.org/blog/blog_0x83.html
    - https://support.apple.com/en-us/125641
    - https://github.com/llvm/llvm-project/commit/ac8e7be5fbd11f731ffc81bf3bbae50a5a4d83de
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/10/31
tags:
    - attack.initial-access
    - attack.t1190
    - attack.execution
    - attack.t1203
    - attack.impact
    - attack.t1499.004
    - cve.2025-43504
logsource:
    product: suricata
    service: eve
detection:
    selection:
        payload_printable|re: 'qSpeedTest:response_size:0*([4-9A-Fa-f][0-9A-Fa-f]{5}|[1-9A-Fa-f][0-9A-Fa-f]{6,});'
    condition: selection
falsepositives:
    - Fuzzing or protocol conformance testing of debugserver in a lab
    - Authorized penetration test replaying the public PoC
level: medium

Known false positives:

  • Authorized security testing replaying the Objective-See PoC against a lab device
  • Protocol fuzzers run by developer-tools teams against debugserver in an isolated network

Tuning notes: Requires full payload visibility (Splunk Stream src_content, Suricata payload_printable, or an NGFW/IDS that forwards payload into CommonSecurityLog). Add dest_port=1234 if your Stream capture covers many protocols. Values of 0x400000 and above are alerted because the fix rejects 4MB or more; the actual buffer overflow begins slightly above that (response_size > 0x40000A).

8 more detection rules (Splunk SPL, Microsoft KQL, Sigma) · unlock with TL Creds. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • debugserver qSpeedTest Packet Observed On The Wire — Exploitation Recon/Trigger · unlock with TL Creds
  • Python Process Crafting qSpeedTest GDB-Remote Packets — PoC Execution And Crash Report · unlock with TL Creds
  • Inbound Connection To debugserver Port 1234 From Unexpected Source · unlock with TL Creds
  • debugserver Launched Listening On Non-Loopback Interface — Exploitation Exposure · unlock with TL Creds
  • debugserver Terminated By SIGBUS/SIGSEGV/SIGABRT — Unified Log Exit Signature · unlock with TL Creds
  • External Source Connecting To debugserver Port 1234 — Perimeter Exposure · unlock with TL Creds
  • debugserver Repeated Crash Burst (SIGBUS/SIGSEGV/abort) — Impact · unlock with TL Creds
  • debugserver Port 1234 Fan-Out From One Source — Lateral Scan · unlock with TL Creds

Indicators of compromise for LLDB debugserver overflow

As of 2026-10-31, Threadlinqs Intelligence tracks 5 indicators of compromise for TL-2026-4906.

Sample indicators (2 of 5)

  • File hash: ac8e7be5fbd11f731ffc81bf3bbae50a5a4d83de
  • File hash: 37cd595c1ccb1fd84ebdfeb0d959744a4d13726c

Defanged, TLP:CLEAR. Full set of 5 indicators: unlock with TL Creds.

5 indicators of compromise · unlock with TL Creds. Compare plans

How LLDB debugserver overflow works

LLDB's debugserver implements the GDB remote serial protocol. In RNBRemote::HandlePacket_qSpeedTest(), the handler copies the prefix "data:" into a static global buffer declared as char g_data[4 * 1024 * 1024 + 16] and then calls memset(g_data + 5, 'a', response_size) using the attacker-supplied, unvalidated response_size from the packet qSpeedTest:response_size:<hex>;. Because the packet is parsed before any authentication or session setup, any remote client able to reach the debugserver TCP port (commonly 1234) can trigger the overflow. Objective-See's analysis describes the reachable target as an iOS device with a Developer Disk Image mounted.

The overflow writes past the end of g_data into adjacent .bss globals, notably the g_log_callback function pointer and the g_LogThreadedMutex synchronization primitive. Observed behavior depends on overflow depth: an overflow reaching only offset 0x4004AB writes a single NULL byte with no crash; overflowing 0x4004AC-0x40052B corrupts g_log_callback and yields SIGBUS when it is dereferenced; 0x40052C-0x402C62 corrupts the pthread mutex and causes abort(); and 0x402C63 and beyond runs into the guard page, producing SIGBUS/SIGSEGV.

Exploitation is constrained: the attacker controls only the length of the write, and the written content is always ASCII 'a' (0x61), which prevents reliable pointer hijacking. With modern mitigations the realistic outcome is denial of service of the debug service, and code execution would require pairing with an additional vulnerability. The research includes a Python proof-of-concept that frames packets as $<payload>#<checksum> and sends oversized response_size values.

Apple remediated the issue in Xcode 26.1 (released 2025-11-03) with improved bounds checking. The upstream LLVM fix (commit ac8e7be5fbd11f731ffc81bf3bbae50a5a4d83de, '[lldb][debugserver] Max response size for qSpeedTest (#156099)') moves the buffer to a heap-allocated std::vector and rejects response sizes of 4MB or more. Note a scoring discrepancy between sources: NVD scores the flaw CVSS 4.9 (AV:N/AC:L/PR:H, availability impact only) and Apple describes it as exploitable by a user in a privileged network position, whereas Objective-See characterizes it as pre-authentication at the protocol level. No in-the-wild exploitation, threat actor attribution, or network IOCs are reported in any source.

MITRE ATT&CK techniques by tactic:

Initial Access

T1190 Exploit Public-Facing Application

Execution

T1203 Exploitation for Client Execution

Impact

T1499.004 Application or System Exploitation

Remediation for LLDB debugserver overflow

Patches

  • Update to Xcode 26.1 or later (Apple security content, 2025-11-03)
  • Upstream LLVM fix: commit ac8e7be5fbd11f731ffc81bf3bbae50a5a4d83de (qSpeedTest response size capped at 4MB, heap allocation)

Immediate actions

  • Do not expose the debugserver TCP port (commonly 1234) to untrusted networks; restrict access to the developer workstation and the device via host firewall or network segmentation
  • Unmount Developer Disk Images and disable developer mode on iOS devices that do not require debugging
  • Hunt for repeated debugserver crashes (SIGBUS/SIGSEGV/abort) correlated with inbound connections to the debug port

Workarounds

  • Avoid running debugserver listening on non-loopback interfaces
  • Block inbound connections to the debugserver port from untrusted hosts

Longer-term hardening

  • Keep developer tooling (Xcode, LLDB toolchains) on current releases and inventory third-party LLDB/LLVM builds that embed debugserver
  • Treat developer debugging services as attack surface in network access policy and monitoring

Affected and fixed versions

  • Apple — Xcode (LLDB debugserver)
    Vulnerable versions: Xcode versions before 26.1
    Fixed in: Xcode 26.1
  • LLVM Project — LLDB debugserver (lldb/tools/debugserver/source/RNBRemote.cpp)
    Vulnerable versions: Builds prior to commit ac8e7be5fbd11f731ffc81bf3bbae50a5a4d83de
    Fixed in: Builds including commit ac8e7be5fbd11f731ffc81bf3bbae50a5a4d83de

Timeline of LLDB debugserver overflow

  • Jason Molenda opens LLVM pull request #156099 '[lldb][debugserver] Max response size for qSpeedTest', moving the buffer to a heap std::vector and capping response size at 4MB
  • LLVM PR #156099 approved by JDevlieghere and merged as commit locked-ioc-2
  • Apple publishes security content for Xcode 26.1 listing CVE-2025-43504 (lldb component) for macOS Sequoia 15.6 and later
  • Apple releases Xcode 26.1, fixing the debugserver buffer overflow with improved bounds checking (credit: Nathaniel Oh, @calysteon)
  • CVE-2025-43504 published in NVD (CVSS 3.1 base score 4.9, CWE-119)
  • Objective-See publishes a technical analysis and Python proof-of-concept for the qSpeedTest overflow
  • NVD record for CVE-2025-43504 last modified

Sources cited for LLDB debugserver overflow

Drafted by the Threadlinqs research pipeline from 6 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats