Threat reportVulnerabilityTL-2026-4906
CVE-2025-43504: Remote Pre-Authentication Buffer Overflow in LLDB debugserver (Xcode / iOS Developer Disk Image)
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
| Identifiers | TL-2026-4906, CVE-2025-43504 |
|---|---|
| Severity | MEDIUM |
| CVSS | 4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H) |
| First disclosed | |
| Exploitation status | Public proof-of-concept exploit |
| EPSS | CVE-2025-43504: 0.3% (31.3th percentile) |
| Affected products | Apple Xcode (LLDB debugserver); LLVM Project LLDB debugserver (lldb/tools/debugserver/source/RNBRemote.cpp) |
| Weaknesses (CWE) | CWE-119 |
| MITRE ATT&CK techniques | T1190 Exploit Public-Facing Application, T1203 Exploitation for Client Execution, T1499.004 Application or System Exploitation |
| Motivation | UNKNOWN |
| Target sectors | technology, software development |
| Target regions | Global |
| Detection rules | 9 (1 shown free) |
| Sources | 6 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, MaxResponseSizeSigma
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).
- 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.
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
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
- NVD - CVE-2025-43504 NVD (NIST) · Advisory · 2025-11-04
- When Good /bins Go Bad: A Remote Pre-Authentication Overflow in LLDB's debugserver objective-see.org · Research · 2025-12-07
- About the security content of Xcode 26.1 Apple · Vendor report · 2025-11-03
- LLVM commit ac8e7be: [lldb][debugserver] Max response size for qSpeedTest (#156099) GitHub · Code repository
- LLVM pull request #156099: Max response size for qSpeedTest GitHub · Code repository
- CVEmon: CVE-2025-43504 cvemon.intruder.io · News
Drafted by the Threadlinqs research pipeline from 6 sources; published ; last updated —.