How to Fix CVE-2019-11510 in Pulse Connect Secure (SA44101)

CVE-2019-11510 is a critical pre-authentication arbitrary file read in Pulse Connect Secure (now Ivanti Connect Secure) VPN gateways, which Nessus reports as Pulse Connect Secure Multiple Vulnerabilities (SA44101). Fix it by moving to a fixed, supported release, then reset every VPN and administrator password, end all active sessions and review the appliance logs for exploitation.

The upgrade is the easy half. An appliance that still reports a 2019 version has probably been exposed for years, so the password reset and the log review matter as much as the new firmware.

What the scanner is actually detecting

The finding comes from Nessus plugin 124766, Pulse Connect Secure Multiple Vulnerabilities (SA44101). It is a remote, version-based check: Tenable’s Connect Secure detection reads the version the web interface reports, and the plugin compares it with the fixed releases in Pulse Secure advisory SA44101. It does not send an exploit.

The plugin covers all 15 CVEs in that advisory. CVE-2019-11510 is the headline issue, but the list also includes CVE-2019-11539 (command injection in the admin web interface, after authentication) and several 2018 Ghostscript CVEs. The fixed releases it checks for are:

Tenable also publishes a separate remote check, Pulse Secure Pulse Connect Secure SSL VPN Unauthenticated Path Traversal (CVE-2019-11510), which tests the flaw directly. Both can appear on the same gateway.

Real-world risk

This one deserves its score. NVD rates CVE-2019-11510 at CVSS 3.1 10.0 (CWE-22, path traversal): an unauthenticated attacker sends a crafted URI over HTTPS and reads arbitrary files from the appliance. CERT/CC’s note VU#927237 says an attacker may gain access to all active users and their plaintext credentials, and that there is no viable workaround other than the vendor patch.

The DEVCORE researchers who found the bug showed at Black Hat USA 2019 how it chains: read cached plaintext passwords and the session database, reuse sessions to get past two-factor authentication, then use CVE-2019-11539 as an administrator to run commands. CISA added CVE-2019-11510 to the CISA Known Exploited Vulnerabilities catalog on 3 November 2021, and its alert AA20-107A described organizations breached after patching because Active Directory credentials, including Domain Admin, had been harvested before the patch went on.

There is also a lifecycle problem. Ivanti states that Pulse Connect Secure 9.1x reached end of support on 31 December 2024, and every branch in the table above is older than that. A gateway that triggers this plugin is running unsupported code, whatever else is true.

How to confirm it on the host

Connect Secure is an appliance, so you confirm the version through the admin console or its REST API, not a shell.

1. In the admin console, open Maintenance > System > Platform. The page shows the current version and, if the appliance was upgraded before, the rollback version.
2. On releases that include the REST API (Ivanti documents it for 9.1 and 22.x), enable Allow access to REST APIs for the administrator under Authentication > Auth. Servers > Administrators, then query it from the internal management network:

# Get an API key (curl prompts for the admin password)
curl -sk -u admin-user -G https://vpn-mgmt.example.com/api/v1/auth

# Use the key as the user name with an empty password
curl -sk -u 'API_KEY:' -H 'accept: application/json' 
  https://vpn-mgmt.example.com/api/v1/system/system-information

The version is under software-inventory > software > version. Compare it with the table above and with the version in the Nessus plugin output.

Next, look for signs of past exploitation. CISA’s archived check-your-pulse tool searches exported logs for 2020-era indicators (strings, IP addresses and user agents). Download the Events and User Access logs from the web console, put the .events and .access files in one folder, and run it with Python 3.6 or later:

git clone https://github.com/cisagov/check-your-pulse.git
cd check-your-pulse
python3 ./app.py --path /path/to/exported-logs -c pulse-iocs.csv

Keep its limits in mind. It alerts on any indicator, so hits after your patch date may be false positives. If unauthenticated request logging was off, it can only match IP addresses and user agents, which CISA calls much less reliable. The local log viewer also holds only the most recent 5,000 messages, so older evidence exists only if you archived logs or sent them to syslog.

How to fix it

Step 1: Back up the configuration

Export the system configuration at Maintenance > Import/Export > Import/Export Configuration, set a password for the file and click Save Config As. Do the same for local users under Maintenance > Import/Export > Import/Export Users.

Step 2: Upgrade, or migrate to a supported platform

The releases in the table clear the plugin, but they are long out of support. Treat them as a stopgap at most and aim for a current Ivanti Connect Secure 22.x build.

• Current 22.x: the current 22.x release notes list upgrade installation only for ISA6000, ISA8000 and VMware, and give a tested upgrade path for each build. Older hardware appliances need a migration to a new appliance or virtual machine. For 9.1x systems, Ivanti tells customers to contact it for a migration path.
• Installing a package: go to Maintenance > System > Upgrade/Downgrade, choose From File (or From Staged Package), and click Install. Ivanti’s guide says not to select the delete option when upgrading. The appliance reboots, which takes several minutes.
• Start the upgrade from the internal interface. The 22.x release notes say not to upgrade through the external interface, and admin access on it has been removed.
• For clusters, follow Ivanti’s cluster upgrade procedure rather than upgrading nodes ad hoc.

Step 3: Assume credentials were exposed

1. End every session at System > Status > Active Users with Delete All Sessions. Administrator sessions are not included: select each one and click Delete Session.
2. Reset the passwords of all local administrator and user accounts on the appliance (Authentication > Auth. Servers).
3. Reset the directory passwords of every account that signed in through the VPN, and rotate secrets stored on the appliance, such as the service account it uses to query LDAP or Active Directory.
4. If logs show exploitation before your patch date, CISA’s guidance is to watch closely for unauthorized connections and consider a full domain password reset.

Step 4: Log what you will need next time

Under System > Log/Monitoring > User Access > Settings, enable Unauthenticated Web Requests, which is off by default, and forward logs to a syslog server so they outlive the local buffer. Keep internet-facing VPN gateways on your external attack surface management scope so a forgotten secondary appliance does not stay on an old build.

How to verify the fix and rescan

1. Check Maintenance > System > Platform or the REST system-information call and confirm the new version on every node.
2. Run a Nessus scan against the gateway’s external address. Plugin 124766 should not fire, and neither should the direct path traversal check if it was present.
3. Expect other Connect Secure findings to remain if the build is not current. Clearing SA44101 says nothing about later advisories.
4. Confirm the Active Users list shows only sessions started after the password reset.

What can break and how to roll back

Rolling back to a vulnerable release is not a fix. If an upgrade fails, roll forward to another supported build.

Common false positive reasons

• Stale results. The scan predates the upgrade.
• Mixed cluster. One node or a load-balanced address still answers with the old version. That is a true positive for that node.
• Wrong CVE attribution on 8.1. NVD does not list 8.1 as affected by CVE-2019-11510, but 8.1 before 8.1R15.1 is affected by other SA44101 CVEs, so the plugin is right even if the headline CVE is not.
• Client versus gateway. Pulse Secure Desktop Client findings on workstations are separate plugins with a separate fix.

FAQ

Is there a workaround for CVE-2019-11510?

No. CERT/CC states there is no viable workaround other than applying the vendor’s update.

We patched years ago. Do we still need to reset passwords?

If the appliance was exposed before the patch, yes. Credentials stolen before patching keep working until they change, as CISA’s AA20-107A alert described.

Does MFA protect us?

Not fully. The DEVCORE research bypassed two-factor authentication by downloading the session database and forging session cookies.

Is Pulse Connect Secure the same product as Ivanti Connect Secure?

Yes. Ivanti renamed it, and Tenable’s detection plugin describes Ivanti Connect Secure as formerly known as Pulse Connect Secure.

Tracking this finding across many hosts

With several gateways, the question is which appliances are really on a fixed build. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export, pulls public data such as the CISA KEV catalog, and can re-test an individual Nessus finding such as 124766 after an upgrade. Duplicates are merged per scanner, so the same gateway reported by two scanners still appears as two findings.

Sources

• Tenable: Pulse Connect Secure Multiple Vulnerabilities (SA44101), Nessus 124766
• NVD: CVE-2019-11510
• CERT/CC VU#927237: Pulse Secure VPN vulnerabilities
• CISA: check-your-pulse log analysis tool
• Ivanti Connect Secure 22.x release notes (upgrade path)