Tuesday, 11 August 2026

One compromised contract-logistics processor put ten organisations into breach notification at once — CEVA Logistics, eight European warehouses, and a bank, a retailer and a games platform all learning from their supplier

CEVA Logistics — a contract-logistics operator that has been part of the French shipping group CMA CGM since 2019 (ICTMagazine.nl, 2026-08-10) — confirmed to affected customers on 1 August 2026 that a cyber intrusion was affecting part of its European contract-logistics operations, telling TechCrunch that its security teams activated protocols and opened an investigation that is still running, and that the operational impact was limited to eight warehouses, with no other CEVA systems globally affected (TechCrunch, 2026-08-10). That is the whole of what the compromised party has said publicly. Dutch trade reporting records that CEVA itself has given no public reaction of its own to these incidents (ICTMagazine.nl, 2026-08-10), and its spokesperson declined to answer whether the company knows how much personal data was taken or whether it has heard from the intruders at all, including on a ransom demand (TechCrunch, 2026-08-10).

The reason this is an entry rather than one more breach is arithmetic. CEVA processes fulfilment and shipping data for many unrelated clients, so one intrusion at one processor created independent notification duties at each of them simultaneously: the Dutch data-protection authority's spokesperson confirmed to TechCrunch that it has received breach reports from ten organisations in relation to this single incident. The named downstream parties span sectors that share nothing but a logistics contract — ING in banking, bol.com and De Bijenkorf in retail, the football club AFC Ajax, the eyewear retailer Ace & Tate, and Valve, which told customers it learned on 7 August that data was taken from CEVA's systems and alerted customers who had recently bought its Steam hardware, noting CEVA holds their shipping and delivery information for 90 days after an order (TechCrunch, 2026-08-10); Dutch trade reporting scopes those Steam buyers to Europe (ICTMagazine.nl, 2026-08-10).

bol.com's own notice is the most specific account any party has published. It records that it was informed on 1 August, that the incident involves two systems used for processing orders from one of its fulfilment centres, that no bol systems were affected, and that data of customers whose orders were processed via that location may have been viewed or copied (bol.com, 2026-08-06). It also records the containment sequence — the logistics partner moved to stop the unauthorised access and brought in external specialists, and bol proactively halted data exchange with it pending assurance that resuming is safe — and the part that is easy to miss in a data-breach framing: the affected location's stock was taken offline, goods could not be received there, and orders were cancelled or delayed while restoration ran longer than expected. This was an availability incident for the downstream businesses as well as a confidentiality one. Dutch trade reporting adds that CEVA isolated and took the affected systems offline, opened an external investigation and informed regulators (ICTMagazine.nl, 2026-08-10).

Two things are conspicuously absent and should stay that way in any internal write-up. No source identifies how CEVA's order-processing systems were reached — no vulnerability, no phishing, no credential theft, no malware family, no actor or extortion brand. And the provenance of data already circulating is disputed: Dutch reporting records that data taken from CEVA is being offered for sale on a criminal forum, while CEVA maintains that dataset is old data from an earlier 2025 breach (ICTMagazine.nl, 2026-08-10). Treating the material on offer as this incident's proceeds is therefore not supported, and neither is the converse — no independent party has adjudicated the dispute.

Belgium's eID signing extension handed any web page the card, the PIN and a drive-by RCE — an eIDAS Qualified Trust Service Provider's browser bridge that never checked the caller's origin

Connective is the browser extension plus native host that lets Belgian web services talk to the smart card in the reader — the national eID and Maestro payment cards — to authenticate users and produce eIDAS qualified electronic signatures, the tier that carries the same legal weight as a wet signature. Its vendor, Nitro Software Belgium, sits on the EU eIDAS Trusted List as a Qualified Trust Service Provider, the highest trust tier the regulation defines (Bay Area Labs, 2026-08-07). The researchers cite the vendor's own marketing for the deployment figures — "8 of the 10 largest banks in Belgium and 60+ Belgian government agencies and departments" — and say they independently confirmed the 2-million weekly-active-user count from the Chrome and Edge store listings; SecurityWeek, reporting the disclosure on 2026-08-10, put the affected population at roughly two million people (SecurityWeek, 2026-08-10).

The root defect is a missing trust boundary rather than a memory-safety bug: the extension forwards messages from web pages to the native host without telling the host which page sent them, so the component holding the card has no way to know who it is talking to (Bay Area Labs, 2026-08-07). The one gate that existed, an RSA-signed activationToken issued by partner sites, decodes to a UUID, a time-to-live and a feature bitmask — and carries no origin either, so any page can replay a token harvested from a legitimate site and reach every card command it enables. The researchers took theirs from a live Belgian service whose tokens allowed all operations with a 24-hour lifetime.

From there the second flaw hands over the secret the whole scheme rests on. When a user types their PIN into the native Connective dialog, the host returns a pinToken to the calling page — and the researchers found that token is a 48-byte blob containing both the ciphertext and the AES-128 key needed to decrypt it, alternating bytes of the first 32, with a hardcoded initialisation vector recovered from the binary; decrypting it yields the PIN digits plus an expiry (Bay Area Labs, 2026-08-07). Worse for the social-engineering step, the page controls the dialog's title and body text, so the prompt asking for the PIN can be made to read as an official identity confirmation while being driven by an advertisement in an invisible frame. With the PIN in hand the attacker can mint their own PIN tokens and keep using the card whenever it is in the reader. The researchers demonstrated an account takeover against a Belgian federal authentication portal on this path, and are explicit about what they did not test: they did not exercise the flow against the country's dominant identity app itself, and note there may be further steps involved.

The third flaw is the one the researchers call the most impactful. The reader-enumeration command accepts a library parameter naming a DLL to load, relative paths included, with the only constraint that the path contains .dll (Bay Area Labs, 2026-08-07). Because the browser blocks downloads with a bare .dll extension, they used a polyglot file whose name embeds the string inside an innocuous-looking document name, had the page download it automatically, and then walked a relative path from the extension's own directory under the user profile back into the downloads folder — arbitrary code execution at user privilege, out of the browser sandbox, from a page visit. They note there was nothing preventing it from spreading by stealing session material and messaging the link onward to other users of the same extension.

Remediation took 146 days from first report, and the interim state is the part worth studying: the first fix, on 2026-05-08, added a remote origin check, which the researchers point out meant only approved sites could still trigger the RCE or steal the PIN token; they told the vendor the same month that the library command was untouched and the PIN token was still reaching web pages. The complete fix landed on 2026-06-01 by disabling the library command and replacing the PIN token with a randomly generated identifier cached inside the extension, with the remote origin checks fully enforced from 2026-07-22 (Bay Area Labs, 2026-08-07). No CVE was assigned, and this run located no vendor advisory. The researchers also observe that the vendor advertises yearly penetration tests.

Triage: on an endpoint, the observable is a signing or smart-card native-messaging host process spawning or loading code that did not ship with it — in process-creation and image-load telemetry with parent lineage, a browser-installed helper under the user profile loading a library from a user-writable location such as the downloads directory, rather than from its own install path. Legitimate use of these bridges loads only the vendor's own modules and the platform smart-card libraries from fixed paths, so the discriminator is the load source, not the load itself.

UPDATE — CVE-2026-65400 is remote root, not just an auth bypass: two independent pre-auth bugs sat in screensharingd, working exploits were rebuilt from the patch in four hours, and the two research accounts disagree on which mechanism the CVE names

UPDATE · originally covered CVE-2026-65400 — macOS Screen Sharing lets a network attacker authenticate without valid credentials, the second severe defect in the same daemon in two releases (2026-08-08)

the original entry carried Apple's own framing — an attacker on the network may be able to authenticate to Screen Sharing without valid credentials, no exploitation reported — and treated it as an authentication bypass. Three things published since change what a defender should do about it.

It is remote root, and the exploit is a weekend's work. Calif pulled the 26.6 and 26.6.1 binaries, diffed them, and had a working exploit against a live 26.6 machine about four hours later (Calif, 2026-08-10). The severity is higher than the advisory line implies because screensharingd, the daemon answering those connections, runs as root — so an attacker does not land in the account they authenticated as, but can reach every account on the machine and install what they like. Huntress, analysing the same patch independently, describes the result as arbitrary file read and write as root, reached through the daemon's privileged file-copy helper processes, and reports achieving code execution by creating a launch daemon that runs an on-disk reverse shell at reboot or by modifying a shell startup file that fires when a terminal is opened (Huntress, 2026-08-07). Huntress also notes that an earlier public proof-of-concept's cron-based path did not work as implemented, because the cron location it wrote to is protected, and that its author later scoped that path to systems with System Integrity Protection disabled — a narrower reading than the original entry's more hopeful gloss on the protection question, since the launch-daemon and shell-startup paths are not covered by it.

There were two pre-auth bugs, not one, and only one got a CVE. Calif reports that screensharingd carried two independent critical flaws sitting in the same source file. The first was found by the researcher fG! (@osxreverser), never reported to Apple, and killed by Apple in the 26.6 release of 2026-07-27 alongside less severe reported bugs; it has no CVE to this day, and none of the three Screen Sharing entries in that July advisory was described as pre-authentication (Calif, 2026-08-10). Calif characterises that first bug as a single wrong return — a length check bailing out early on an oversized frame and handing back the success code from the preceding read, which the caller reads as an authentication step having passed. The second bug is CVE-2026-65400, fixed out of band on 2026-08-06, and Calif states it needs one thing the first did not: a valid account name, which is not a secret because macOS prints usernames on the login window. Both, in Calif's account, are pure logic errors: no heap grooming, no address-space defeat, no race to win, and no crash — one or two packets in the right order.

The two accounts of the root cause do not agree, and the difference is worth knowing. Huntress roots CVE-2026-65400 in the Secure Remote Password implementation, stating that the daemon's frame-length validator erroneously returns a stale success status so the connection is treated as authenticated, and that the session then continues without cryptographic protection (Huntress, 2026-08-07). Calif assigns that same stale-return mechanism to the first, uncredited bug, and says CVE-2026-65400 is instead a state-machine desync whose details it is withholding until more machines have updated (Calif, 2026-08-10). This entry does not adjudicate between them. The practical consequence of the disagreement is a defensive one: a reader who has only seen the Huntress write-up may conclude the mechanism is fully public, when the more granular account says the mechanism behind the CVE that is actually patched this month has not been published.

Exposure. Calif cites the scan by the researcher who started the affair, which found around 40,000 Macs with Screen Sharing reachable from the internet — mostly residential addresses, but including university and company hosts (Calif, 2026-08-10). Huntress reports a separate concern for managed estates: providers of hosted bare-metal Macs commonly provision these services enabled, a search of internet-wide scan data shows tens of thousands of potentially vulnerable hosts, and at the time of writing some providers had not folded the latest updates into their base images, so newly provisioned hosts were still coming up on the previous, vulnerable version (Huntress, 2026-08-07).

Detection. Huntress's contribution the original entry lacked is a telemetry-level discriminator drawn from Apple's Endpoint Security event stream. On a screen-sharing attach event, a legitimate authenticated session reports its authentication type as RSA-SRP, while a session established through this bug reports the weaker SRP value, because no cryptography is applied to it. The session username is the second signal: root is a strong indicator, since that account is disabled by default on macOS and few administrators would enable it and then use it for Screen Sharing, and an attacker guessing at account names produces attach events with a null session username — noisy enumeration that is itself worth alerting on. At the process layer, execution of the daemon's file-copy sender helper with a user and group identifier of 0 and 80 accompanies information-disclosure attempts, though Huntress notes those values do not stay static once the attacker enumerates another local account.

Triage: Screen Sharing is a real administrative tool, so the session itself is not the signal — the authentication type is. Any successful screen-sharing attach whose authentication type is the unencrypted variant, or whose session username is root or null, has no benign explanation on a managed Mac; an ordinary remote-support session by an administrator authenticates over the encrypted path as a named account. Where that telemetry is unavailable, the fallback discriminator is exposure rather than behaviour: a Screen Sharing listener answering from an untrusted network at all is the condition this bug needs.

Gunra ransomware-as-a-service: a joint six-agency advisory documents FortiOS edge exploitation, a persistent MFA backdoor built from one fixed OTP value, and a Linux encryptor whose keys can be reconstructed

Six authorities — the FBI, CISA, the Department of Defense Cyber Crime Center, the NSA, the US Secret Service and the Republic of Korea's National Police Agency — published a joint #StopRansomware advisory on Gunra on 2026-08-10 (CISA et al., 2026-08-10). Gunra first appeared in April 2025 and is, in the authoring agencies' assessment, based on or significantly influenced by the Conti source code leaked in 2022; as of January 2026 it runs a structured affiliate programme advertised on criminal forums, supplying a management panel, a configurable builder, cross-platform lockers and affiliate documentation, and the FBI records the group also operating under the name Golden Community and recruiting penetration testers as initial-access brokers (CISA et al., 2026-08-10). The victim set on the group's leak site spans the Americas, Europe, the Middle East, Africa and Asia-Pacific, and the advisory names government services and facilities, utilities, healthcare, financial services, critical manufacturing and transport among the affected sectors — which is why this reads directly onto the European public-sector and critical-infrastructure estate, not only onto its Korean and American case studies.

Initial access is the edge appliance. The FBI observed Gunra obtaining access primarily by exploiting known vulnerabilities in internet-facing firewall and VPN appliances, specifically the FortiOS and FortiProxy authentication-bypass flaws CVE-2024-55591 and CVE-2025-24472, both CWE-288 (CISA et al., 2026-08-10). The advisory points at the CVE records rather than restating affected versions, and it is explicit about what the exploitation buys: those two flaws let an actor abuse scheduled tasks on a vulnerable FortiOS firewall to create a new persistent super-user account named forticloud-sync carrying a hard-coded password (CISA et al., 2026-08-10). That account name is the cheapest hunt in this advisory: an appliance administrator enumeration that finds it has found an intrusion, and finding it after patching means the patch did not evict anyone. Separately, KNPA observed initial access through credential-exposure and SSH access-control weaknesses on internet-facing VPN gateways, and in one case through an SSL-VPN administrator account reachable with default credentials because no account-lockout control was configured.

The identity plane is where the intrusion becomes durable. After taking a network administrator's workstation and the SSL-VPN administrative console, the actors located an unused account with reach into both the internet-facing and internal networks and modified its configuration to bypass the mandatory password-change requirement, then used it (CISA et al., 2026-08-10). Against one victim they manipulated the traffic-control functionality of the SSL-VPN appliance itself to collect the credentials and session material users were sending to a corporate VDI authentication portal, then replayed the captured session cookies to impersonate legitimate users. Against the same victim they went one step further and edited the authentication-processing files on that VDI authentication portal server so that a specific attacker-chosen one-time-password value would always authenticate successfully — a standing MFA bypass rather than a stolen token. Credential access elsewhere is conventional but thorough: secretsdump.py against domain controllers to pull hashes out of NTDS for pass-the-hash and pass-the-ticket movement, psexec.py and smbclient.py over SMB for lateral movement, RDP into the VDI estate, and in one case theft of a symmetric key from a system access-control server that decrypted the stored passwords for every enterprise server account.

Behavioural shape, in telemetry terms. The operators work deliberately unsociable hours — the advisory records reconnaissance and internal activity concentrated between 22:00 and 06:00 to avoid administrator attention — and clear system and network access logs and shell command history behind them (CISA et al., 2026-08-10). Collection and exfiltration precede encryption: business documents, databases, personal data and internal mail are staged, a purpose-built executable pulls data out of Microsoft OneDrive and SharePoint, and for at least one victim compressed archives running to tens of terabytes went to a consumer file-sharing service, with 7-Zip, RClone and FileZilla among the tools observed on the group's own infrastructure. Recovery is attacked directly: volume shadow copies are deleted through WMI from a command shell before encryption, and against one victim backup and archive data was deleted at both the primary data centre and the disaster-recovery site, before and after deployment. The encryptor itself enumerates every drive letter through the native file-enumeration APIs, skips system directories and system-critical file extensions so the host stays bootable and the ransom note stays readable, checks for a debugger, and encrypts the surviving user data multi-threaded with ChaCha20 and RSA-4096, appending .ENCRT. Ransom notes land per directory and route victims to a Tor negotiation portal and an encrypted messenger with a five-to-seven-day clock.

The one piece of genuinely good news is a cryptographic mistake. The advisory records that as of March 2026 researchers identified a weakness in the Linux ELF variants, which append .GNRA: the encryption keys come from a weak pseudo-random generator seeded with the predictable srand(time(NULL)), and defenders may use that to mathematically reconstruct the keys from file timestamps and recover files without paying (CISA et al., 2026-08-10; original research at Breakglass Intelligence, 2026-03-12). This has an operational consequence that cuts against normal incident-response reflex: the advisory's own instruction, for a Gunra Linux incident where encryption has happened, is to preserve the encrypted files, their timestamps, the ransom notes and the system logs — because a rebuild-from-backup-and-move-on response throws away the timestamps the key reconstruction depends on. No such weakness is recorded for the Windows encryptor.

Detection concepts. Three of this actor's behaviours produce durable, vendor-neutral signal. In edge-appliance administrative logs and configuration audit trails, surface any newly created administrative or super-user account and any change that clears a mandatory-password-change flag on a dormant account — both are the advisory's stated persistence steps, and both are visible in configuration state rather than in transient telemetry. In authentication-server change control, file-integrity monitoring over the authentication-processing components of VDI, SSL-VPN and SSO portals is the only control that sees the OTP backdoor at all; it produces no failed logins, no impossible travel and no anomalous token, because from the portal's point of view the authentication genuinely succeeded. In endpoint process telemetry with parent lineage, the shadow-copy deletion is a command shell invoking the WMI command-line utility with a shadowcopy delete operation, and the credential-dumping and lateral-movement steps present as the Impacket family's characteristic service-creation-over-SMB and NTDS access patterns on domain controllers.

Triage: the tooling here is deliberately dual-use — remote-access and archiving utilities that administrators run legitimately every day — so presence alone is not the signal and the advisory says as much. The discriminators are contextual: the same remote-access agent installed on a host that has no help-desk ticket behind it, an archiving utility writing multi-gigabyte archives on a file server at 03:00, an account whose password-change requirement was cleared without a change record, and — the sharpest one — a successful multi-factor authentication in which the presented one-time-password value is identical across sessions or across users. Legitimate one-time codes never repeat; that is the whole property they exist for.