CVE-2024-51977

What it actually does

This vulnerability allows an unauthenticated network attacker to retrieve sensitive device information by sending a simple HTTP GET request for `/etc/mnt_info.csv` to a vulnerable device over HTTP, HTTPS, or IPP-accessible web services on TCP ports 80, 443, or 631. The exposed CSV data can include the device model, firmware version, IP address, and serial number. The flaw does not directly allow code execution, privilege escalation, data modification, or service disruption, but it provides reliable reconnaissance data that can help attackers identify vulnerable devices, fingerprint firmware, and plan follow-on attacks.

Why it matters to the business

An exposed vulnerable device can disclose inventory and configuration details to anyone who can reach its network service. While the immediate impact is limited to information leakage, the risk is elevated because the issue is weaponized and has a high EPSS likelihood of exploitation. Attackers can use the leaked model, firmware, IP address, and serial number to identify targets for later compromise, prioritize vulnerable devices, support phishing or social engineering, or map an organization’s network-connected device fleet. Organizations with internet-exposed printers, multifunction devices, or embedded appliances are at higher operational risk because these systems are often overlooked in patching and monitoring programs.

How an attack unfolds

An attacker first scans for devices exposing HTTP, HTTPS, or IPP services on TCP ports 80, 443, or 631. After identifying a reachable service, the attacker sends an unauthenticated GET request to `/etc/mnt_info.csv`. If the device is vulnerable, it returns a CSV-formatted response containing sensitive device metadata such as model, firmware version, IP address, and serial number. The attacker can then use this information to fingerprint the device, determine whether it is running vulnerable firmware, correlate the serial number with asset or support information, and select additional exploits or intrusion paths. Because the request requires no credentials, no user interaction, and low attack complexity, exploitation can be automated at internet scale.

How to fix it

Apply the vendor-provided firmware or software update that removes unauthenticated access to `/etc/mnt_info.csv`. No exact fixed versions were provided in the input, so administrators should consult the affected device vendor’s security advisory and upgrade all vulnerable models to the latest available firmware. If immediate patching is not possible, restrict access to device management interfaces and IPP services so they are reachable only from trusted administrative networks. Block internet access to TCP ports 80, 443, and 631 on affected devices unless explicitly required. Place embedded devices behind firewalls or management VLANs, disable unused HTTP/HTTPS/IPP services where supported, and enforce authenticated administrative access. Treat exposed serial numbers, firmware versions, and IP addresses as potentially compromised information if the device was reachable by untrusted networks.

How to confirm the fix worked

Confirm remediation by attempting to access `http://<device>/etc/mnt_info.csv`, `https://<device>/etc/mnt_info.csv`, and, where applicable, the same path through the IPP-exposed service on TCP port 631 from an unauthenticated client. A remediated or properly mitigated device should reject the request, require authentication, return a 403/404 response, or be unreachable from untrusted networks. Validate that firewall rules prevent access to TCP ports 80, 443, and 631 from the internet or other unauthorized network segments. Inventory network-connected devices and compare their firmware versions against the vendor’s fixed release guidance. Review vulnerability scanner results to ensure no assets still expose `/etc/mnt_info.csv` without authentication.

Typical attack path

1. Scan public or internal address ranges for services listening on TCP ports 80, 443, or 631.
2. Send an unauthenticated HTTP GET request for `/etc/mnt_info.csv`.
3. Parse the returned CSV response for model, firmware version, IP address, and serial number.
4. Use the disclosed firmware and model information to identify additional known vulnerabilities or weak configurations.
5. Target the device or surrounding network with follow-on exploitation, credential attacks, phishing, or lateral reconnaissance.

How to detect it

To determine whether exploitation already occurred, review logs from device web services, reverse proxies, firewalls, web gateways, IDS/IPS sensors, and network flow tools for unauthenticated requests to `/etc/mnt_info.csv` over TCP ports 80, 443, or 631. Look for HTTP GET requests to that path, especially from external IP addresses, vulnerability scanners, unusual internal hosts, or repeated requests across many devices. If device-level logs are limited, use firewall or NetFlow records to identify connections to embedded devices on ports 80, 443, and 631 followed by subsequent reconnaissance or exploitation attempts. Proxy and web access logs may show cleartext HTTP requests directly; HTTPS inspection logs, endpoint network telemetry, or device logs may be needed for encrypted traffic. Investigate any successful HTTP 200 responses for `/etc/mnt_info.csv` as likely information disclosure. After a confirmed hit, review surrounding activity from the same source IP for additional paths, login attempts, firmware-specific exploit probes, port scanning, or lateral movement attempts.

• GET /etc/mnt_info.csv
• /etc/mnt_info.csv
• GET http://*/etc/mnt_info.csv
• GET https://*/etc/mnt_info.csv
• TCP/80 request path /etc/mnt_info.csv
• TCP/443 request path /etc/mnt_info.csv
• TCP/631 request path /etc/mnt_info.csv
• HTTP 200 /etc/mnt_info.csv
• "/etc/mnt_info.csv" "200"
• "GET /etc/mnt_info.csv HTTP/1.1"

What your security team should do

• Prioritize identifying any internet-exposed devices with TCP ports 80, 443, or 631 open, because exploitation is weaponized and EPSS is high.
• Run targeted checks for unauthenticated access to `/etc/mnt_info.csv` across printer, multifunction device, and embedded-device address ranges.
• Patch vulnerable devices to the latest vendor firmware as soon as practical, especially systems exposed beyond trusted management networks.
• If patching is delayed, restrict HTTP, HTTPS, and IPP access using firewall rules, ACLs, management VLANs, or VPN-only administration.
• Add SIEM detections for requests to `/etc/mnt_info.csv`, including both successful and failed attempts.
• Review historical web, proxy, firewall, IDS/IPS, and device logs for evidence of prior access to the exposed path.
• Treat any confirmed successful access from an untrusted source as reconnaissance and investigate for follow-on scanning or exploitation activity against the same device or network segment.
• Include embedded and peripheral devices in regular asset inventory, vulnerability management, and firmware lifecycle processes.