The DragonForce listing against IFAGE — the Fondation pour la formation des adultes à Genève — is no longer an unverified leak-site claim. The group carried out its threat and published the data, which Le Temps reported had been done as of Thursday 2026-07-23: "Des photos de pièces d'identité, des adresses e-mail et postales, ainsi que des numéros de téléphone ou encore des résultats d'examens ont été publiés." — identity-document photographs, e-mail and postal addresses, telephone numbers and examination results (20 minutes, 2026-07-24). The same report states that their disclosure by the cybercriminals "concerne tant des employés de l'institut que des bénéficiaires (étudiants, entreprises, etc.)" — it covers both the institute's employees and its beneficiaries, meaning students and companies. It also cites an expert consulted by Le Temps who put the exposure at thousands of documents spanning several years and running to 2026. ICTjournal had reported the extortion threat a week earlier (ICTjournal, 2026-07-17).

The operationally interesting part is the gap between the victim's scoping and the published set. IFAGE's earlier public account of its incident placed the impact on employee data rather than student or pedagogical records; the leak contains multi-year examination results for students. First coverage flagged that the group's claimed volume already exceeded the institute's own disclosure, and publication has now settled that discrepancy in the attackers' favour. Nothing in the reporting identifies the initial-access vector, so no access-path lesson is available from this incident.

Contradiction: the sources and the victim do not agree on whether a ransom was ever demanded, and this entry does not resolve it. 20 minutes frames the publication as the consequence of an unpaid demand — "Si la rançon demandée n'était pas payée, les pirates informatiques qui s'en sont pris en avril à l'Ifage (Fondation pour la formation des adultes à Genève) promettaient de mettre en ligne les données dérobées" — while also reporting the foundation's own position that "La fondation avait aussi affirmé qu'elle n'avait pas reçu de demande de rançon, mais que, le cas échéant, elle refuserait de payer": it had received no ransom demand, but would refuse to pay if one came (20 minutes, 2026-07-24). ICTjournal is more definite on the demand's existence, reporting a week earlier that a ransom was now being demanded and that the group threatened to publish at the expiry of the ultimatum posted on its leak site (ICTjournal, 2026-07-17). A leak-site ultimatum naming a ransom the victim says never reached it is a common pattern and not necessarily either party misspeaking — demands are frequently posted publicly rather than delivered.

Microsoft Threat Intelligence published a forensic timeline of the AsyncAPI npm compromise that adds a detail with broad supply-chain-defence implications (Microsoft Threat Intelligence, 2026-07-15). Once the attacker held push access as the AsyncAPI service account (via the pull_request_target misconfiguration covered in the original entry), no npm-token theft was needed: a direct push to a release-triggering branch ran the project's own legitimate release-with-changesets workflow, which published the packages via npm trusted publishing over GitHub OIDC. As a result the five trojanized versions carry cryptographically valid provenance attestations that correctly identify the real repository, commit and workflow — even though the triggering commit was unauthorized (Microsoft Threat Intelligence, 2026-07-15).

Two further deltas: the payload triggers at import time (embedded in one file per package — index.js for the specs package, validator.js/utils.js/ErrorHandling.js for the generator family) and unwraps an IPFS-fetched bundle through three static-key crypto layers to an eval(), so npm install --ignore-scripts provides no protection; and Microsoft recovered all three self-identifying strings — M-RED-TEAM v6.4, miasma-train-p1 and miasma-test-org — from one binary, resolving the identifier ambiguity across the original reporting. Unit 42 independently corroborates the timeline and identifies the payload as a descendant of the same Miasma RAT deployed in the June 2026 Red Hat supply-chain operation (Unit 42, 2026-07-15).

The July Patch Tuesday entry covered the two KEV-listed exploited zero-days (AD FS CVE-2026-56155, SharePoint CVE-2026-56164). Four further high-severity fixes in the same cycle carry pre-auth risk and warrant separate attention. CVE-2026-55040 (CVSS 9.1, weak authentication) is a SharePoint JWT token-validation bypass that Rapid7's Stephen Fewer built into a two-vulnerability chain for Pwn2Own Berlin 2026: a remote unauthenticated attacker who knows a target's Active Directory SID or User Principal Name can forge identity and operate as that SharePoint user or administrator (Rapid7 Labs, 2026-07-14). Rapid7 chained it to a still-undisclosed RCE that Microsoft will not patch until the August 2026 cycle — but "patching CVE-2026-55040 will successfully break this exploit chain," so the July update is the available defense today even with the RCE half outstanding (Rapid7 Labs, 2026-07-14).

CVE-2026-55944 (CVSS 9.8) is an unauthenticated deserialization RCE in Microsoft Dynamics NAV / Dynamics 365 Business Central (on-premises) — "deserialization of untrusted data ... allows an unauthorized attacker to execute code over a network," triggered by a crafted login request before any session exists (vector AV:N/AC:L/PR:N/UI:N), and rated "Exploitation More Likely" (Microsoft MSRC, 2026-07-14). It is easy to overlook against SharePoint or Exchange in a busy Patch Tuesday, yet on-prem Dynamics back-office instances are frequently exposed. Two more SharePoint deserialization RCEs — CVE-2026-50522 and CVE-2026-58644 (both CVSS 9.8, "Exploitation More Likely") — require Site-Owner-level access per Microsoft's FAQ; CVE-2026-50522 is fixed in the July cumulative update, while CVE-2026-58644's patch actually shipped in the June cumulative update and the CVE was only documented on 14 July after being omitted from June's release notes — so a SharePoint estate patched through June is already covered for 58644 (Microsoft MSRC, 2026-07-14).

The 2026-07-15 entry carried CVE-2026-58644 as a CVSS 9.8 SharePoint deserialization RCE rated only "Exploitation More Likely," with its patch noted as having shipped in the June 2026 cumulative update. CISA has now confirmed it is being exploited in the wild: its SharePoint alert, updated 2026-07-16, states CISA "is aware of active exploitation of vulnerabilities CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, and CVE-2026-58644, enabling cyber threat actors to gain unauthorized access to on-premises SharePoint Server instances," and CISA added CVE-2026-58644 to the KEV catalog the same day (CISA, 2026-07-16). The alert describes the cluster's post-exploitation as stealing IIS machine keys — the ASP.NET view-state signing/encryption keys — and using deserialization techniques to gain persistence and deploy malware, so the machine key, not the single CVE, is the durable foothold once any of the four is exploited.

The July 2026 SharePoint patch cluster carried CVE-2026-50522, a deserialization-of-untrusted-data RCE that all sources had assessed as not-yet-exploited (Microsoft flagged only an "increased likelihood"). That changed on 2026-07-21: NCSC-NL updated advisory NCSC-2026-0237 to report, per watchTowr, that public exploit code for CVE-2026-50522 was published and the flaw is now actively exploited against on-premises SharePoint, with attackers stealing machine keys for long-term access (NCSC-NL, 2026-07-21).

watchTowr detailed the chain (relayed via BleepingComputer): a malicious .NET BinaryFormatter payload is delivered as the cookie of a forged SecurityContextToken in a WS-Federation sign-in response posted to SharePoint's /_trust/default.aspx endpoint; a successfully processed payload executes code and lets the attacker exfiltrate the server's machine keys, which are then used to forge valid ASP.NET authentication tokens/ViewState — giving persistent, re-authenticatable access that survives patching unless the keys are rotated (BleepingComputer, 2026-07-21). A PowerShell PoC (attributed by BleepingComputer to researcher "Janggggg") went public on 2026-07-20, and watchTowr's Attacker Eye honeypots captured successful compromises within hours (BleepingComputer, 2026-07-21); Security Affairs corroborates that the public PoC triggered active exploitation (Security Affairs, 2026-07-21). No authentication is required for the initial RCE.

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.

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.

The exploitation status flipped. CISA added CVE-2026-55040 to its Known Exploited Vulnerabilities catalog on 2026-08-18, describing it as a weak-authentication flaw that "allows an unauthorized attacker to bypass a security feature over a network" (CISA KEV catalog, 2026-08-18), ENISA's EU Vulnerability Database carries the same date and an EPSS of 3.97, mirroring that determination rather than independently confirming it (ENISA EUVD, 2026-08-18). The earlier entry carried this flaw as proof-of-concept-public on the strength of Rapid7's exploit being replayed against honeypots a day after publication — real exploitation attempts, but against sensors rather than estates. The federal catalogue now classes it as exploited outright, which is a stronger statement than honeypot telemetry even though it rests on one authority.

Microsoft's own record has not moved. It still records exploitation as no, and its published explanation of the impact remains that "the authentication feature could be bypassed as this vulnerability allows impersonation" (Microsoft Security Response Center, 2026-07-14) — the vendor rates the flaw Critical at CVSS 9.1 and does assess exploitation as more likely, which agrees with the catalogue's direction — what disagrees is the record's own exploited field, still set to no with no revision since 14 July. That is the second Microsoft CVE in this catalogue update whose exploited field contradicts the catalogue, and it is a reason not to let a vendor-scored feed be the only input to a SharePoint patch decision. (On the sibling IKE Extension flaw the vendor's exploitability assessment is the disagreeing field too; here only the exploited flag is.)

The reason this matters here more than the score suggests is the estate. Switzerland's federal IT provider BIT confirmed a SharePoint Server intrusion affecting around 200 federal user and technical accounts, and canton Graubünden disclosed its own SharePoint server breach a day later — both already covered here, and neither publicly tied to this identifier by any source. What the exploitation listing changes is the standing of an unpatched, internet-reachable farm: the honest reading is no longer "a proof-of-concept exists" but "this is being used", and a farm that sat exposed between the July patch and now warrants a look at its authentication records rather than an upgrade ticket alone.

Hunting concentrates on the impersonation outcome rather than the request that produced it, because a forged token is accepted by design once validation fails. In authentication and application telemetry, the signals are SharePoint access events whose asserted identity has no corresponding interactive sign-in from the same source within the session window, site-administrator-level operations from a client that never authenticated normally, and unauthenticated requests to token-handling endpoints immediately preceding privileged activity. Triage: federated and app-only access legitimately produce SharePoint operations with no interactive sign-in, so that pattern alone is normal in most tenants — the discriminators are whether the asserted principal is one that federation or a registered application is actually configured to assert, and whether the source address belongs to the estate's own service ranges. Patching is the remediation; there is no configuration workaround in the vendor's record.

The original entry recorded SonicWall's confirmation that CVE-2026-15409/-15410 were being exploited as zero-days and directed emergency patching. Volexity has now published the reconstructed intrusion, attributed it to an actor it tracks as UTA0533, and shown that patching alone is insufficient — the delta below is the full kill chain, the on-appliance implants, and the compromise-response guidance the terse advisory did not carry (Volexity, 2026-07-17).

Volexity was engaged after suspect authentication and lateral movement were seen originating from SonicWall SMA 1000 appliances (models 6210/7210/8200v); the earliest sign of compromise was 2026-06-22, weeks before SonicWall's 2026-07-14 disclosure (Volexity, 2026-07-17). SonicWall's PSIRT confirms it "has investigated multiple cases indicating the active exploitation of the vulnerabilities described in this advisory" (SonicWall SNWLID-2026-0008, 2026-07-14), and Rapid7's MDR team independently found the same two zero-days under attack (Rapid7, 2026-07-16).

Initial access (T1190, T1133). CVE-2026-15409 is a pre-authentication server-side request forgery in the SMA 1000 /wsproxy endpoint. A crafted WebSocket-upgrade request establishes a tunnel from the unauthenticated external attacker straight to services that are supposed to be reachable only on the appliance's own loopback — Volexity confirms "no valid SMA session cookie was required during this process" (Volexity, 2026-07-17). Through the tunnel the actor reached the appliance's bundled CouchDB/Erlang services and a localhost-only control service; the shipped CouchDB carries hardcoded admin:admin credentials, and the control service's authentication password is derivable from a device UUID, so the SSRF turns both into part of the external attack surface.

Privilege escalation (T1068). CVE-2026-15410 is a path traversal in the hotfix-rollback workflow: the sysCtrl.execRemoveHotfix operation builds a rollback path from caller-controlled input and hands it to /usr/local/bin/remove_hotfix, which then executes it. A rollback name containing directory-traversal sequences resolves outside the intended rollback directory and runs an attacker-staged script as root.

Persistence and implants (T1055, T1505.003, T1090.003, T1037.004). With root, UTA0533 dropped a setuid helper and a Python loader Volexity calls KNUCKLEBALL, which injects two JAR archives into the appliance's legitimate workplace process: the open-source Suo5 HTTP proxy-forwarder and a Behinder-like Java webshell Volexity calls ORANGETAIL. Persistence was established by adding a call to the loader inside the appliance's workplace init script, and the NGINX Unit configuration was rewritten to add routes that proxy attacker-chosen (arbitrary) request paths to the injected webshell and proxy — so hunting for a fixed URL is the wrong shape; the behaviour is unexpected route entries in the appliance's own reverse-proxy configuration.

Credential access and lateral movement (T1040, T1059). The actor ran tcpdump from a script staged in the appliance's temp directory to capture unencrypted LDAP traffic (TCP 389), harvesting directory credentials off the wire (Volexity, 2026-07-17). Rapid7's engagement observed the actor then "quickly shifted to lateral movement, pivoting from the compromised appliance directly into the internal corporate network" (Rapid7, 2026-07-16). How far that onward movement reached differs across the two IR firms' cases: Volexity concludes that in the appliances it investigated, "available evidence suggests the threat actor was less successful moving laterally or gaining access to other systems" (Volexity, 2026-07-17) — so treat a foothold on the appliance as a demonstrated launch point for internal movement, but not evidence that deep lateral movement always succeeds.

The earlier entry reconstructed UTA0533's appliance-to-network kill chain against SonicWall SMA 1000 and told readers to treat an exposed, unpatched appliance as compromised rather than merely vulnerable. That direction stands. Four things have moved since, and two of them change what "remediated" means.

Who is on the chain. Rapid7's director of vulnerability intelligence, Douglas McKee, told The Hacker News that "More recently, INC Ransomware has emerged as the dominant threat actor actively weaponizing this vulnerability chain", and that the technical correlation with the pre-disclosure cluster "indicates that a single threat actor or coordinated group is responsible for discovering and exploiting this zero-day vulnerability" (The Hacker News, 2026-08-03). Two limits belong with that quote. Rapid7 attributed this activity to INC Ransom on 2026-07-17, hours before this pipeline's 2026-07-18 entry, which did not carry it (Dark Reading, 2026-07-17) — so the actor link is seventeen days old and the new element is only the dominance characterisation. And the overlap claim is Rapid7's alone: Volexity, which named the UTA0533 cluster, has published no INC link, so the wider framing that both firms made that connection is not supported.

A patch you applied is not necessarily a patch that is running. This is the finding with the most operational consequence, and no prior entry here has carried it. Rapid7's director of incident response, Brett Deroche, describes containment succeeding in most engagements but not all: "We observed the threat actor maintaining persistence and rolling the newly applied patch back to a vulnerable state to maintain access. A comprehensive forensic review of the firewall is required to ensure complete eviction." A root-level attacker resident on the appliance can undo remediation, which means the standard verification — check the version, close the ticket — reports success on a box that is still owned. Resecurity's DFIR work reaches the same conclusion from the artifact side: "Setuid binaries, Python injectors, modified init scripts, and NGINX Unit configuration changes can survive reboots and may persist after a superficial firmware upgrade if not remediated. A patched appliance that still contains ROOTRUN or KNUCKLEBALL remains compromised" (Resecurity, 2026-08-01).

The rotation scope is wider than passwords and MFA seeds. Rapid7 reports that the attacks used the appliance foothold to extract high-value credentials, active session databases and TOTP multi-factor-authentication seed configurations (The Hacker News, 2026-08-03) — stolen session state and MFA seeds keep working after a password reset, which is why the rotation list matters more than it looks. The earlier entry told readers to reset account passwords and TOTP seeds. Resecurity's list of what the appliance processed or stored, and therefore what has to be replaced, extends to SMA administrator passwords, directory-service bind credentials for LDAP, RADIUS and Active Directory, user passwords for every account that authenticated during the exposure window, certificates and API keys configured on the appliance, and TOTP tokens and seeds. Bind credentials are the item most often missed, and they are the ones that grant standing directory access independent of the appliance. Where compromise is confirmed, Resecurity's guidance is to factory-reset, reimage on patched firmware and restore configuration from a backup pre-dating the vulnerable branches — a constraint SonicWall states independently in its own product notice, which limits usable backups to those predating 12.4.3-03245 and 12.5.0-02283 (SonicWall, 2026-07-14).

A new pressure layer at the extortion stage. Resecurity, which has run incident response for several victims, reports that "many of the new victims received emails, as well as phone calls from unknown organizations claiming to assist with ransomware issues", using infrastructure registered shortly after the intrusion. Whether this is the same operation or opportunists reading the leak site, the effect is the same: inbound offers of help with a ransomware problem the organisation has not made public are adversary contact, and the people receiving them are often outside the security team.

On victim geography, hold the claim loosely. Resecurity reports that INC's leak-site listings between 2026-07-17 and 2026-08-01 "include private sector and government organizations from Australia, the US, UAE, Colombia, Switzerland, and other countries", and SecurityWeek relays that INC "has emerged as the most active one" among actors chaining the two CVEs (SecurityWeek, 2026-08-03). No organisation is named, no victim or authority has confirmed any listing, and Resecurity does not state that any individual listing was reached through this exploit chain — the country list and the chain are separate claims in the same report. Treat it as an unverified criminal claim rather than evidence of a Swiss compromise.