CVE-2022-44574

What it actually does

CVE-2022-44574 is an improper authentication flaw in Ivanti Avalanche 6.3.x and earlier. A network-accessible attacker can interact with a specific Avalanche service port without valid credentials and modify application properties that should require authentication. The primary impact is loss of integrity: configuration or operational properties can be changed remotely, potentially altering device-management behavior, service settings, or administrative state depending on the exposed component and deployment configuration. The CVSS vector indicates remote, low-complexity exploitation with no privileges or user interaction required, but no direct confidentiality or availability impact is specified.

Why it matters to the business

Successful exploitation could let an unauthenticated external or internal attacker tamper with Avalanche configuration, potentially disrupting mobile-device or warehouse-device management workflows, weakening administrative controls, or causing incorrect device behavior. Because Avalanche is often used to manage operational endpoints, unauthorized configuration changes can translate into business disruption, compliance concerns, and incident-response effort. The EPSS score is elevated, indicating meaningful likelihood of exploitation activity even though the issue is not currently listed in CISA KEV and no ransomware association is reported.

How an attack unfolds

An attacker first identifies an exposed Ivanti Avalanche instance running version 6.3.x or earlier and determines whether the vulnerable service port is reachable. Because the flaw is an authentication bypass, the attacker does not need valid Avalanche credentials. The attacker then sends crafted requests to the vulnerable service interface to change properties that should normally be protected by authentication. If accepted, those changes can alter Avalanche behavior or configuration. The attacker may then use the modified state to interfere with managed-device operations, weaken controls, establish persistence through configuration changes, or prepare follow-on activity against devices or administrators that depend on Avalanche.

How to fix it

Upgrade Ivanti Avalanche to a vendor-supported release newer than 6.3.x that contains the authentication fix. If an exact fixed version is not available in internal patch catalogs, consult Ivanti’s security advisory and current Avalanche release notes before deployment. Until upgraded, restrict network access to Avalanche management and service ports using firewalls, VPNs, allowlists, and segmentation; ensure the service is not directly exposed to the internet; limit access to trusted administrative networks only; and review configuration for unauthorized property changes. After patching, rotate administrative credentials if there is evidence of suspicious configuration activity and restore known-good configuration baselines where appropriate.

How to confirm the fix worked

Confirm the deployed Avalanche version is newer than 6.3.x and matches a vendor-supported fixed release. Validate that Avalanche management and service ports are reachable only from approved administrative networks. Review application configuration and property values against a known-good baseline to confirm no unauthorized changes remain. Where safe and authorized, perform a controlled vulnerability scan or vendor-recommended validation test to confirm unauthenticated property modification is no longer possible. Check firewall, reverse proxy, and exposure-management inventories to verify the affected service is not publicly reachable.

Typical attack path

1. Scan for internet-facing or internally reachable Ivanti Avalanche services.
2. Identify instances running Avalanche 6.3.x or earlier, or infer vulnerability from service behavior.
3. Connect to the vulnerable Avalanche service port without authenticating.
4. Submit crafted property-modification requests that should require authentication.
5. Verify that unauthorized property changes were accepted.
6. Use the altered configuration to disrupt operations, weaken management controls, or support additional intrusion activity.

How to detect it

To determine whether exploitation already occurred, review Ivanti Avalanche application logs, web/service access logs, reverse proxy logs, firewall logs, EDR telemetry, Windows Event Logs or Linux system logs depending on deployment, and configuration-change audit records. Focus on unauthenticated or anonymous requests to Avalanche service ports, property-modification activity from unknown IP addresses, configuration changes outside maintenance windows, repeated probing of Avalanche ports, and changes followed by service restarts or unexpected device-management behavior. Compare current configuration and property values with historical backups or golden baselines. Correlate suspicious requests with network flow records showing access from internet addresses, user workstations, or other systems that should not administer Avalanche. Because no public actor-specific indicators are provided for this CVE, detection should emphasize behavioral evidence of unauthorized property modification rather than fixed malware or infrastructure indicators.

What your security team should do

• Prioritize upgrade or replacement of all Ivanti Avalanche 6.3.x and earlier deployments, especially any reachable from untrusted networks.
• Immediately restrict inbound access to Avalanche service and management ports to trusted administrative networks only.
• Inventory all Avalanche instances, including lab, warehouse, remote-site, and legacy deployments that may not be centrally patched.
• Review Avalanche configuration/property change history for unauthenticated, unknown, or unusual source addresses.
• Compare current Avalanche configuration against a known-good backup or baseline and revert unauthorized changes.
• Increase monitoring on Avalanche servers for unexpected configuration changes, service restarts, and management activity from non-administrative networks.
• If suspicious activity is found, preserve application logs, network flow data, and system logs before remediation for forensic review.