CVE-2024-38653

What it actually does

CVE-2024-38653 is an XML External Entity (XXE) vulnerability in SmartDeviceServer in Ivanti Avalanche 6.3.1. A remote unauthenticated attacker can submit crafted XML that causes the server-side XML parser to resolve attacker-controlled external entities, allowing the attacker to read arbitrary files accessible to the SmartDeviceServer process. The direct technical impact is high-confidentiality file disclosure, including potential exposure of configuration files, credentials, keys, service account data, logs, or operating-system files. The CVSS vector indicates network exploitability, low attack complexity, no required privileges, and no user interaction.

Why it matters to the business

Successful exploitation can expose sensitive server-side files from an Ivanti Avalanche deployment, potentially revealing credentials or configuration data that enable broader compromise of mobile device management, warehouse, logistics, or endpoint management operations. Because the vulnerability is reported as weaponized and has a very high EPSS score, internet-exposed or broadly reachable Avalanche servers should be treated as high-priority remediation targets even though the issue is not currently listed in CISA KEV and is not known from the provided data to be used in ransomware campaigns.

How an attack unfolds

An attacker first identifies an exposed Ivanti Avalanche SmartDeviceServer instance, then sends a specially crafted XML request containing a malicious DOCTYPE and external entity declaration. When the vulnerable server parses the XML, it attempts to resolve the external entity, such as a local file reference using a file URI. If the application includes the resolved entity in a response, error message, or downstream processing path, the attacker receives the contents of the targeted file. The attacker typically begins with proof-of-access files, then attempts to retrieve application configuration, credential stores, certificates, keys, and logs. Any recovered secrets may then be used to authenticate to Avalanche components, connected databases, directory services, managed device infrastructure, or adjacent systems.

How to fix it

Upgrade Ivanti Avalanche to a vendor-supported release that fixes this XXE issue; no exact fixed version was provided in the input, so consult Ivanti’s advisory and apply the latest available security update or maintenance release for Avalanche. If immediate upgrade is not possible, restrict access to SmartDeviceServer to trusted management networks only, block direct internet access, place the service behind authenticated access controls or VPN, and enforce firewall rules limiting source IPs. Disable XML external entity processing and DTD resolution if configurable, and ensure XML parsers use secure settings that prevent external entity expansion, external schema loading, and file URI resolution. Rotate credentials, certificates, API tokens, and service account secrets that may have been readable by the Avalanche service, especially if the server was externally reachable before remediation.

How to confirm the fix worked

Confirm all Ivanti Avalanche instances are inventoried and no longer running vulnerable version 6.3.1. Verify the installed build against Ivanti’s fixed-version guidance or latest supported release notes. From an approved test environment, validate that XML requests containing DOCTYPE and external entity declarations are rejected, sanitized, or processed without resolving local files or generating outbound callbacks. Review firewall and access-control rules to confirm SmartDeviceServer is not exposed to untrusted networks. Confirm that sensitive files cannot be retrieved through the affected interface and that application logs show rejected XML payloads rather than successful parsing. After patching or mitigation, rescan externally and internally to verify that only intended management endpoints are reachable.

Typical attack path

1. Scan for Ivanti Avalanche SmartDeviceServer instances exposed to the internet or reachable from attacker-controlled network locations.
2. Confirm the target is a vulnerable Ivanti Avalanche 6.3.1 deployment or otherwise susceptible to XXE parsing behavior.
3. Send a crafted XML payload containing a DOCTYPE declaration and external entity reference.
4. Reference a local file through the external entity, such as an operating-system or application configuration file.
5. Observe the server response, error output, or out-of-band callback to confirm entity resolution.
6. Iteratively request higher-value files such as configuration files, credentials, certificates, keys, and logs.
7. Use any exposed secrets to expand access to Avalanche services, managed device infrastructure, databases, or adjacent enterprise systems.

How to detect it

Look for evidence of malicious XML submitted to SmartDeviceServer or related Avalanche HTTP/XML endpoints. Review reverse proxy, load balancer, web server, and application logs for requests containing XML DOCTYPE declarations, ENTITY definitions, SYSTEM or PUBLIC identifiers, file URI references, and requests attempting to read sensitive paths such as /etc/passwd, /etc/shadow, /proc/self/environ, C:\Windows\win.ini, or application configuration files. Check application logs for XML parser errors, DTD processing messages, entity expansion errors, file access exceptions, or unusual stack traces around XML parsing. Review EDR and operating-system telemetry for the Avalanche service process reading unusual files outside expected application directories. Inspect DNS and egress HTTP logs for out-of-band XXE callbacks to unfamiliar domains or attacker-controlled infrastructure, because some XXE probes validate vulnerability by forcing the server to make external requests. If suspicious file disclosure is found or the server was exposed while vulnerable, investigate for subsequent authentication events using exposed credentials, access to management consoles, database logins, new administrative users, and changes to managed device configuration.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• SYSTEM 'file://
• PUBLIC "-//
• file:///etc/passwd
• file:///etc/shadow
• file:///proc/self/environ
• file:///proc/version
• file:///C:/Windows/win.ini
• file:///C:/Windows/System32/drivers/etc/hosts
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• C:\Windows\win.ini
• C:\Windows\System32\drivers\etc\hosts
• java.io.FileNotFoundException
• SAXParseException
• DOCTYPE is disallowed
• External Entity
• external entity
• EntityResolver
• DocumentBuilderFactory
• SAXParserFactory

What your security team should do

• Treat this as urgent for any internet-exposed Ivanti Avalanche deployment because exploitation is weaponized and EPSS is very high.
• Immediately inventory Avalanche servers and identify any instances running version 6.3.1 or unverified builds.
• Patch to a fixed vendor-supported release as soon as possible; if no fixed version is available for the deployed branch, upgrade to the latest supported Avalanche release recommended by Ivanti.
• Restrict SmartDeviceServer access to trusted administrative networks and remove direct internet exposure.
• Hunt for prior exploitation using web, reverse proxy, application, EDR, DNS, and network telemetry for XXE payloads and suspicious file-read attempts.
• Rotate secrets that may be accessible to the Avalanche service, including application credentials, database credentials, service account passwords, certificates, and API tokens.
• Add WAF or reverse-proxy detection rules for XML payloads containing DOCTYPE, ENTITY, SYSTEM, PUBLIC, file URI, and common sensitive file paths.
• Monitor for follow-on activity using any credentials or configuration data that may have been disclosed.