CVE-2024-47011

What it actually does

CVE-2024-47011 is a path traversal vulnerability in Ivanti Avalanche versions before 6.4.5. A remote, unauthenticated attacker can craft HTTP requests containing directory traversal sequences to cause the Avalanche server to read and return files outside the intended web or application directory. The flaw primarily enables sensitive information disclosure, such as configuration files, application data, credentials, logs, certificates, or other locally readable files available to the Avalanche service account. The impact depends on the permissions of the service process and the sensitivity of files present on the host.

Why it matters to the business

Successful exploitation can expose sensitive operational and authentication data from an Ivanti Avalanche deployment, potentially giving attackers information needed to expand access, target managed devices, or prepare follow-on attacks. Because the issue is remotely reachable, unauthenticated, and has a high EPSS score, exposed Avalanche servers should be treated as higher-priority remediation targets even though the vulnerability is not currently listed in CISA KEV and no ransomware use is reported. Organizations using Avalanche for mobile device or warehouse device management may face disruption, credential compromise, and increased risk to managed endpoint fleets if exposed data is reused for lateral movement.

How an attack unfolds

An attacker first identifies an internet-facing or internally reachable Ivanti Avalanche instance running a vulnerable version before 6.4.5. The attacker sends specially crafted HTTP requests to affected Avalanche endpoints using path traversal sequences such as ../ or encoded variants to escape the expected file path. If the request is accepted, the server resolves the attacker-controlled path and returns file contents that should not be accessible through the web interface. The attacker then reviews leaked files for credentials, service configuration, database connection details, certificates, device management information, logs, or other sensitive data. That information can be used to authenticate to related services, map the environment, target managed devices, or support subsequent intrusion activity.

How to fix it

Upgrade Ivanti Avalanche to version 6.4.5 or later. If immediate upgrade is not possible, restrict access to Avalanche management interfaces using VPN, firewall rules, network allowlists, and administrative segmentation; block unauthenticated access from untrusted networks; and monitor or filter requests containing traversal sequences. Review service account permissions and ensure the Avalanche process cannot read sensitive operating system files or unrelated application data. Rotate credentials, API keys, database passwords, certificates, and other secrets that may have been stored in files readable by the Avalanche service if exploitation is suspected. After patching, remove temporary mitigations only after confirming the instance is no longer vulnerable.

How to confirm the fix worked

Confirm the installed Ivanti Avalanche version is 6.4.5 or later through the product console, host inventory, software package records, or vendor-supported version checks. Validate that externally reachable Avalanche services are no longer exposing vulnerable behavior by performing an authorized security test using benign traversal payloads against known affected routes and confirming files outside the intended directory are not returned. Review network exposure to ensure Avalanche management ports are not reachable from untrusted networks unless explicitly required. Confirm compensating controls such as WAF rules, reverse proxy filtering, and access control lists block traversal patterns including encoded variants.

Typical attack path

1. Scan for Ivanti Avalanche services exposed to the internet or reachable from compromised internal systems.
2. Fingerprint the Avalanche version or test behavior consistent with versions before 6.4.5.
3. Send crafted HTTP requests containing path traversal sequences or encoded traversal variants to vulnerable endpoints.
4. Retrieve files outside the intended application directory if the server improperly resolves the path.
5. Extract credentials, configuration values, certificates, logs, or device-management data from disclosed files.
6. Use the disclosed information to support credential attacks, lateral movement, or further compromise of managed infrastructure.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs from Ivanti Avalanche, reverse proxies, load balancers, WAFs, and perimeter devices for requests containing directory traversal sequences such as ../, ..\, %2e%2e%2f, %2e%2e%5c, double-encoded traversal, or requests attempting to access operating system or application configuration files. Correlate suspicious requests with 200 responses, unusually large response sizes, file download behavior, or repeated probing across multiple paths. Review application logs for file access errors, invalid path exceptions, canonicalization failures, or requests for unexpected local files. On the host, inspect EDR and operating system telemetry for the Avalanche service process reading files outside its application directory, especially credential stores, configuration files, certificates, logs, or system files. If suspected exploitation is confirmed, investigate subsequent authentication events, remote access attempts, database logins, administrative console activity, and access to managed-device infrastructure using any secrets that could have been exposed.

• ../
• ..\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• %2e%2e%5c
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /proc/self/environ
• C:\Windows\win.ini
• C:\Windows\System32\drivers\etc\hosts
• boot.ini
• web.config
• application.properties
• application.yml
• database.properties
• jdbc.properties
• keystore
• truststore
• .jks
• .p12
• .pem
• .key

What your security team should do

• Prioritize upgrading all Ivanti Avalanche deployments to version 6.4.5 or later, especially internet-facing systems.
• Identify all Avalanche instances and verify whether any are reachable from untrusted networks.
• Restrict access to Avalanche management interfaces to approved administrative networks or VPN users only.
• Search web, reverse proxy, WAF, and EDR telemetry for traversal attempts against Avalanche endpoints since at least the vulnerability publication date.
• If suspicious access is found, treat disclosed local files as potentially compromised and rotate exposed credentials and secrets.
• Review Avalanche service account permissions and reduce file-system read access to the minimum required.
• Add SIEM detections for traversal strings, encoded traversal patterns, and abnormal file-read responses from Avalanche servers.
• Monitor for follow-on activity using credentials or configuration data that may have been stored on the Avalanche host.