Cl0p PTC Windchill campaign status: the extortion wave crossed from leak-site assertion to partial victim corroboration this week — Philips and Shell responded, European organisations appeared among the named listings, and a second vendor confirmed the webshell artefact PTC had already documented

Status update on the Cl0p extortion campaign against internet-exposed PTC Windchill and FlexPLM product-lifecycle platforms, which this pipeline has tracked since 27 July on CVE-2026-12569. Prior coverage recorded the campaign in a state that is common for this actor and unsatisfying for defenders: a KEV-listed flaw, an extortion wave under way, and a set of leak-site listings that no victim had acknowledged. Three things changed this week, and together they move it from assertion toward evidence without closing the central gap.

The listings became European and named. This pipeline's operational entry of 13 August recorded a leak-site tracker carrying 44 named Cl0p victim entries on 12 August, among them a Swiss and a Dutch organisation, alongside others in Finland, the United Kingdom, Italy, Slovakia, Hungary and France — a shift from the masked entries the campaign had been posting. The count is not stable across sources: BleepingComputer, reporting Shell's response two days later, reports that "the Clop gang listed it on its leak site as one of 43 new victims likely targeted in data theft attacks against Internet-exposed PTC Windchill and FlexPLM instances exploiting a critical improper input validation vulnerability tracked as CVE-2026-12569" (BleepingComputer, 2026-08-14). Neither figure is a count of confirmed victims. Separately, Foresiet reviewed an earlier batch of 42 masked listings and assessed a possible relationship with the Windchill and FlexPLM campaign on the basis of the advertised data categories — project repositories, CAD files, engineering drawings and product-lifecycle content — while stating explicitly that leak-site information alone cannot establish the access route for any listed organisation (Foresiet, 2026-08-10). That caveat is the one to carry: the categories are consistent with a PLM platform and consistent with a dozen other sources of the same file types.

Then two named organisations responded, which had not happened before in this campaign. Philips described an attempted cyberattack on a specific company server holding internal data, said it had been brought under control, and stated there was no impact on customer environments; Shell said it was aware of a potential incident and was investigating (NL Times, 2026-08-13; BleepingComputer, 2026-08-14). Neither statement attributes its incident to the Windchill flaw, and neither confirms the actor's claimed scope — Philips's account in particular describes a contained single-server event rather than the archive the leak site advertises. The third delta is corroboration rather than novelty, and this entry corrects its own earlier framing of it: ReliaQuest reported the actors deploying JSP webshells on compromised product-lifecycle platforms, relayed in the same reporting — but the artefact class was already public. Foresiet's 10 August analysis records that "PTC went on to report heightened threat activity and documented attackers deploying JSP webshells inside Windchill login directories", naming hexadecimal-named webshells under /Windchill/login/, a custom X-windchill-req HTTP request header, and flst.txt as an artefact of attacker file-listing activity (Foresiet, 2026-08-10). ReliaQuest's report is a second, independent observation of what the vendor had already described.

Triage: the discriminator for the webshell artefact is provenance rather than content, because legitimate JSP files live in exactly the same directories. A file written into a deployed web application outside a deployment or patch window, owned by the application-server service account rather than by the deployment tooling, and not present in the build artefact the platform team can reproduce, is the signal — a legitimate deployment replaces a whole application archive and leaves a matching record in the change system. The corresponding runtime observable is the application-server process becoming a parent to a shell or command interpreter, which a product-lifecycle platform has no routine reason to do.