Wednesday, 12 August 2026

The SharePoint chain covered here on 2026-07-15 and flagged in the W29 outlook as half-patched until August is now complete on both halves. Microsoft's August Patch Tuesday published CVE-2026-63520, a remote code execution flaw Rapid7 states is the second of a pair that chain into a critical unauthenticated remote code execution against a vulnerable SharePoint server, and Rapid7 released a detailed technical analysis and a proof-of-concept for the first link, CVE-2026-55040, the CVSS 9.1 weak-authentication bypass Microsoft patched on 14 July. Patches exist for SharePoint Server Subscription Edition, 2019 and 2016; Microsoft records neither flaw as exploited, and rates both "Exploitation More Likely".

The entry on July's SharePoint pre-auth JWT bypass covered CVE-2026-55040 as one half of a Pwn2Own chain whose second half was still unpatched, and the W29 outlook carried it as an item in motion, a SharePoint chain half-patched until August. Both halves are now disclosed and one of them has public exploit code. Microsoft's August Patch Tuesday published CVE-2026-63520, a remote code execution vulnerability in SharePoint Server, and Rapid7 (whose Senior Principal Security Researcher Stephen Fewer discovered it) states that "this vulnerability is the second in a pair of exploits which, when chained together, comprise a critical unauthenticated remote code execution vulnerability in a vulnerable SharePoint server" (Rapid7, 2026-08-11). The same post records the second half of the release: "Alongside today's coordinated disclosure of CVE-2026-63520, Rapid7 has now published a detailed technical analysis and proof-of-concept for CVE-2026-55040, the first vulnerability in the chain."

The two records read very differently on their own, which is the point of reading them together. Microsoft classes CVE-2026-63520 as improper input validation (CWE-20), CVSS 8.1 with high attack complexity, severity Important, allowing an unauthorised attacker to execute code over a network (MSRC, 2026-08-11). CVE-2026-55040 is the more severe of the pair on its own terms: "Weak authentication in Microsoft Office SharePoint allows an unauthorized attacker to bypass a security feature over a network", CWE-1390, CVSS 9.1 with low attack complexity and no privileges or user interaction required, severity Critical (MSRC, 2026-08-11). Microsoft records both as not exploited and not publicly disclosed before their patches, and rates both "Exploitation More Likely". Patches exist for SharePoint Server Subscription Edition, 2019 and 2016 (Rapid7, 2026-08-11).

What moves this ahead of the ordinary patch cycle is not a score but the disclosure state. The authentication-bypass half now has published analysis and working proof-of-concept code, and the code-execution half it chains into was documented the same day, so the research cost of reconstructing an unauthenticated RCE against an unpatched on-premises farm has collapsed to reading two public write-ups. Nothing in either advisory reports exploitation yet; the exposure is the window between publication and patch coverage, on a product class whose internet-facing deployments are collaboration portals rather than obscure infrastructure.

That window matters more than usual for this constituency. Two Swiss public-sector SharePoint compromises were disclosed in the last nine days, the Confederation's own IT provider on 4 August and the canton of Graubünden on 5 August, both on-premises estates and both attributed by the affected bodies to the SharePoint flaws disclosed in mid-July. Neither of those intrusions involves the CVEs here, and nothing in the cited sources connects them; the relevance is the estate, not the incident. An organisation that has just rebuilt or re-imaged SharePoint servers in response to the July wave is exactly the organisation whose new builds may predate both the July and August updates, and whose asset inventory for those hosts is least likely to be current.

Detection concepts are constrained by what has been published: neither Microsoft record describes the vulnerable code path, and this entry does not have Rapid7's technical analysis in hand, so behavioural detail beyond the advisories would be invention. What the advisories do support is exposure work rather than detection work, enumerate on-premises SharePoint farms and their patch levels across Subscription Edition, 2019 and 2016, and treat internet-reachable ones as the priority, since both halves of the chain are network-reachable with no authentication and no user interaction. Where a farm's August update cannot be applied immediately, restricting the server's reachability to authenticated internal networks is the control that does not depend on knowing which request shape to look for.

Kaspersky GReAT published a further instalment on Project CAV3RN, the modular espionage framework it tracks against targets in Israel, on 2026-08-11. The new component is a .NET NativeAOT communication module that performs a DNS A-record lookup before every poll or result submission and reads the fourth octet of the answer to choose between direct HTTPS and a Google Apps Script relay, with the same DNS infrastructure able to hand back a replacement Apps Script deployment ID so the operator can rotate the Google channel without redeploying. A second new component, a broker DLL masquerading as the RNP OpenPGP library, rescans its directory every second and hot-loads higher-versioned components.

Kaspersky's GReAT team published a further instalment on Project CAV3RN on 2026-08-11, describing it as "a modular espionage framework used against targets in Israel" and expanding on two earlier publications (Kaspersky Securelist, 2026-08-11). The prior entry here covered the framework's DNS-based C2 fallback and Kaspersky's low-confidence association with OilRig. The delta is a channel-selection design that is worth carrying into detection engineering regardless of who operates it.

Kaspersky states: "The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel" (Kaspersky Securelist, 2026-08-11). The mechanics are specific enough to hunt on. The communication module is a 64-bit DLL compiled with .NET 8 NativeAOT. Before polling for commands or sending a result, it issues an A-record query for a name built from a short random nonce concatenated with a numeric error state, then a hex-encoded client identifier, under a fixed operator-controlled domain. One exact address is treated as a rejection; otherwise the module reads the fourth octet of the answer and maps it, in combination with the current error state, onto direct HTTPS, the Apps Script relay, an exception, or closing the transaction with no channel at all. A recovered Apps Script deployment ID is written back to the module's on-disk configuration, while other configuration changes pushed by the operator stay in memory. The two channels differ in shape as well as destination. On the direct-HTTPS path the module contacts a configured attacker-controlled address whose endpoint is gated on a custom client-identifier HTTP header, returning a failure response to requests without it and an encoded tasking body to requests carrying it. On the Apps Script path the module instead POSTs a JSON envelope to the deployment URL, with the upstream method and the headers to replay (the same client-identifier value among them) carried as fields inside that JSON body rather than as headers on the request to Google. Tasking comes back base64-encoded and XORed either way.

The second new component is an inter-component broker, a 64-bit Visual C++ DLL that masquerades as the RNP OpenPGP library through a set of rnp_* exports, with one of those exports starting the broker. At startup it creates its control structure, initialises a message dispatcher and scans the host directory for DLLs, grouping candidates by their CompanyName resource and loading the highest-versioned member of each group that exposes four specific named exports. It rescans that directory every second, so a component can be added or upgraded without restarting the host, but only by dropping a higher-versioned DLL under a new path, because replacing a file in place is not detected (Kaspersky Securelist, 2026-08-11).

Triage: high-volume DNS lookups under a single parent domain are also how legitimate telemetry agents, CDN clients and some licence checks behave, so the query volume alone is not the signal. The discriminators the described mechanism supports are the label structure (a short changing nonce plus a stable hex-encoded identifier per host, rather than a service-shaped name) and the tight temporal coupling, with one lookup preceding each outbound connection rather than a periodic refresh independent of traffic. Note what is not available as a discriminator on the relay path: the custom client-identifier travels inside the JSON body of a TLS POST to a legitimate Google endpoint, so it is not visible to header inspection or to anything short of TLS interception at the proxy.

Wesco International confirmed to BleepingComputer on 2026-08-11 that it is investigating a claim of CRM data exfiltration by a third party after ExfilSquad (the extortion brand behind the confirmed July breaches of the UK Department for Education's portals and the Police National Legal Database) claimed 2.6 million records from its cloud CRM and, once its ransom deadline expired, published the data it says it took. Wesco found no evidence of ransomware or other malicious software and does not believe sensitive data is at risk, offering no figure of its own. Researchers have tied the group's past activity to improperly configured Microsoft Power Pages data tables; Wesco has not said how it was breached, and the only public link to Dynamics 365 is that Wesco may be using it.

The ExfilSquad campaign (whose leak-site list a threat-intelligence vendor assessed was more likely fabricated than real, but which contained a genuine UK government breach) has produced its first victim to answer on the record in partial terms. Wesco International, a US industrial and electrical distributor, confirmed to BleepingComputer that it is investigating a claim of CRM data exfiltration by a third party, after ExfilSquad claimed 2.6 million records taken from its cloud CRM environment (BleepingComputer, 2026-08-11). The company's spokesperson states "We have worked with our cloud CRM vendor on the matter, and we do not believe that there is a risk to sensitive data", and the company "found no evidence of ransomware or other malicious software on its IT systems", with no business disruption reported.

Two things happened in sequence and both matter. After the deadline for Wesco to enter ransom negotiations expired, ExfilSquad published the data it says it exfiltrated (BleepingComputer, 2026-08-11), so this is a completed publication event, not a pending threat. And Wesco's posture is a third distinct response pattern from this campaign's victims: the UK Department for Education and the Police National Legal Database both issued full confirmations with corrected scope, other named victims have said nothing at all, and Wesco concedes the incident while contesting its severity. A triage queue that ingests leak-site feeds now has three calibration points from one actor: confirmed-and-detailed, confirmed-but-disputed, and unanswered.

The technical half needs its hedge stated plainly, because the reporting is careful and it would be easy to over-read. What BleepingComputer says is two separate things: that research from Resecurity and VenariX indicates the group "has targeted in the past improperly configured Microsoft Power Pages data tables", and that while Wesco has not shared how it was breached, "publicly available information indicates that Wesco may be using Microsoft Dynamics 365" (BleepingComputer, 2026-08-11). No source joins those two into a finding that this breach used a Dynamics 365 surface, and no source states the group's targeting has widened. The honest read is that the documented mechanism remains anonymously readable Power Pages data tables (no exploit, no malware, just data a portal was configured to serve to anyone) and that this victim's root cause is undisclosed.

Triage: exfiltration through an over-permissioned anonymous web role produces no exploit signature and no malware, so endpoint and network telemetry will be silent by construction, which is consistent with Wesco finding no ransomware or malicious software on its systems while an incident had nonetheless occurred. What it does produce is bulk read volume against Dataverse tables attributed to the anonymous or portal service identity rather than to a named user; the discriminator against a legitimately public portal is the breadth of tables touched and the sequential, high-rate access pattern, not the identity itself, which is supposed to be reading something.

Microsoft Threat Intelligence reported over the weekend of 2026-08-08/09 that Storm-1175 (a financially motivated, China-linked actor previously known for high-velocity Medusa ransomware campaigns) began deploying a previously undocumented strain, StormEncryptor, on 2 August, and is likely exploiting CVE-2026-18577 in N-able N-central to do it. Microsoft has not formally confirmed the access vector; what it notes is that the deployments began the same day the flaw was disclosed. Huntress found more than half of reachable cloud-hosted N-central servers across its partner base still unpatched, and 28.6% of self-hosted instances.

The N-able N-central authentication-bypass chain this pipeline has tracked through two hotfixes now has an assessed actor and a named payload. Microsoft Threat Intelligence reported that "the Storm-1175 group began deploying a new ransomware strain on August 2 called StormEncryptor", and that the group is likely exploiting CVE-2026-18577 in N-central to obtain access (The Record, 2026-08-10). The hedge is Microsoft's own and matters: "Microsoft has not formally confirmed the access vector, but noted that StormEncryptor deployments began the same day the flaw was disclosed" (The Record, 2026-08-10). The same-day correlation is the evidence; a confirmed vector is not yet on the record.

The Record describes the actor as financially motivated and linked to China, and its prior activity is why the attribution changes a defender's calculus rather than just labelling it (The Record, 2026-08-10). Microsoft's own April 2026 profile of the group (which does not itself make a China attribution) describes high-tempo Medusa ransomware operations against vulnerable web-facing assets, and records the group moving from initial access to data exfiltration and ransomware deployment often within a few days and in some cases within 24 hours (Microsoft Threat Intelligence, 2026-04-06). Its earlier Medusa victims were healthcare, professional services and finance organisations in Australia, Britain and the United States; StormEncryptor is the departure from that tooling (The Record, 2026-08-10). Note what those sectors and countries describe: the group's previous victim set, not confirmed victims of this campaign, for which no count has been disclosed.

Two facts sharpen the exposure picture for anyone whose managed service provider runs N-central. N-able states it detected the original flaw in a zero-day attack on 31 July, though it is unclear whether the actor behind that first intrusion was Storm-1175; the initial patch was bypassed, forcing an emergency hotfix on 2 August and a second on 6 August with the warning that the first was not enough. And the patch gap is wide: after the fixes were available, Huntress found more than half of reachable N-central cloud servers across its partner base still unpatched, with 28.6% of self-hosted instances exposed (The Record, 2026-08-10). Huntress went as far as suggesting that anyone running N-central in a higher-risk environment where exposure cannot meaningfully be reduced may need to consider turning the tool off, while cautioning that doing so costs central visibility, patching and remote access when they may be needed most.

The structural point is the one this constituency should carry: a single compromised RMM server is a gateway to every endpoint it manages, so one breach at one provider cascades across its whole client base. The Record draws the direct comparison to the 2021 Kaseya intrusion, where REvil compromised around 60 direct customers and subsequently hit roughly 1,500 downstream businesses, and to the 2024 ScreenConnect attacks; in which Microsoft says Storm-1175 was among the actors targeting the product (The Record, 2026-08-10).

The LegacyHive proof-of-concept covered here on 2026-07-29, reproduced on fully patched Windows and described at the time as having no Microsoft mitigation, appears to be fixed. Microsoft's August Patch Tuesday shipped CVE-2026-62832, an improper-link-resolution elevation-of-privilege flaw in the Windows User Profile Service rated CVSS 7.8, publicly disclosed before the patch and assessed "Exploitation More Likely". Rapid7 assesses the advisory is a solid match for the researcher's description of LegacyHive; Microsoft's record does not name the technique, so the identification is Rapid7's judgement rather than a vendor confirmation.

The entry on LegacyHive (the Nightmare Eclipse Windows proof-of-concept that LevelBlue reproduced on a fully patched July-2026 build) recorded that the vendor offered no mitigation for that class of abuse. Microsoft's August Patch Tuesday appears to have closed it. CVE-2026-62832 is described in Microsoft's own record as "Improper link resolution before file access ('link following') in Windows User Profile Service allows an authorized attacker to elevate privileges locally", scored CVSS 3.1 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), rated Important, recorded as publicly disclosed before the fix, not exploited, and assessed as "Exploitation More Likely" (MSRC, 2026-08-11).

Microsoft does not name LegacyHive, and the identification is worth attributing precisely rather than assuming. Rapid7 states that between the public disclosure and the advisory FAQ (which describes an authenticated attacker who has credentials for another account and loads another user's registry hive) "the advisory is a solid match for Nightmare Eclipse's description of LegacyHive" (Rapid7, 2026-08-11). That is an assessment by a third party, not a vendor mapping, which is why this entry carries it as such.

The independent detail that makes the match credible comes from the unofficial patch that preceded the official one. 0patch analysed the flaw in July and describes it in the same terms: the vulnerability lies in the Windows User Profile Service, where a time-of-check-to-time-of-use condition lets a local attacker use a symbolic link to confuse the service into loading any user's registry hive instead of the requesting user's, ending up mounted in the attacker's own registry space with read/write permissions. Its root cause, per 0patch, is an access-check fallback: when the service can open the hive file with full access it mounts it under the requesting user's identity using NtLoadKey3, which supports impersonation, but when it cannot, it falls back to the older NtLoadKeyEx without impersonation, so the hive loads with full access as Local System. The consequence 0patch names is the same one the original entry described from the attacker's side: read the target user's stored secrets, or replace paths to trusted executables and DLLs so they run the next time that user logs in (0patch, 2026-07-20).

For anyone who acted on the July coverage, the practical delta is short. The prerequisite is unchanged and still limits the blast radius; the attacker needs a local session plus credentials for a separate account, so this is a post-compromise escalation step rather than an entry point. The August cumulative update supersedes the 0patch micropatch as the remediation, and estates that deployed the community patch were covered in the interval. No action item ships with this entry: the fix arrives inside the ordinary Patch Tuesday cycle, and the entry exists to correct the record on the earlier "no fix available" framing rather than to open new work.

Metabase's unauthenticated SQL-injection zero-day, covered here on 2026-08-09 when no CVE existed, has been assigned CVE-2026-72898 in GitHub Security Advisory GHSA-vwf4-m7j8-wcjf at CVSS 3.1 10.0, and CISA added it to the Known Exploited Vulnerabilities catalog on 2026-08-11. The advisory publishes affected ranges per release line and confirms active exploitation in Metabase's own words. For self-hosted instances nothing about the exposure changed, but the flaw is now visible to every scanner, SBOM pipeline and CVE-keyed patch process that could not see it a week ago.

The entry on Metabase's unauthenticated SQL-injection zero-day closed on the observation that no CVE identifier had been assigned, so a purely CVE-driven patch process would not surface the exposure at all. That gap is now closed in both directions. GitHub Security Advisory GHSA-vwf4-m7j8-wcjf assigns CVE-2026-72898 with a CVSS 3.1 base score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), and Metabase's own advisory text states that "Metabase has confirmed active exploitation of this vulnerability" and that the flaw "allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance" (Metabase, 2026-08-06). CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-08-11 with a 14 August due date (CISA, 2026-08-11).

The second half of the delta is the affected-version matrix, which the vendor's original blog post did not carry in this form. The advisory lists the affected ranges per release line as >= x.58.0 < x.58.23, >= x.59.0 < x.59.20, >= x.60.0 < x.60.16, >= x.61.0 < x.61.10, >= x.62.0 < x.62.8 and >= x.63.0 < x.63.3, and names the patched versions separately as x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 and x.63.5; note the two lists do not meet, so a build sitting between an affected upper bound and its patched release is not described either way and should be treated as needing the named patched version (Metabase, 2026-08-06). That turns "upgrade Metabase" into a query an asset inventory can answer, and it is what a scanner needed in order to report anything at all.

Nothing here changes the exposure of an instance that has not been upgraded; the exploitation window has been open since at least 3 August per the earlier coverage, and the interim control is unchanged: block the /api/session/reset_password endpoint if an upgrade cannot happen immediately. What changed is visibility, and that is the operationally useful part. An organisation whose vulnerability management runs off CVE identifiers, SBOM matching or KEV feeds got no signal on this flaw for over a week while it was being exploited; the same tooling will now produce a finding on the next scan cycle. The advisory's post-upgrade guidance also stands and is worth re-reading against what an attacker with administrator access would already have taken: revoke active sessions, audit API keys and administrator accounts, and rotate the stored credentials for every connected data source, because those credentials are what an instance-level compromise reaches.