Windows - Security - Lansweeper Automated Vulnerability Remediation

What the Lansweeper vulnerability sync does

This Automox Worklet™ pulls vulnerability findings from a Lansweeper Cloud site and turns them into actionable patch jobs inside the Automox console. The Worklet authenticates to the Lansweeper GraphQL endpoint at https://api.lansweeper.com/api/v2/graphql, paginates through every reported CVE for the site ID you supply, resolves each Lansweeper asset key to a hostname, and uploads the resulting CSV to Automox Vulnerability Sync for endpoint matching.

The Worklet operates in two modes. Set the automatedRemediation parameter to $false to stage a Vulnerability Sync action set in your console for manual review. Set it to $true to fire patch commands at every matched endpoint as soon as the action set reaches a ready state.

Every run drops a CSV audit file at C:\ProgramData\Automox\WorkletCache\EC-134\Lansweeper_Vulnerabilities.csv with hostnames, CVE IDs, and CVSS severity scores. Set displayVulnReport to $true to also echo the full CSV into the Automox Activity Log for security teams who keep their evidence in one place.

Why patch Lansweeper-detected CVEs through Automox

Lansweeper is strong at asset discovery and vulnerability detection, but the remediation step lives in a separate tool. Teams that bridge the two by hand typically export a CSV, deduplicate by CVE, look up patch availability, and schedule policies one batch at a time. That cycle is where exposure windows stretch from hours into weeks, and where audit findings around mean time to remediate get written.

Lansweeper names CVEs, but turning that detection into a deployed patch usually requires a manual ticket bridge between the scanner console and a patching tool. This Worklet syncs Lansweeper-identified vulnerabilities through the Automox Vulnerability Sync API and maps them to the Automox patch catalog, so the CVE Lansweeper surfaces on Monday is targetable as an Automox policy on Tuesday without an admin retyping KB numbers between consoles.

How the Lansweeper to Automox vulnerability sync works

1. Evaluation phase: The Worklet authenticates to the Lansweeper Cloud GraphQL API using your lsToken and lsSiteID shared secrets. It paginates through the site's vulnerabilities query in batches of 100 using cursor-based pagination, collecting every CVE, CVSS severity score, and affected asset key. If the resulting list contains one or more CVEs, evaluation exits 2 and triggers remediation; if the site is clean, it exits 0.

2. Remediation phase: The Worklet resolves each Lansweeper asset key to a hostname, writes a CSV containing Hostname, CVE ID, and Severity columns, and uploads it to the Automox Vulnerability Sync Manual Remediations API as a generic-format action set. It polls every 60 seconds until the action set reaches a ready state, with a 600-second overall timeout. When automatedRemediation is $true, the Worklet iterates the action set's solutions list and posts a run command for each automox-patch solution; solutions classified as unmatched (no patching path in the Automox catalog) are counted and reported in the Activity Log summary for follow-up with a custom Worklet.

Lansweeper integration requirements

• Windows workstation or server endpoint to host the Worklet runner (Windows 10, Windows 11, Windows Server 2016 or later)

• Lansweeper Cloud Pro or Enterprise license; on-premises Lansweeper is not supported by the GraphQL vulnerabilities endpoint

• A Lansweeper Personal Application configured for API access, generating the lsToken value used by the Worklet

• Four Automox shared secrets named exactly axApiKey, axOrgID, lsToken, and lsSiteID (names are case-sensitive)

• Automox API key generated by a global or zone administrator with permission to call the Vulnerability Sync Manual Remediations API

• Worklet policy scoped to a single host endpoint using Endpoint Targeting filters; the Worklet itself drives all fleet actions through the API, so it must not run on every endpoint

• Outbound HTTPS connectivity from the host endpoint to api.lansweeper.com and console.automox.com

• PowerShell 5.1 or later; the Worklet uses Invoke-RestMethod and Invoke-WebRequest with -UseBasicParsing for KB5074204 compatibility

Expected Lansweeper sync and remediation behavior

After a successful evaluation, the Worklet writes the CSV to C:\ProgramData\Automox\WorkletCache\EC-134\Lansweeper_Vulnerabilities.csv and a new action set appears under Remediations in the Automox console. The Activity Log summary reports the total number of Lansweeper CVEs identified, the count classified as automox-patch (patchable) by Vulnerability Sync, and the count classified as unmatched (no patching path in the Automox catalog). Review the unmatched count and remediate those CVEs with a custom Worklet under Manual Remediations.

When automatedRemediation is set to $true, online endpoints receive patch commands as soon as the action set reaches the ready state; offline endpoints receive the same commands the next time the Automox agent checks in. Patches install without forcing a restart. Endpoints that need one move into a Reboot Required state in the console, where they wait for a scheduled reboot window or a manual reboot policy. Confirm completion against the exit codes returned by Automox: exit 0 means the site was clean and no action was needed, and exit 2 means CVEs were found and the action set was created or executed.

Re-running the Worklet on the next scheduled interval acts as the closing audit step. A clean run with exit 0 is the proof that the previously detected CVEs are no longer present in the Lansweeper site, which is the evidence security teams need for SOC 2, PCI-DSS 11.3.1 internal vulnerability scanning, and NIST 800-53 RA-5 vulnerability scanning controls. The CSV trail in WorkletCache and the Manual Remediations history in the console together cover the detection-to-remediation chain that auditors typically ask for.