Stack-based buffer overflow in scandir.sgi affects D-Link DIR-868L

D-Link DIR-868L Hardware version A1, firmware version 1.12 is vulnerable to Buffer Overflow. The vulnerability is in scandir.sgi binary.

• The normalized record identifies D-Link DIR-868L hardware revision A1 with firmware version 1.12 as affected.
• NVD maps firmware version 1.12 to hardware revision A1 of the DIR-868L.
• D-Link's advisory is presented for the DIR-868L across all hardware revisions and all firmware revisions; its product table lists fixed firmware as Not Available and identifies the product as EOL/EOS.
• The broader vendor scope is not broken into exact version branches. Therefore, the status of each firmware branch other than version 1.12 cannot be independently inferred from the normalized record.

The vulnerability is in the scandir.sgi binary of D-Link DIR-868L. D-Link's advisory states that a query field in an HTTP request header is parsed as input and that user-supplied data is copied into a fixed-length stack buffer without adequate length validation. This is a classic buffer overflow, classified by NVD as CWE-120. The advisory describes a post-authentication attack, while the supplied assessment describes network reachability without required privileges or user interaction; the available evidence does not resolve this difference. The advisory does not disclose the exact endpoint, exploit data, control-flow result, or details that would confirm code execution.

The supplied assessment describes the vulnerability as network-reachable, low-complexity, requiring no authentication and no user interaction. D-Link's advisory instead calls it a post-authentication buffer overflow attack. Because these descriptions are inconsistent, the actual authentication requirement should be verified in the deployed environment. The available evidence confirms a third-party disclosure, but does not establish active exploitation, a public exploit, a named campaign, or specific indicators of compromise.

The flaw can cause data to overflow a stack buffer and corrupt the state of the processing path on the router. If the resulting condition can be controlled, possible outcomes include compromise of confidentiality, modification of integrity, or disruption of availability. The supplied assessment records impact to all three properties, but the available sources do not confirm a specific code-execution path. The described scope is unchanged, and there is no evidence establishing impact to other systems or a broader network intrusion.

• A compromised router could lose confidentiality, integrity, or availability, consistent with the impacts recorded in the supplied assessment.
• Operational consequences could include loss of trust in the router, altered traffic-handling behavior, or service disruption, although the available evidence does not confirm any specific outcome.
• Because the device operates at the network edge, compromise could increase risk to systems and devices that rely on it; a pivot into the internal network is not established.
• D-Link states that the product is EOL/EOS and no longer receives firmware updates or security patches, increasing the long-term operational risk of continued use.

1. Retire and replace the device first. D-Link recommends discontinuing use of the DIR-868L and replacing it because the product is EOL/EOS.
2. No fixed firmware is confirmed for version 1.12 in the available evidence. Do not treat the last firmware listed on the legacy website as a confirmed security fix.
3. If immediate replacement is not possible, identify the installed firmware and use the last firmware D-Link publishes for the correct model and region, treating this only as a temporary risk-reduction measure.
4. Following D-Link's guidance, regularly change the unique password used for web configuration and enable Wi-Fi encryption with a unique password.
5. Contact the relevant D-Link regional office for replacement or EOL/EOS product guidance.

• Inventory active D-Link DIR-868L devices, including hardware revision and firmware, and compare them with the affected branches in the asset-management system.
• Determine whether each device contains the scandir.sgi binary and exposes an HTTP administration service.
• Review HTTP administration logs for unusual request headers or query fields. This is precautionary monitoring, not a vendor-confirmed IOC.
• Check whether the device is EOL/EOS and record systems that no longer receive security updates.
• Do not treat the absence of suspicious log entries as proof of safety because the advisory does not provide a log signature or specific IOC.