Thursday, 13 August 2026

MyDr, a Polish electronic health record platform serving thousands of clinics, confirms a deliberate criminal intrusion — and because it is a processor, not a controller, the people affected cannot be told directly

MyDr serves thousands of Polish healthcare facilities and, on figures the company itself gives, processes three million appointments and 2.7 million prescriptions a month (Zaufana Trzecia Strona, 2026-08-10). It published an incident statement updated 2026-08-12 at 18:35 CET confirming an intrusion: "Na tym etapie trwającego dochodzenia potwierdzamy, że staliśmy się celem zewnętrznego, celowego działania o charakterze przestępczym, którym objęta była część danych" — at this stage of the ongoing investigation we confirm that we became the target of an external, deliberate act of a criminal nature, which covered part of the data (MyDr, 2026-08-12). The company states the affected data is most likely historical, from 2024 and earlier, and may not cover all MyDr clients or all their patients; that its systems are fully operational and safe to use; that its cybersecurity partners monitoring the dark web have found no evidence the data has been published or shared publicly; and that it cannot yet confirm the quantity and type of data disclosed until forensic analysis completes (MyDr, 2026-08-12).

The claims that prompted the statement are considerably larger. People presenting themselves as the perpetrators contacted Polish security journalist Adam Haertle before the disclosure and said they hold 18,814,422 unique PESEL national identity numbers and 2.5 TB of data (Zaufana Trzecia Strona, 2026-08-10). The outlet's verification is careful and worth reading as a method rather than a verdict: it was sent a database record for a senior Polish politician whose date of birth, identity number, name and one of two phone numbers it independently confirmed, along with the correct national health-fund region; it asked the claimants to look up the identity numbers of four industry volunteers and received records for two, which with the author's own record makes three matches out of five checked. The outlet states it caught the claimants in no inconsistency within what it could check, while being explicit that its checking ability is limited and that it has no way to verify either the 2.5 TB volume or the 18-million figure — though it observes that the figure is consistent with the potential reach of a system serving thousands of practices. It also records that Gawkowski, whom it names as premier, wrote publicly that much suggests an unauthorised person may have gained access to the data.

The access chain is a lead, not a finding. Per the claimants' own account, they first obtained remote code execution through an XXE-class flaw in the handling of PKCS#12 certificates — "Według tego, co usłyszeliśmy od sprawców, najpierw udało im się uzyskać zdalne wykonanie kodu przez podatność typu XXE przy obsłudze certyfikatów PKCS#12" — which yielded a GitHub API key, from there the platform's source code, and from there the AWS infrastructure. The outlet's next sentence is the one that governs how this should be read: "Nie byliśmy w stanie niezależnie zweryfikować tych informacji" — we were not able to independently verify this information (Zaufana Trzecia Strona, 2026-08-10). MyDr says it cannot share technical details while the investigation runs. No CVE exists and no vendor has confirmed a vulnerability class; treat the chain as an unverified attacker narrative that is nonetheless a reasonable thing to check for in your own certificate-parsing paths.

The extortion mechanics are documented more solidly, because the outlet handled the artefacts. The claimants sent the company's chief executive a message on 5 August linking to a PDF that was supposed to self-delete after download and did not; the file was password-protected, and the claimants noted the password was the executive's own PESEL number — which the outlet points out is a low-entropy value and therefore no obstacle. The document framed the approach as an offer to purchase the results of a security audit, and contained internal corporate correspondence including personnel information and a whistleblower report, alongside a fragment of the company's partner-doctor database. The claimants also showed a message sent to company employees from the company's own bulk-SMS account, and named Jira and a HubSpot CRM among systems they say they reached in full (Zaufana Trzecia Strona, 2026-08-10). On attribution the outlet is deliberately unhelpful in the right way: the claimants write in English, use a Russian-style emoticon convention, and produce English that reads as though deliberately rewritten to imitate a non-native speaker from elsewhere — which it reads as an attempt to lay false trails.

The structural finding, and the reason this matters beyond Poland. MyDr cannot tell affected people they are affected. "MyDr jest jedynie "podmiotem przetwarzającym" zgodnie z RODO, a administratorem danych są placówki ochrony zdrowia, których są tysiące" — MyDr is only a processor under GDPR, and the controllers are the healthcare facilities, of which there are thousands (Zaufana Trzecia Strona, 2026-08-10). The outlet's assessment is that individuals therefore have no way to check their own exposure and must wait for MyDr to determine scope, notify each facility, and for each facility to notify its own patients — a chain it expects to take many days. MyDr's own statement is consistent with this: it says it will contact affected clients proactively once it establishes which facilities and which data are involved, will support them in reporting to the data-protection authorities and in patient communication, and that no reports from facilities are required at present.

WindRelay — a purpose-built Android NFC-relay malware installed silently by a companion remote-access trojan during the fraud call itself, with per-victim app names carrying the victim's own name

Group-IB's fraud-protection team published an analysis on 2026-08-12 of a technique rather than a single case: a previously unseen Android NFC-relay malware family it tracks as WindRelay, deployed together with SpyNote, a long-running commodity remote-access trojan, inside a live social-engineering call (Group-IB, 2026-08-12). The pairing is the finding. Prior NFC-relay tooling in this region — the modified NFCGate builds first seen in Czechia in late 2023 and their descendants — has been documented by several vendors as standalone malware the victim is talked into installing. Here the victim installs one thing and gets two.

The chain, as observable behaviour. The caller impersonates a bank employee reporting a card problem and stays on the line for the whole intrusion, rather than relying on a link or a one-time code that the victim actions alone. The victim is directed to sideload an application from outside the official store. That application is SpyNote, compiled for this target: Group-IB records that its app label and package carry the victim's own name, which the builder toolkit supports natively, and describes the purpose as trust abuse — an app already bearing your name reads as proof the caller knows who you are, and removes the unfamiliar-name check victims are trained on. Once the trojan holds Android accessibility permissions, the operator uses them to install the second component: "SpyNote’s Accessibility Service access lets the fraudster sideload and activate the NFC app silently, with no screen sharing ever triggered" (Group-IB, 2026-08-12). That property is what defeats the control most banks have deployed: screen-share detection never fires, because no screen is shared.

WindRelay's requested permissions read as a design specification for the fraud rather than a grab-bag: near-field communication to capture card data at the moment the victim is asked to tap, network access to relay the captured exchange in real time to a second device the fraudster presents to a physical terminal, contacts access for onward targeting, an unusual diagnostic-dump permission for inspecting the device and its security tooling, and custom self-declared permissions that hinder interoperation with security software (Group-IB, 2026-08-12). The documented case was monetised through two channels inside one 13-minute call — a digital loan taken out through the trojan's access to the banking application, and a card-present cash-out through the relay — which Group-IB presents as a deliberate dual-monetisation pattern rather than an improvisation.

Scale and geography come from sample correlation rather than victim reports: "We identified 23 samples uploaded to VirusTotal between November 2025 and July 2026", mimicking institutions in Czechia, Slovakia and Slovenia with text localised per country, some carrying personalised interface elements including the victim's name — which Group-IB reads as evidence the operator can build per-victim applications on demand (Group-IB, 2026-08-12).

Detection concepts. Group-IB's own guidance is unusually concrete and centres on timing rather than identity: "Alert installations of apps from non-official sources (package installer, not Play Store) that occur during an active call. This timing pattern is a strong signal on its own, independent of what the app does." (Group-IB, 2026-08-12) Alongside it: accessibility-service grants followed within minutes by a second sideload with no screen-share session; applications granted device-administrator privileges shortly after a call begins; and building detection around permission sets rather than known-sample hashes, which is what catches a family that recompiles itself per victim. On the account side, the dual-monetisation shape gives a correlation rule the bank owns entirely — a loan disbursement and a card-present transaction for the same customer within a short window, which Group-IB notes is unusual for genuine activity.

Triage: sideloading, accessibility grants and NFC use are each individually legitimate on Android, which is why none of them alone is the signal. The discriminators the mechanism forces are sequence and timing: the install arrives from the package installer rather than the store, it happens while a call is in progress, a second install follows the accessibility grant without any user-visible remote-control session, and the newly installed application requests near-field communication together with diagnostic-dump and self-defined permissions — a combination an ordinary consumer application has no reason to hold.

UK ICO reprimands the national criminal-records office over a seven-month website compromise — outsourced patching with no internal owner was the cause, and network segmentation is what capped the damage

The UK Information Commissioner's Office issued a reprimand to ACRO Criminal Records Office — the national policing body that runs criminal-record-check services — for infringing Articles 32(1), 32(1)(b) and 32(1)(d) of the UK GDPR, announcing it on 2026-08-12 against a formal record dated 7 August (ICO, 2026-08-12; ICO, 2026-08-07). Between August 2022 and March 2023 a hacker held unauthorised access to ACRO's public website and content management system and staged personal information for theft; ACRO could not conclusively determine whether it was removed. Up to 10,920 people may have been affected, and the ICO's list of potentially exposed fields is unusually broad for a website compromise: names, dates of birth, addresses, National Insurance numbers, passport and driving licence details, bank account information, biometric data, and criminal-offence and other special-category information, covering applicants for Police Certificates and International Child Protection Certificates, subject-access applicants, and third parties connected to those applications (ICO, 2026-08-12).

The finding is about ownership, not tooling. The ICO's investigation concluded that "ACRO did not ensure clear responsibility for identifying and monitoring critical CMS security updates, failed to maintain an effective patch management process, and did not adequately investigate security alerts that could have identified the hacker’s activity earlier" (ICO, 2026-08-12). The specific structural defect it names is that ACRO had engaged third-party providers to deliver security services including patch management — but engaging a provider is not the same as assigning the duty to notice that a critical update exists and confirm it was applied. That gap is what let a content management system stay exploitable long enough for an intrusion to run for seven months.

The mitigating half is equally concrete, and the ICO records it as one of the factors it took into account in deciding to issue a reprimand: "Network segmentation prevented the hacker from moving beyond the compromised website environment into core systems, reducing the potential scale of harm" (ICO, 2026-08-12). The regulator also credits ACRO's remediation — decommissioning the compromised infrastructure, migrating services elsewhere, implementing security monitoring, improving threat visibility and further strengthening segmentation. The ICO's own advice to other organisations is to make accountability explicit for identifying, assessing and implementing updates across all systems and suppliers; to ensure alerts are monitored, investigated and escalated; and to treat patch management, vulnerability management and regular testing as the primary defences.

The ICO names no CVE, no CMS product and no intrusion technique beyond unauthorised access to the website and content management system, so there is no detection content to derive here and none is invented. The published artefact is the causal analysis, not the tradecraft.

CVE-2026-58115 — Siemens SIMATIC IoT2050 Advanced ships a Node-RED interface with no authentication, so one unauthenticated HTTP request runs code as root on an OT edge gateway (CVSS 10.0)

Siemens ProductCERT published SSA-834709 on 2026-08-11 covering CVE-2026-58115 in SIMATIC IoT2050 Advanced devices (order number 6ES7647-0BA00-1YA2) running Industrial OS with Node-RED installed. The advisory's own description of the defect is a single sentence with no qualifiers: "Affected devices do not enforce authentication on the Node-RED HTTP interface, allowing unauthenticated access to programming nodes that are capable of executing system commands on the server." The consequence follows directly — "This could allow an unauthenticated remote attacker to create malicious flows through the HTTP interface in order to execute arbitrary code on the underlying server with maximum privileges." (Siemens ProductCERT, 2026-08-11)

Siemens scores it 10.0 under both CVSS 3.1 and CVSS 4.0, with the 3.1 vector recording network attack vector, low complexity, no privileges, no user interaction, changed scope and high impact on confidentiality, integrity and availability, classified as CWE-306, missing authentication for a critical function. All versions below V4.3.4.1 are affected; V4.3.4.1 is the remediation. Where the update cannot be applied, Siemens names two specific mitigations — uninstall Node-RED, or harden the Node-RED installation per its User Guide — alongside its standing recommendation to protect network access to devices and operate them inside a protected environment. (Siemens ProductCERT, 2026-08-11) ANSSI's CERT-FR carried the advisory to its constituency on 12 August (CERT-FR, 2026-08-12), and NCSC-NL published its own on 11 August (NCSC-NL, 2026-08-11).

Why this clears the bar without any exploitation report. Nothing in the advisory claims in-the-wild abuse, and none is reported anywhere this run could find. The urgency comes from the flaw's own mechanics rather than from attacker activity: the vulnerable interface is a flow editor whose legitimate purpose is to run code, the missing control is authentication rather than a memory-safety condition needing a working exploit, and the SIMATIC IoT2050 is an edge gateway whose product role is to sit at the boundary between an operational network and the systems above it. There is no exploit to write — reaching the interface is the exploit — which is why the absence of observed activity says very little about how long that will remain true. That places it squarely in the class of flaws demanding an out-of-band response rather than the next maintenance cycle, and the affected device class is one European energy, water and transport operators deploy.

Detection and hardening, in telemetry terms. The behaviour to look for is a change to the device's automation logic that no engineering workflow accounts for. In application and web-access telemetry on the gateway, requests to the Node-RED administrative and flow-deployment endpoints that arrive without an associated authenticated engineering-workstation session are the exploitation signal; in configuration state, flow definitions whose modification timestamps do not line up with a change record are the persistence signal; and in process and network telemetry on the device, command execution or outbound connections originating from the Node-RED runtime process — rather than from the automation application it is meant to serve — indicate the programming nodes are being used as an execution primitive. Because the interface answers anyone who can route to it, network position is the compensating control that works today: restrict reachability of the Node-RED HTTP interface to the engineering segment, and treat any path to it from a general-purpose corporate network or from a cellular or carrier-provided link as an exposure to remove rather than to monitor.

UPDATE — CVE-2026-59310 (VMware vCenter Syslog traversal) crosses into confirmed compromise: 361 victim addresses in 47 countries, first beacons five days after disclosure, and Switzerland's NCSC flips the advisory to actively exploited

UPDATE · originally covered VMSA-2026-0006 — VMware vCenter: unauthenticated Directory Service auth bypass and Syslog traversal RCE (both CVSS 9.8), plus a VMXNET3 guest-to-host escape (2026-07-30)

the entry on Broadcom's VMSA-2026-0006 recorded five vCenter, ESX, Workstation and Fusion flaws, noted that none was reported exploited and that all had been reported privately to Broadcom. One of them has now been confirmed in use against real estates.

QUIRSO, a German security firm, reports that an incident-response engagement gave it visibility into an exploitation campaign against internet-accessible vCenter systems using CVE-2026-59310, the CVSS 9.8 directory traversal in the vCenter Syslog server that reaches arbitrary code execution from network access alone (QUIRSO, 2026-08-10). The timeline is the part that should reset patch priorities: "Compromised systems identified by QUIRSO were found to first establish contact with the attacker's domains on August 3, five days after Broadcom publicly disclosed the flaw" (The Hacker News, 2026-08-12). QUIRSO records 361 unique victim IP addresses across 47 countries, with Germany, the United States, Turkey, Iran and France the most affected and 185 of the 361 addresses in those five countries; it is explicit that an address does not correspond to an organisation, since some belong to hosting providers and shared infrastructure. By 5 August, 343 of the 361 addresses had already appeared — the campaign reached roughly 95 per cent of its observed footprint within three days of starting (QUIRSO, 2026-08-10). QUIRSO assesses that while the attacker might have had prior knowledge of the flaw, the correlation with disclosure suggests the advisory itself was the campaign's starting point.

Switzerland's NCSC updated its own VMSA-2026-0006 advisory on 12 August, setting "Current exploitation status: Actively Exploited" and citing QUIRSO's report (NCSC-CH, 2026-08-12).

What the attacker does after landing. The chain reported is path-traversal activity consistent with the flaw, "followed by the deployment of a malicious cron job to establish persistence on the host using reverse_ssh" (The Hacker News, 2026-08-12), an open-source SSH-based reverse-shell framework whose legitimate penetration-testing features include automatic connect-back, port forwarding and file transfer. The choice is a deliberate one about direction of travel: the control channel is established outbound from the appliance, which sidesteps controls built to stop unsolicited inbound access (QUIRSO, 2026-08-10). QUIRSO says a follow-up publication examining the attacker's tradecraft, infrastructure and post-exploitation activity is planned, and that further detection content is being released in coordination with law-enforcement partners.

A second, separate signal sits alongside it and should not be merged with the first. The Hacker News reports Defused Cyber observing a spike in scanning against vCenter — version probes and walks of the single-sign-on flow — that it associates with CVE-2026-59309, the unauthenticated Directory Service authentication bypass from the same advisory. QUIRSO's co-founder Denis Szadkowski told the outlet there is not enough evidence to correlate that scanning with the intrusion set behind CVE-2026-59310, adding that "the forensic evidence strongly points toward CVE-2026-59310 as the initial access vector" for the compromises QUIRSO investigated (The Hacker News, 2026-08-12). Two flaws in one advisory are drawing attention independently; only one has confirmed compromises behind it.

Detection concepts, telemetry class first. The behaviours worth hunting are all unusual for a management appliance rather than unusual in general. In egress and flow records, an SSH-protocol session initiated from a vCenter appliance to an external destination inverts the normal direction of vCenter traffic, which is inbound administrative access and outbound management of hosts. In configuration and scheduling state on the appliance, cron or scheduled entries that no platform-engineering change record accounts for are the persistence artefact reported here. In process telemetry, execution lineage descending from the Syslog service is the exploitation artefact. QUIRSO's own framing of the tool is the right calibration and applies to any dual-use binary: "The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity." — "In combination with unauthorized installation, unexpected outbound connections or execution on a vulnerable vCenter appliance, however, it is a high-priority indicator requiring investigation." (QUIRSO, 2026-08-10)

Triage: administrators do legitimately place scheduled jobs on appliances and do run SSH from jump hosts, so neither artefact alone resolves. What separates this activity is the appliance being the SSH client toward an external network, a scheduled entry created outside a change window and not present in the platform team's configuration baseline, and either appearing on a vCenter whose build predates the VMSA-2026-0006 fixes. On an appliance patched before 29 July none of the three should be present at all.

UPDATE — attackers are running Rapid7's SharePoint proof-of-concept against honeypots within a day, and the published root cause is four validation failures that let an unsigned token impersonate a site administrator

UPDATE · originally covered UPDATE — the half-patched SharePoint chain this pipeline flagged in July is now complete and public: CVE-2026-63520 ships, and Rapid7 releases the analysis and proof-of-concept for CVE-2026-55040 (2026-08-12)

yesterday's entry recorded that Rapid7 had published a technical analysis and proof-of-concept for CVE-2026-55040 and stated plainly that it did not have that analysis in hand, so no behavioural detail could be offered. Two things changed within a day. The proof-of-concept is being used in attacks, and the analysis — read in full for this entry — turns an exposure problem into a hunt.

Threat-intelligence company Defused reported on 2026-08-12 that "Attackers are now using the @rapid7 POC for CVE-2026-55040 against our SharePoint honeypots", roughly a day after the code was published (BleepingComputer, 2026-08-12). That is one company observing its own sensors, not a vendor confirmation: the same report notes that "While Microsoft has labeled this security flaw as an attractive target for attackers", it has not yet flagged it as successfully exploited in the wild (BleepingComputer, 2026-08-12). Switzerland's NCSC added the exploitation-attempt claim to its own July Patch Tuesday advisory on 12 August, having added the analysis and proof-of-concept to the same advisory the day before (NCSC-CH, 2026-08-12). For scale, the same reporting cites Shadowserver, which "currently tracks over 8,500 Microsoft SharePoint servers exposed online", with the honest caveat that how many are honeypots or already patched is unknown (BleepingComputer, 2026-08-12).

How the bypass works, and why it matters that it is four bugs and not one. Rapid7's analysis, based on decompilation of the identity module from a fully patched Subscription Edition build, states that "The root cause is a chain of four distinct weaknesses that, when combined, allow an unauthenticated remote attacker to forge a valid JWT and impersonate any SharePoint site user" (Rapid7, 2026-08-11). SharePoint's server-to-server authentication uses a nested token: an outer token carrying user identity claims, and an inner "actor token" representing the calling application that is expected to be cryptographically signed. Each of the four failures removes one guarantee from that design.

First, the token handler explicitly turns off the requirement for signed tokens when it builds its validation parameters — Rapid7's description is blunt: "This single line disables the JWT library's cryptographic signature verification", so the outer token is accepted with no signature at all. Second, the code resolves the inner actor token's signing key from a thumbprint value carried in that token's own header, searching all trusted certificates including SharePoint's own local security-token-service certificate, and assigns the resolved key without ever verifying a signature against it. Third, issuer validation then looks for a registered token service matching that certificate, does not find one — because the server's own signing certificate is not in the collection being searched — and treats the absence of a match as grounds to accept rather than reject. Fourth, the final signature step requires only that a signature string be non-empty; any arbitrary value satisfies it. The result is that the identity in the outer token's name claim, which the caller chooses, is resolved to a real account. (Rapid7, 2026-08-11)

Two properties of that chain matter operationally more than the mechanics themselves. The certificate whose thumbprint the attacker needs is published by the server: Rapid7 records that it is retrievable from an unauthenticated metadata endpoint on the SharePoint site itself, so no prior access is required to obtain it. And picking a useful identity is a separate reconnaissance step — Rapid7 describes querying the target's domain controller over an anonymous SMB session to learn the domain identifier, then walking relative identifiers to enumerate candidate accounts and find one that is a site administrator, noting that a user principal name works too but is less reliable to guess. (Rapid7, 2026-08-11)

Detection, in telemetry terms. The decisive weakness leaves a server-side record: Rapid7's decompilation shows the issuer-validation path emitting a trace message stating that the issuer was accepted because no registered token service matches the signing certificate, immediately before returning success (Rapid7, 2026-08-11). On a healthy farm that path should be rare; on an attacked one it fires on every forged token. That message in the SharePoint diagnostic trace logs is the highest-value single artefact available, and it is a server-side one, so it survives an attacker who never touches the endpoint. Alongside it, three sequences are worth building around: an unauthenticated request to the site's metadata endpoint from an external address, followed within a short window by bearer-token requests to the site's REST API from the same source; authenticated REST activity — reading files, minting a form digest, changing configuration — with no corresponding interactive sign-in or federation token issuance for that account in identity logs; and anonymous SMB sessions enumerating account identifiers from an address that also talks to the SharePoint front end.

Triage: legitimate server-to-server integrations also present bearer tokens to the SharePoint REST API, which is why the token's presence is not the signal. The discriminators are the ones the mechanism forces: a token whose acceptance is accompanied by the unregistered-signing-certificate trace message, activity attributed to a highly privileged account with no matching sign-in event in the identity provider, and an external source address that fetched the unauthenticated metadata endpoint shortly beforehand. A normal integration is registered, so its issuer resolves against a registered token service and never takes the accepting-by-default branch.

UPDATE — Cl0p named 44 victims on its leak site in a single batch, including a Swiss and a Dutch organisation, and one vendor assesses an earlier masked batch as possibly the Windchill campaign

UPDATE · originally covered Cl0p-affiliated actors move the PTC Windchill / FlexPLM intrusions (CVE-2026-12569) into a mass extortion-email phase, with no victims named yet (2026-07-27)

the entry on Cl0p's mass-extortion campaign against internet-exposed PTC Windchill and FlexPLM deployments recorded that no victims had yet been listed on the group's leak site. Victims are now being listed, and the shape of the batch — rather than any individual name — is the delta.

Read directly from the Ransomware.live tracker's recent-victims feed this run, 44 named Cl0p listings were all first recorded by the tracker on 2026-08-12 (Ransomware.live, 2026-08-12). The tracker's own record timestamps advance at a near-constant 33 to 40 seconds apart, which is its crawl cadence rather than anything about the leak site — so the feed establishes that these listings were picked up in one sweep, and nothing at all about when Cl0p actually posted them. This entry therefore makes no claim about a publication window. The country codes attached to the records include Switzerland, the Netherlands, Finland, the United Kingdom, Italy, Slovakia, Hungary and France alongside a larger United States contingent; the tracker files the Dutch listing under healthcare and the Swiss one under retail and e-commerce. That tracker mirrors what the leak site publishes and verifies none of it; the company descriptions it prints alongside each record are machine-generated and are not used here. What the feed establishes is that the listings exist, when they appeared, and that European organisations are among them — nothing about whether any of those organisations was in fact compromised.

On whether this batch is the Windchill campaign, the honest answer is that nobody has said so. Foresiet reviewed a batch of 42 masked Cl0p listings and published on 2026-08-10, noting that the advertised data categories recurred with unusual consistency — project repositories, databases, CAD files, engineering drawings, backups and product documentation, with three listings spelling the Windchill product name directly — and that this pattern resembles product-lifecycle-management content more than a general file share. Its conclusion is carefully bounded: it assesses a possible relationship with the broader Cl0p activity involving CVE-2026-12569, while stating that "the available leak-site information alone cannot establish the initial-access vector used against each listed organization", and that it had no forensic access to any affected environment (Foresiet, 2026-08-10). Foresiet's batch is an earlier, masked one; whether the 12 August named batch is the same set unmasked is not stated by any source read this run, and is not asserted here.

What is independently confirmed is the underlying vulnerability's status. CVE-2026-12569, the unauthenticated deserialization remote-code-execution flaw in PTC Windchill PDMLink and FlexPLM, has been in the CISA Known Exploited Vulnerabilities catalog since 2026-06-25 and carries "Known" in its ransomware-campaign-use field, checked directly against catalog version 2026.08.11 (CISA KEV catalog, 2026-08-11). Foresiet also restates the post-exploitation behaviour PTC itself documented: web shells planted under the Windchill login directory, which provide persistent access and command execution after the initial exploitation and which survive patching unless separately found and removed (Foresiet, 2026-08-10).

UPDATE — CISA now records the already-exploited SharePoint deserialization flaw CVE-2026-45659 as used in ransomware campaigns, changing what an unpatched farm risks

UPDATE · originally covered CVE-2026-45659 — Microsoft SharePoint Server: authenticated deserialization RCE, now KEV-listed (2026-07-02)

the original entry recorded CISA's 1 July catalogue addition for CVE-2026-45659 as the first public confirmation that this SharePoint deserialization path was being exploited, against a Microsoft advisory that still rated it "Exploitation Less Likely". The catalogue entry has since gained a second flag.

Queried directly this run, the Known Exploited Vulnerabilities catalog at version 2026.08.11 records CVE-2026-45659 with its ransomware-campaign-use field set to "Known" (CISA KEV catalog, 2026-08-11). That the value changed on 11 August, rather than having been present since the July addition, is reported separately: CISA "confirmed that a high-severity Microsoft SharePoint remote code execution vulnerability (CVE-2026-45659), flagged as actively exploited since early July, is now also being exploited by ransomware gangs" (BleepingComputer, 2026-08-12). The same reporting notes that of the fourteen SharePoint vulnerabilities the agency has flagged as actively exploited since November 2021, eight have also been exploited in ransomware attacks.

The flaw itself is unchanged from the original coverage: deserialization of untrusted data reachable by an attacker holding at least Site Member permissions, CVSS 8.8, patched by Microsoft on 2026-05-21. No source names the operation responsible, its victims, or how the required authenticated access is obtained in these campaigns, and none is asserted here.