1. Lunex turns a fake verification check into a defense-evasion and theft chain

Classification: active malicious campaign; live delivery and malware capability are observed, but successful compromise totals are unknown.[1][2]

What happened

Ontinue analyzed a four-stage Windows chain in which a fake Cloudflare-style verification lure delivered an MSI, a loader attempted silent elevation, an attacker-supplied AMD driver impaired security monitoring, and LunexStealer collected browser and cryptocurrency-wallet data.[1][2][4]

The campaign is associated with the Psychedelic operator tag and is part of a broader malware-as-a-service platform rather than one immutable file.[1][2][3]

Timeline and evidence

Arctic Wolf and Ontinue published matching technical findings on September 24, 2026, including the same final-payload hash, command-and-control artifacts, the psychedelicloveUtils scheduled task, and the com.lunex.explorer native-messaging host.[1][2]

Arctic Wolf observed 557 lure-page views, 426 clicks, and 79 “complete” events across 32 countries, but explicitly warned that those web events do not prove command execution, installation, or compromise.[2]

Exposure and prerequisites

A target first had to encounter a compromised site or lure, follow the fake verification directions, and run the copied installer command; the MSI could install per user before later stages attempted elevation.[1][2]

The chain bundled PDFWKRNL.sys, an AMD driver affected by CVE-2023-20598, so owning no AMD GPU or updating legitimate AMD software does not by itself rule out attacker-carried-driver exposure.[1][4][5]

In-the-wild status

This is an active malicious campaign, not a proof-of-concept-only case: both research teams documented malware samples and live delivery infrastructure.[1][2]

Ontinue assessed Russian-speaking development and multiple criminal operators, while Arctic Wolf cautioned that language artifacts do not prove nationality, location, or affiliation.[1][2]

Unknowns

The checked sources did not establish how many endpoints were successfully infected, how much data was stolen, whether stolen credentials were used, or whether the driver technique impaired every security product and Windows build.[1][2]

Local and small-business relevance

A small office is more likely to meet this case through ordinary browsing and social engineering than through a targeted intrusion. Browser-stored work passwords, active sessions, crypto-wallet extensions, and remote-access capability can turn one staff click into an identity and endpoint incident. This is why “the antivirus still looked open” is not a clean bill of health when the campaign’s notable technique targets monitoring callbacks.

If your team needs help separating a suspicious prompt from a real endpoint event, The IT Guys offers small-business IT services and at-home services.

Immediate actions

• Tell users that a legitimate CAPTCHA or Cloudflare check should never require Windows Run, pasted commands, or an MSI installation.
• Use application control to restrict unapproved installers, scripts, binaries from user-writable locations, and known-vulnerable driver loading; do not rely only on the default driver blocklist.[1]
• If execution is plausible, isolate the endpoint, preserve volatile evidence, and revoke browser sessions and rotate browser-stored credentials from a known-clean system before rebuilding browser profiles.[1][2]

Detection and verification

Hunt for unexpected browser- or Explorer-originated installer activity, psychedelicloveUtils, com.lunex.explorer, suspicious native-messaging registrations, unapproved extensions, and kernel-driver service creation.[1][2]

The final payload SHA-256 06f434695f93d7fd11eeff71358ff69fed79d310a66d993bbcc4ff979c117c90 and driver SHA-256 6e8b49cf70bf854e8c59c7d27cefa89406caf8978461190dabb86dafcd8554e1 are point-in-time pivots, not stand-alone proof of compromise.[1][2]

Recovery and escalation

Escalate when the installer ran, the native-messaging host or scheduled task exists, driver telemetry is abnormal, or browser sessions show unexplained use; deleting only the visible executable is not sufficient recovery.[1][2]

Preserve first, then reimage when integrity cannot be established, revoke sessions, rotate reachable credentials, rebuild browser profiles, review wallet exposure, and confirm EDR telemetry returns after restart.[1][2]

The good and the bad

Confidence

Confidence is high that the campaign and payload chain are real, moderate on the breadth of the infrastructure, and low on victim count, loss, and national attribution.[1][2][3]

2. PeopleSoft exploitation shows the limit of literal WAF rules

Classification: confirmed exploitation of CVE-2026-35273, including a scoped path-normalization bypass against some compensating controls.[7][8][9]

What happened

CVE-2026-35273 is an unauthenticated network-reachable flaw in Oracle PeopleSoft Enterprise PeopleTools Updates Environment Management that can lead to remote code execution.[9][10]

In the renewed campaign, UNC6240 changed one character in the requested PSEMHUB path to a percent-encoded form; some WAF or reverse-proxy rules compared the literal path before decoding, while PeopleSoft/WebLogic later decoded and routed it.[7]

Timeline and evidence

Mandiant observed the original zero-day activity from May 27 through June 9, 2026, Oracle released its security alert on June 10, and CISA added the CVE to KEV on June 12.[8][9][11]

Google’s September 25 report described renewed mass exploitation, including web shells on dozens of systems globally and both file-writing and fileless execution.[7]

Exposure and prerequisites

The supported affected releases listed by Oracle are PeopleTools 8.61 and 8.62, with earlier unsupported releases untested but considered likely affected; exposure also depends on the EMHub/PSEMHUB component being present, reachable over HTTP or HTTPS, and unpatched.[7][9][10]

A WAF-only path block does not change the vulnerable application state and was bypassed in observed attacks when operators had not applied the Oracle fix.[7][9]

In-the-wild status

Exploitation is confirmed by Mandiant incident evidence and CISA KEV inclusion, and Mandiant attributes the activity to UNC6240, also called ShinyHunters.[7][8][11]

The current KEV snapshot marks known ransomware-campaign use as Known, but that catalog field does not by itself establish file-encrypting ransomware in this campaign.[20]

Unknowns

The public evidence does not give an exact campaign start for the renewed wave, an exact victim count, or independent validation of every victim, actor claim, and post-exploitation outcome.[7][11][20]

Local and small-business relevance

PeopleSoft is more likely to sit in a university, healthcare organization, public agency, large employer, or service provider than in a five-person shop. Smaller organizations can still be downstream stakeholders: payroll processors, benefit administrators, school partners, and contractors may hold or exchange sensitive records with an affected institution. Ask the system owner for patch and investigation status rather than assuming an upstream WAF settled the matter.

Immediate actions

1. First, preserve relevant access, application, authentication, endpoint, and network logs; suspicious files; process and volatile state; active configuration; account and credential scope; and the node inventory from every load-balanced PeopleTools member before patching, disabling components, deleting files, or rotating credentials.[7]
2. Second, contain through a known-clean administrative path: restrict administrative and system-to-system endpoints from the public internet, normalize paths before any temporary edge match, and remove or disable EMHub/PSEMHUB only where Oracle-supported architecture allows and after the evidence capture.[7][8][9]
3. Third, apply Oracle’s CVE-2026-35273 security fix on every PeopleTools node, remain on a supported release, verify the running build, hunt every node, and then rotate affected credentials from a clean system when the preserved evidence indicates exposure.[7][9]

Detection and verification

Review access logs for PSEMHUB requests and encoded or mixed-case variants, inspect PSEMHUB.war and PORTAL.war for unshipped content, and look for shell processes spawned by the WebLogic Java process or unexpected MeshCentral agents.[7][8]

Absence of a JSP web shell is not proof of safety because Google observed fileless command execution as well as written shells.[7]

Recovery and escalation

A confirmed shell or fileless execution event should trigger incident response: preserve evidence, identify service-account privileges, rotate database, Integration Broker, cloud, and other reachable credentials from a clean system, and review audit and egress records for bulk access or archives.[7]

The good and the bad

Confidence

Confidence is high on affected supported versions, exploitation, the WAF-normalization failure mode, and the need for a preserve-first response followed by containment and patching; actor attribution is Mandiant’s assessment rather than an independently proven identity.[7][8][9]

3. Elementor’s short-lived release window creates a high-impact click risk

Classification: high-impact CSRF in Elementor core 4.3.0 and 4.3.1; no confirmed exploitation in the wild by the cutoff.[14][15][17]

What happened

CVE-2026-62062 is a CSRF and REST-authentication-bypass issue in the free Elementor Website Builder plugin that can make a logged-in WordPress user perform a REST action their account is allowed to perform.[14][15][17]

On a stock site, an administrator who opens a crafted link can be induced to create a second administrator account; a lower-privileged user does not automatically yield full takeover.[14]

Timeline and evidence

Elementor 4.3.0 was released September 22, 2026, 4.3.1 followed on September 23, and the first fixed release, 4.3.2, arrived September 24.[14][16][17]

Patchstack and the CVE record published the advisory on September 25, while the WordPress.org API showed 4.3.2 as current at retrieval.[14][15][17]

Exposure and prerequisites

Only Elementor core versions 4.3.0 and 4.3.1 contain this vulnerable code; releases before 4.3.0 do not contain the affected proxy, and 4.3.2 is fixed.[14][15][16]

The Editor Events module must be loaded, and Patchstack says it is enabled by default when a site’s first Elementor installation was 3.32.0 or later.[14]

The attacker needs no account, but a currently authenticated WordPress user must open the crafted link, and the result stays bounded by that user’s REST permissions.[14][15][17]

In-the-wild status

No verified in-the-wild exploitation was found by the reporting cutoff: CISA’s dated enrichment said exploitation was none, and CVE-2026-62062 was absent from KEV catalog version 2026.09.25.[17][20]

Patchstack expected exploitation and considered the flaw suitable for mass campaigns, but that forecast is not evidence that attacks occurred.[15]

Unknowns

Public version statistics grouped the 4.3 branch and did not separate vulnerable 4.3.0 and 4.3.1 sites from already-fixed 4.3.2 sites, so a precise live vulnerable-site count was unavailable.[18][19]

Local and small-business relevance

This is the most immediately familiar case for a local small business: a website administrator may read support mail, chat, comments, and vendor messages while still logged into WordPress. A new rogue administrator could then alter pages, plugins, payment instructions, forms, or integrations.[14] Those are plausible consequences of administrator control, not evidence that they occurred in this case.

If an unexpected prompt or login alert arrives during the audit, use our unexpected MFA prompt response guide and secure the identity from a clean device.

Immediate actions

1. First, inventory production, staging, multisite, and forgotten clones for the active Elementor core version, prioritizing exactly 4.3.0 and 4.3.1; before updating, preserve the current administrator roster, user and REST logs, plugin and theme state, scheduled tasks, configuration, and recent-change evidence.[14][15]
2. Second, activate the newest supported Elementor release, at minimum 4.3.2, and use a trusted virtual patch only as a short bridge if immediate updating is impossible.[14][15][16]
3. Third, audit privileged users and recent changes against the preserved baseline because updating closes the request path but does not remove an administrator account that may already exist; preserve any newly found evidence before disabling an account or cleaning the site.[14]

Detection and verification

Review user creation and role changes, unfamiliar administrators, suspicious REST requests, unexpected plugin or theme installs, scheduled tasks, injected code, and unexplained outbound changes during the exposure window.[14]

Verify that 4.3.2 or newer is active on every instance and that the expected administrator roster remains intact; an update merely downloaded but not activated is not enough.[14][15][16]

Recovery and escalation

If an unauthorized account or change is found, preserve evidence, disable the account, invalidate sessions, rotate WordPress, hosting, database, API, and application credentials from a clean device, refresh salts where appropriate, and restore or rebuild from known-good material when integrity is uncertain.[14]

The good and the bad

Confidence

Confidence is high on the affected and fixed releases, prerequisites, and mechanism; confidence is moderate on population estimates, and no public exploitation was confirmed by the cutoff.[14][17][20]

4A. SharePoint is an exploited authenticated RCE, not a pre-authentication bug

Classification: confirmed exploitation of CVE-2026-65660 against on-premises SharePoint Server; authentication is required.[23][24][25]

What happened

CVE-2026-65660 is a network-reachable code-injection flaw that can produce remote code execution after an attacker already has low-level authenticated access to an affected on-premises SharePoint server.[23][24][26]

Microsoft rates it Important with CVSS 3.1 score 8.8, and the vector requires low privileges but no user interaction.[23][24][26]

Timeline and evidence

Microsoft first published the issue on August 11, 2026, changed the title and impact from spoofing to remote code execution on August 27, and added reliable evidence of observed attacks on September 25.[23][24]

CISA added CVE-2026-65660 to KEV on September 25 with a September 28 due date, ransomware use marked Unknown, and forensic triage marked Yes.[20]

Exposure and prerequisites

Affected SharePoint Enterprise Server 2016 builds are below 16.0.5565.1001, SharePoint Server 2019 builds are below 16.0.10417.20198, and Subscription Edition builds are below 16.0.19725.20522.[25][26]

The fixed builds are 16.0.5565.1001 for 2016, 16.0.10417.20198 for 2019, and 16.0.19725.20522 for Subscription Edition, with Microsoft instructing customers to install all updates offered for installed software when more than one package applies.[23][25]

SharePoint Online is not listed in the affected on-premises product ranges checked for this CVE.[25][26]

In-the-wild status

Active exploitation is confirmed by Microsoft’s dated revision and CISA KEV inclusion, even though one top-level machine-readable Microsoft field still said exploited: No at the cutoff.[23][24][20]

Unknowns

The checked primary material did not identify the actor, attack start, victim count, success rate, initial-access route, or post-compromise actions.[23][24][20]

Local and small-business relevance

Most very small businesses do not operate an on-premises SharePoint farm, but MSPs, local government suppliers, healthcare partners, manufacturers, and firms acquired by larger groups may inherit one. The authentication requirement lowers the set of possible attackers but raises a second question: how did a low-privilege account become available, and what else did it access?[23][24][26]

Immediate actions

1. First, inventory every on-premises farm member and compare its active build with the fixed thresholds; when exploitation is plausible, preserve SharePoint, IIS, authentication, endpoint, and security logs, account state, running processes, and relevant configuration from every member before installing packages or performing cleanup.[20][23][25][26]
2. Second, contain affected access through a known-clean path, install every applicable Microsoft security package, then confirm that each running farm member reports the fixed build rather than trusting a successful installer exit on one node.[23][25]
3. Third, conduct forensic triage against the preserved baseline and protect affected identities from a clean system before returning the farm to normal service.[20][23]

Detection and verification

Review low-privilege account activity, unexpected code or child processes on SharePoint servers, unusual web requests, new persistence, and lateral access from the farm, but do not claim a CVE-specific indicator set because Microsoft and CISA published none in the checked records.[20][23]

Recovery and escalation

If code execution or unauthorized account use is established, isolate affected nodes, preserve evidence, rotate affected identities from clean systems, rebuild when integrity is uncertain, and verify every farm member before returning service.[20][23][25]

The good and the bad

Confidence

Confidence is high on the vulnerability class, authentication prerequisite, exact fixed builds, and exploitation status; confidence is low on campaign scope and actor identity because those details were not disclosed.[20][23][24]

4B. MikroTrick is one exploited RouterOS chain with two CVEs

Classification: confirmed exploitation of the CVE-2026-67279 plus CVE-2026-86060 chain against internet-reachable SSH.[27][28][29]

What happened

CVE-2026-67279 lets an unauthenticated SSH client cross a pre-authentication state boundary into channel handling, and CVE-2026-86060 can then manipulate the trusted RouterOS login policy mask.[29][31][32]

Together, the two flaws produced unauthenticated full administrative-console access without a password or SSH key.[28][29][31]

Timeline and evidence

CERT Polska found successful activity in logs from at least September 2, 2026, MikroTik released fixed builds on September 3, CISA added CVE-2026-86060 to KEV on September 10, and added CVE-2026-67279 on September 25.[27][28][29]

CVE-2026-67279 has CVSS 4.0 score 6.9 Medium and CVE-2026-86060 has CVSS 4.0 score 9.2 Critical, but the operational story is the combined chain rather than either score alone.[31][32]

Exposure and prerequisites

Both flaws affect RouterOS 7.24 below 7.24.2, 7.0.0 below 7.23.4, and 6.0.0 below 6.49.21.[30][31][32]

The fixed minimums are 7.24.2 Stable, 7.23.4 Long-term, 6.49.21 Long-term, and 7.25 beta 3 for that beta channel.[27][30][31]

A vulnerable build and attacker reachability to SSH are central to the observed takeover path; MikroTik says its default configuration blocks internet SSH, but manually exposed management services create risk.[27][28]

In-the-wild status

CERT Polska confirmed successful attacks using the two-CVE chain before patches were available, and both CVEs were in CISA KEV by the reporting cutoff.[28][29][20]

CVE-2026-67276 is a separate RSA-key authentication flaw and is not part of MikroTrick.[29]

Unknowns

The public evidence did not establish a complete victim count, operator identity, ransomware use, or a universal post-compromise payload.[28][29][20]

Local and small-business relevance

Routers often outlive staff, vendors, and documentation. A small office may have inherited an old public SSH rule used by a former installer, and a device with administrative control sits at a powerful trust boundary even when every laptop is patched. Confirm from outside the local network whether management is reachable; do not rely on memory.

Immediate actions

1. First, preserve RouterOS logs, the running configuration, administrator roster, scripts, scheduler entries, routes, tunnels, and the Flagged state before changing management exposure or upgrading; keep response access through a known-clean path.[27][28]
2. Second, restrict SSH and other management services to trusted addresses or a VPN, then upgrade to a supported patched release in the deployed channel, at minimum 7.24.2 Stable, 7.23.4 Long-term, 6.49.21 Long-term, or 7.25 beta 3 for beta.[27][28][30]
3. Third, inspect the running configuration and administrator roster against the preserved baseline before deciding whether an in-place upgrade is enough.[27][28]

Detection and verification

CERT Polska reported a distinctive failed login for the invalid account value -2, creation of a fully privileged ops account, and activity from 82.192.72.4, with 103.102.31.18 associated with attempts.[28]

Check logs and the RouterOS Flagged marker, then review unknown users, scripts, scheduler tasks, proxies, tunnels, and other configuration changes; absence of Flagged status does not prove the router is clean.[27][28]

Recovery and escalation

When takeover is suspected, isolate the router, preserve logs and configuration, factory-reset and rebuild from a trusted verified configuration, rotate passwords and keys, and avoid blindly restoring a full backup from the suspect device.[28]

The good and the bad

Confidence

Confidence is high on the two-CVE chain, branch-specific fixed versions, and successful in-the-wild use; confidence is low on total scope and attribution.[27][28][29]

5. Kiteworks made a disruptive precautionary call without confirming a breach

Classification: preventive warning based on federal threat intelligence; compromise, a zero-day, actor identity, and initial-access route remained unconfirmed.[34][35][36]

What happened

Kiteworks said unnamed federal intelligence authorities supplied credible intelligence that a threat actor may attempt to target some customer systems, and the company recommended a precautionary shutdown.[34][35][37]

Kiteworks also said it had no indication that either its own systems or customer systems had been compromised, describing the measure as preventive rather than a response to a confirmed breach.[34][35][37]

Timeline and evidence

Heise’s report on a customer email described a six-hour shutdown from 04:00 to 10:00 CEST on September 26, while Kiteworks’ later public advisory recommended nine hours during the weekend in each customer’s local time zone and left exact hours to direct notices.[34][36]

Kiteworks published its public advisory on September 25 at 21:55:56 UTC and its metadata showed modification on September 26 at 01:21:01 UTC, but the reviewed archive did not prove which wording changed.[34]

Exposure and prerequisites

Self-managed on-premises or customer-managed AWS and Azure systems were the customer’s responsibility to shut down, while Kiteworks said it would shut down Kiteworks-hosted systems without customer action.[34]

Kiteworks said release 9.5.1 addressed all known vulnerabilities, but that does not establish protection against the feared route because contemporaneous reporting described concern about potentially unknown vulnerabilities.[34][35][36]

In-the-wild status

No reviewed source established successful intrusion, exploited zero-day, data theft, persistence, a named CVE, or a confirmed initial-access path by the cutoff.[34][35][36]

At least one healthcare customer told TechCrunch it shut down immediately and experienced operational delays, but that is a single-source account of preventive downtime rather than evidence of malicious impact.[35]

Unknowns

The public record did not identify the federal agency, actor, target subset, intelligence basis, CVE, technical indicator, reason for the six-to-nine-hour difference, or a post-window all-clear.[34][35][36]

Local and small-business relevance

Kiteworks is used for sensitive file exchange, so even a precautionary shutdown can interrupt healthcare, legal, financial, government, or vendor workflows. A small business should not improvise a time window from a news headline. Find the direct customer notice, confirm whether the tenant is hosted or self-managed, and coordinate business continuity with the system owner.

For broader context on the day’s technology stories, see The IT Guys’ September 26 technology news recap.

Immediate actions

1. First, locate the organization’s direct Kiteworks notice and follow its specific schedule rather than converting the public nine-hour wording into a universal UTC window.[34][36]
2. Second, identify hosted versus self-managed responsibility, preserve appliance, authentication, network, and administrative logs, and document clean shutdown and startup checkpoints.[34]
3. Third, confirm the running release and vendor support status, while recognizing that 9.5.1 was described as covering known vulnerabilities rather than a confirmed unknown route.[34][35]

Detection and verification

Compare pre- and post-window administrator lists, authentication events, configuration changes, unusual file transfers, new integrations, and unexplained outbound connections. Retain enough evidence to distinguish malicious access from the expected shutdown and restart noise. Ask Kiteworks support for current indicators and an all-clear; do not invent signatures that the public advisory did not provide.

Recovery and escalation

Escalate if logs show unauthorized access, unexplained configuration or administrator changes, suspicious transfer activity, or vendor guidance that changes the event from precaution to incident; preserve evidence before resets and rotate exposed identities from clean systems when compromise is established.[34][35][37]

The good and the bad

Confidence

Confidence is high that Kiteworks issued a preventive shutdown request and that the six-to-nine-hour discrepancy is real; confidence is low on the underlying threat mechanism, actor, and whether any exploitation occurred.[34][35][36]