CVE-2023-28128

What it actually does

The vulnerability is an unrestricted upload of a dangerous file type in Ivanti Avalanche 6.3.x and earlier. An attacker with high-privilege access to the Avalanche interface can upload a server-executable payload instead of an expected safe file type. If the uploaded file is stored in a location where the Avalanche application server can execute or process it, the attacker can achieve remote code execution with the privileges of the Avalanche service account. Successful exploitation can lead to full compromise of the Avalanche server, including access to managed device data, application configuration, credentials or tokens available to the service, and the ability to pivot further into the network.

Why it matters to the business

Compromise of an Ivanti Avalanche server can disrupt mobile device, warehouse, and endpoint management operations, expose sensitive device and operational data, and provide an attacker with a foothold in infrastructure that often has broad reach into managed environments. Although exploitation requires high privileges, the issue has a high EPSS score and weaponized exploit maturity, making it important to remediate quickly wherever Avalanche 6.3.x or earlier remains deployed.

How an attack unfolds

An attacker first obtains high-privilege access to the Ivanti Avalanche management interface, such as through stolen administrator credentials, credential reuse, phishing, or compromise of an existing privileged session. The attacker then uses a file upload feature that fails to properly restrict dangerous file types and submits a payload such as a server-executable script, archive, or application component. If Avalanche stores or deploys that file in an executable context, the attacker triggers it through the web interface, a direct HTTP request, or application processing behavior. The payload then runs on the Avalanche server under the application service account, allowing command execution, web shell deployment, credential theft, persistence, data collection, and lateral movement.

How to fix it

Upgrade Ivanti Avalanche to a vendor-supported release that is newer than 6.3.x and includes the vendor fix for this upload validation flaw. If an exact fixed version is not available in internal records, consult Ivanti’s advisory and release notes and move to the latest supported Avalanche version rather than remaining on any 6.3.x or earlier build. Restrict access to the Avalanche management interface to trusted administrative networks or VPN-only access. Enforce MFA for administrative accounts, review and reduce privileged Avalanche users, rotate credentials if compromise is suspected, and remove any uploaded files that are not expected application content. As interim mitigation, block uploads of executable server-side extensions at a reverse proxy or WAF where feasible, including JSP, JSPX, WAR, JAR, CLASS, ASPX, PHP, EXE, DLL, BAT, CMD, PS1, SH, and similar dangerous types.

How to confirm the fix worked

Confirm that all Avalanche instances are running a fixed, vendor-supported version newer than 6.3.x. Validate that the management interface is not publicly reachable unless explicitly required and is restricted to trusted administrative sources. Test the upload workflow using benign files with dangerous extensions in a non-production or approved test environment and confirm the application rejects them. Review application directories and upload storage locations for unexpected executable files, especially files created before remediation. Confirm administrative accounts have MFA enabled, unused privileged accounts are disabled, and credentials associated with Avalanche service accounts or administrators have been rotated where suspicious activity exists.

Typical attack path

1. Identify an exposed Ivanti Avalanche management interface or access it from an internal network segment.
2. Obtain high-privilege Avalanche credentials or hijack an authenticated privileged session.
3. Use the vulnerable upload functionality to submit a dangerous server-side file type or payload.
4. Cause the uploaded payload to be executed by the Avalanche application server or related service.
5. Run operating system commands with the privileges of the Avalanche service account.
6. Deploy persistence such as a web shell, scheduled task, service, or additional payload.
7. Collect configuration files, credentials, device-management data, and network information.
8. Use the compromised server to pivot to managed devices or adjacent internal systems.

How to detect it

Review Avalanche application logs, web access logs, reverse proxy logs, WAF logs, Windows Event Logs or Linux audit logs, EDR telemetry, and file-system timestamps for signs of suspicious upload followed by execution. Focus on authenticated administrative sessions that performed file uploads, especially uploads with executable extensions or unusual MIME types. Look for HTTP multipart upload requests containing filenames ending in server-executable extensions, followed by requests that access the uploaded file. On the host, look for newly created JSP, JSPX, WAR, JAR, CLASS, ASPX, PHP, EXE, DLL, BAT, CMD, PS1, or SH files in Avalanche web, application, deployment, temporary, or upload directories. Investigate any Avalanche application process spawning shell interpreters, scripting engines, download utilities, reconnaissance commands, archive tools, or credential access tools. Review privileged login history for unusual source IP addresses, off-hours activity, new administrator accounts, configuration changes, and unexpected service restarts around the time of suspicious uploads.

• multipart/form-data
• filename="*.jsp"
• filename="*.jspx"
• filename="*.war"
• filename="*.jar"
• filename="*.class"
• filename="*.aspx"
• filename="*.php"
• filename="*.exe"
• filename="*.dll"
• filename="*.bat"
• filename="*.cmd"
• filename="*.ps1"
• filename="*.sh"
• Content-Type: application/x-java-archive
• Content-Type: application/java-archive
• Content-Type: application/octet-stream
• java.exe -> cmd.exe
• java.exe -> powershell.exe
• java.exe -> powershell_ise.exe
• java.exe -> pwsh.exe
• java.exe -> wscript.exe
• java.exe -> cscript.exe
• java.exe -> certutil.exe
• java.exe -> bitsadmin.exe
• java.exe -> curl.exe
• java.exe -> wget.exe
• java -> /bin/sh
• java -> /bin/bash
• java -> curl
• java -> wget
• C:\Program Files\Wavelink\Avalanche\
• C:\Program Files (x86)\Wavelink\Avalanche\
• C:\Program Files\Ivanti\Avalanche\
• C:\Program Files (x86)\Ivanti\Avalanche\

What your security team should do

• Immediately inventory all Ivanti Avalanche deployments and prioritize any version 6.3.x or earlier for upgrade or isolation.
• Treat internet-exposed or broadly accessible Avalanche management interfaces as high priority because exploit code is considered weaponized and EPSS is high.
• Restrict Avalanche administrative access to trusted networks, VPN, or privileged access management paths only.
• Review Avalanche administrator accounts, enable MFA, remove stale privileged users, and investigate recent privileged logins.
• Hunt for suspicious uploads, new executable files, web shells, and child processes spawned by the Avalanche application service.
• If suspicious activity is found, isolate the server, preserve forensic evidence, rotate Avalanche administrator and service credentials, and review downstream managed-device trust relationships.
• Add WAF or reverse-proxy controls to block dangerous file extensions in upload requests until the upgrade is complete.
• Monitor vendor advisories for the exact fixed release and apply the latest supported Avalanche patches promptly.