CVE-2026-71979 Overview
CVE-2026-71979 is a stack buffer overflow vulnerability in INDI (Instrument Neutral Distributed Interface) indiserver through version 2.2.4.2. Unauthenticated remote attackers can crash the daemon by sending malformed XML with mismatched tags whose names exceed 1024 bytes. A single TCP packet on port 7624 triggers an unbounded sprintf() write into a fixed 1024-byte stack buffer in MsgQueue.cpp. The condition terminates the daemon and disrupts all active client and driver sessions. The flaw is classified as CWE-121 Stack-based Buffer Overflow and is fixed in commit 96bbd7f.
Critical Impact
Remote unauthenticated attackers can crash the indiserver daemon with a single TCP packet, disconnecting all connected astronomy instruments and clients.
Affected Products
- INDI indiserver versions up to and including 2.2.4.2
- INDI library components consuming lilxml error buffers (MsgQueue.cpp, drivers/auxiliary/joystick.cpp)
- Systems exposing INDI protocol on TCP port 7624
Discovery Timeline
- 2026-08-17 - CVE-2026-71979 published to NVD
- 2026-08-17 - Last updated in NVD database
Technical Details for CVE-2026-71979
Vulnerability Analysis
The vulnerability resides in the XML chunk parsing path of indiserver. When a client submits XML with a mismatched closing tag, the underlying lilxml library formats an error message describing the offending tag names. The caller in MsgQueue.cpp supplies a fixed 1024-byte stack buffer to receive that error string. The library uses sprintf() without bounding the length of the tag names copied into the buffer.
An attacker can supply a tag name longer than 1024 bytes, causing the formatted error message to overflow the stack buffer. The overwrite corrupts adjacent stack frames and terminates the daemon process. Because indiserver is a single-process broker that multiplexes clients and hardware drivers, its termination disconnects every active astronomy instrument, telescope mount, camera driver, and control client bound to the server.
Root Cause
The parseXMLChunk() function writes error output through sprintf() into an undersized destination. In indiserver/MsgQueue.cpp, the destination is declared as char err[1024], while lilxml may produce error strings that embed attacker-controlled tag names exceeding this size. The upstream fix introduces a shared constant XML_ERROR_SIZE and enlarges the destination buffer to match the library's worst-case output.
Attack Vector
Exploitation requires only network reach to TCP port 7624 and no authentication. The attacker sends a single TCP payload containing an opening XML element followed by a closing tag whose name exceeds 1024 bytes. The malformed input drives the error-formatting path and overflows the fixed stack buffer, causing daemon termination.
// Source: https://github.com/indilib/indi/commit/96bbd7f564bbb128a129019e44eadd40dd49cff9
// Patch in indiserver/MsgQueue.cpp - replaces fixed 1024-byte stack buffer
// with library-defined XML_ERROR_SIZE constant to prevent overflow
}
/* process XML chunk */
- char err[1024];
+ char err[XML_ERROR_SIZE];
XMLEle **nodes = parseXMLChunk(lp, buf, nr, err);
if (!nodes)
{
// Source: https://github.com/indilib/indi/commit/96bbd7f564bbb128a129019e44eadd40dd49cff9
// Patch in drivers/auxiliary/joystick.cpp - same undersized buffer
// pattern corrected to use XML_ERROR_SIZE
return false; // file does not exist yet — normal on first use
LilXML *lp = newLilXML();
- static char errmsg[512];
+ static char errmsg[XML_ERROR_SIZE];
XMLEle *root = readXMLFile(fp, lp, errmsg);
fclose(fp);
delLilXML(lp);
Detection Methods for CVE-2026-71979
Indicators of Compromise
- Unexpected termination of the indiserver process, followed by simultaneous disconnection of all connected clients and drivers.
- Core dumps or crash logs referencing parseXMLChunk or MsgQueue.cpp stack frames.
- Inbound TCP connections to port 7624 carrying XML payloads with tag names longer than 1024 bytes.
Detection Strategies
- Inspect network traffic to port 7624 for XML payloads containing tag names that exceed 1024 bytes or contain mismatched open/close elements.
- Monitor process supervision logs (systemd, supervisord) for repeated indiserver restart events.
- Alert on abnormal client churn where all active INDI sessions drop within the same second.
Monitoring Recommendations
- Capture and retain indiserver stderr and core dumps for post-crash analysis.
- Deploy network intrusion detection signatures that flag oversized XML element names in cleartext INDI traffic.
- Track TCP connection frequency to port 7624 from external sources and alert on unauthenticated connections from untrusted networks.
How to Mitigate CVE-2026-71979
Immediate Actions Required
- Update indiserver to a build that includes commit 96bbd7f or a release later than 2.2.4.2.
- Restrict TCP port 7624 to trusted management networks using host or perimeter firewalls.
- Restart any long-running indiserver instances after patching to load the corrected binary.
Patch Information
The fix is committed to the INDI repository as 96bbd7f564bbb128a129019e44eadd40dd49cff9. It replaces the undersized char err[1024] and char errmsg[512] buffers with the library-defined XML_ERROR_SIZE constant in indiserver/MsgQueue.cpp and drivers/auxiliary/joystick.cpp. Rebuild INDI from the patched source or install a downstream package containing the commit. See the GitHub commit, GitHub issue #2472, and the VulnCheck advisory.
Workarounds
- Bind indiserver to localhost and require SSH tunneling for remote client access.
- Place indiserver behind a reverse proxy or firewall rule that rejects TCP payloads with oversized XML element names.
- Run indiserver under a process supervisor that restarts the daemon automatically to reduce observatory downtime until patching completes.
# Example iptables rule limiting INDI port 7624 to a trusted subnet
iptables -A INPUT -p tcp --dport 7624 -s 192.0.2.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 7624 -j DROP
# Run indiserver bound to loopback only
indiserver -v -m 100 -p 7624 indi_simulator_telescope &
# Access remotely via SSH tunnel:
# ssh -L 7624:127.0.0.1:7624 user@observatory-host
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

