Loading vulnerability…
Lansweeper lsrunase 2.0 and lsencrypt 2.0 encrypt credentials using RC4 with a hardcoded 142-byte static key array embedded in the software. The scheme also stores an 8-character prefix in cleartext alongside the ciphertext. Because the encryption key is fixed and recoverable from the application, an attacker with local access to the encrypted credential material can deterministically recover the original plaintext password using a single SHA-1 hash and RC4 decryption operation. No brute force or key guessing is required. The issue is fundamentally caused by the use of a hardcoded cryptographic key for protecting credentials, combined with a weak and obsolete cipher design.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small standalone proof-of-concept for CVE-2026-39031 affecting Lansweeper lsrunase 2.0 and lsencrypt 2.0. It contains two files: a README with vulnerability background, affected versions, cryptographic details, disclosure timeline, and usage examples; and a single Python script, lsrunase2cve.py, which implements the recovery logic. The exploit is not a remote code execution tool and does not contact any network services. Its capability is offline credential recovery: given an encrypted password string generated by the vulnerable Lansweeper tools, it extracts the first 8 characters as the cleartext prefix, appends the hardcoded 142-byte suffix embedded in the script, hashes the resulting 150-byte buffer with SHA-1 to derive the RC4 key, Base64-decodes the remaining ciphertext, and decrypts it with an in-script RC4 implementation. The script also supports the inverse operation, re-encrypting an ASCII password into the vulnerable format, optionally with a caller-supplied prefix for reproducible test vectors. Code structure is straightforward: constants define prefix constraints and the fixed key suffix; class RC4 implements key scheduling and stream encryption/decryption; validate_prefix(), generate_key(), and derive_rc4_key() reconstruct the vulnerable key derivation; decrypt_password() performs offline plaintext recovery; generate_random_prefix() and encrypt_password() reproduce the vulnerable encryption format; build_parser() and main() expose a CLI with mutually exclusive --decrypt and --encrypt modes plus optional --prefix for encryption only. There are no hardcoded victim IPs, domains, callback URLs, or C2 endpoints. The only extracted endpoints are documentation references and the vendor disclosure email in the README. Operationally, the PoC requires only possession of an encrypted password value from the affected products and works entirely locally, making it a practical credential recovery utility rather than a network exploit.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
3 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.