Tuesday, 18 August 2026

Arbeiterkammer Oberösterreich cannot scope its own breach because the attackers wiped the traces — so every member is being notified under Article 34 as a precaution

The Arbeiterkammer Oberösterreich — the Upper Austrian Chamber of Labour, which holds personal data on its membership — published a member notice on 2026-08-16 disclosing that unknown perpetrators gained access to parts of its IT systems on Monday 2026-08-10 (Arbeiterkammer Oberösterreich, 2026-08-16). It notified police, filed a criminal complaint and informed the Austrian data protection authority, and states that "Die gesamte Daten- und IT-Infrastruktur wurde unverzüglich in eine abgeschottete Umgebung transferiert" — the entire data and IT infrastructure was immediately transferred into a segregated environment. The APA wire carried the disclosure the following day (news.at, 2026-08-17).

The finding worth carrying is not the intrusion but what the organisation says it can no longer do. On current knowledge the attackers did reach data; the extent "kann aufgrund gezielter Spurenverwischung durch die Täter derzeit nicht festgestellt werden" — cannot currently be established because of deliberate trace removal by the perpetrators — "auch nicht, ob und welche personenbezogenen Mitgliederdaten konkret betroffen sind", nor whether and which members' personal data were specifically affected. The anti-forensic work did not hide the intrusion, which was detected; it destroyed the evidence needed to bound it.

That has a direct regulatory consequence, and it is the transferable part. Unable to determine who was affected, the chamber is proceeding on the assumption that all data it holds could be affected, and every member receives an individual letter by post under Article 34 GDPR. A control that would normally produce a scoped notification to an identified population instead produces a blanket one — with the cost, the alarm and the downstream fraud exposure that implies. The chamber is explicit about the last of those: it warns members to expect SMS, WhatsApp messages and emails purporting to come from it, particularly about payments or prize winnings, states that these are not from the chamber, and tells members never to disclose data authorising their bank details. Attackers routinely follow a publicised breach notification with themed phishing, and here the victim has had to tell its entire membership to expect exactly that.

Zurich District Court opens the LockerGoga / MegaCortex / Nefilim trial: four named Swiss victims, CHF 100m+ in damage, and an indictment that describes the intrusion pattern step by step

A 52-year-old Ukrainian software developer, resident in canton Basel-Landschaft and in custody since October 2021, appeared before Zurich District Court on 2026-08-17 charged with commercial extortion, multiple counts of serious data corruption, serious money laundering and possession of child pornography (cash.ch, 2026-08-17). The charge sheet covers attacks between December 2018 and May 2020 involving the ransomware families LockerGoga, MegaCortex and Nefilim (Netzwoche, 2026-08-17); the proceedings were triggered by a series of ransomware attacks on Zurich-area companies from July 2019. Per the indictment as reported by cash.ch, the defendant developed LockerGoga largely independently on the instruction of a co-accused in Moscow, later contributed to MegaCortex, and took a leading role as project manager on a further tool (cash.ch, 2026-08-17). The prosecution seeks twelve years' imprisonment and a twelve-year entry ban (cash.ch, 2026-08-17).

The indictment lists ten companies, four of them Swiss: Meier Tobler, Crealogix, IHI Ionbond and Stadler Rail (20 Minuten, 2026-08-17). Netzwoche reports the defendant is alleged to have taken part, from his residence in Switzerland, in attacks on ten companies in Switzerland, France, Norway, Scotland, Canada, the Netherlands and the United States (Netzwoche, 2026-08-17). Three victims, none Swiss, paid ransoms totalling CHF 4.5 million; the Swiss companies paid nothing (20 Minuten, 2026-08-17). Netzwoche reports the same proceedings differently, putting the single largest payment at 450 bitcoin, which it values at roughly CHF 41 million at today's rate (Netzwoche, 2026-08-17). The two franc figures are not measuring the same thing: one is what was paid at the time, the other is what that bitcoin is worth now, and neither outlet reconciles them. Prosecutors put the economic damage above CHF 100 million, from business interruptions, delivery delays, work stoppages and the special measures the companies had to mount (20 Minuten, 2026-08-17); Netzwoche reports the prosecution figure as above CHF 130 million, arising mainly from revenue lost to business interruption and the cost of restoring IT systems (Netzwoche, 2026-08-17). Per the indictment as reported by 20 Minuten, the defendant joined with a Ukrainian principal based in Moscow in June 2018, and that principal is alleged to have operated under a cover identity of Russia's FSB — an allegation the prosecution makes in a trial the defendant contests, and one no investigating authority has published independently.

What the charge sheet describes operationally. Unusually for court reporting, the intrusion pattern is spelled out: "Sie verschafften sich Zugang zu den Systemen, schalteten Überwachungsprozesse ab und verschlüsselten anschliessend Server sowie Arbeitsplatzrechner" — they obtained access to the systems, switched off monitoring processes, and then encrypted servers as well as workstations (cash.ch, 2026-08-17). 20 Minuten records the group's stated objective as penetrating as many company networks as possible in Western Europe and North America and encrypting "die Daten inklusive Back-up-Dateien" — the data including the backup files (20 Minuten, 2026-08-17). At Stadler Rail the defendant is additionally accused of taking around 500 gigabytes of confidential data and threatening to publish it to increase pressure (cash.ch, 2026-08-17) — double extortion, inside a charged period Netzwoche reports as December 2018 to May 2020 (Netzwoche, 2026-08-17); no cited source dates that exfiltration more precisely than the period as a whole. The extortion notes claimed the data was encrypted with military-grade algorithms and that any third-party recovery attempt would destroy it (20 Minuten, 2026-08-17) — a pressure device rather than a technical fact.

Detection, telemetry class first. Nothing here is a new technique, and the value is not novelty: it is that a court record independently corroborates the ordering that ransomware detection is built around. Defence-impairment precedes encryption, so the telemetry that matters arrives before any file changes — security service and agent stop or configuration-change events, sudden gaps in endpoint agent check-ins across multiple hosts, and audit or logging services terminating outside a maintenance window. Backup infrastructure is a target in the same operation rather than a recovery path afterwards, so authentication and deletion activity against backup catalogues and repositories belongs in the same alerting tier as domain controllers. Triage: legitimate maintenance also stops security agents and touches backup stores — the discriminators are that maintenance is scoped to a change window and a host set, is performed by accounts that routinely do it, and does not spread to servers and workstations at once; a monitoring-process stop that fans out across both populations within a short window, from an account with no history of that action, is the sequence worth waking someone for.

CVE-2025-62593 — Ray's dashboard is defended against browsers by a User-Agent string check, and CISA now records the DNS-rebinding bypass as exploited

CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog on 2026-08-17, describing it as a code-injection flaw in Ray and noting that "Developers using Ray as a development tool may be exposed to this vulnerability exploitable through Firefox and Safari" (CISA KEV, catalogue version 2026.08.17). The underlying advisory is not new — the Ray project published it on 2025-11-26 — but the exploitation determination is, and it changes the flaw's standing from a documented design weakness to something being used.

The design decision behind it is stated plainly by the project: Ray's dashboard exposes job-submission endpoints, including /api/jobs and /api/job_agent/jobs/, without authentication, and the guard against browser-originated requests is a heuristic on the User-Agent header. As the advisory puts it, "This vulnerability is due to an insufficient guard against browser-based attacks, as the current defense uses the User-Agent header starting with the string 'Mozilla' as a defense mechanism" (Ray project, 2025-11-26). That assumption holds only where the browser refuses to let a page set the header. Firefox and Safari implement the fetch specification and permit it; Chrome does not, which the advisory notes is the result of a long-standing bug that puts Chrome out of spec — so the browser most likely to be non-compliant is the one that happens to be safe.

The reason this reaches hosts that no firewall would consider exposed is DNS rebinding. The attacker does not need network reach to the Ray dashboard; the victim's browser has it. A developer running Ray locally who visits a malicious page — or is served a malicious advertisement, which the advisory calls out explicitly — gives that page a path to resolve an attacker-controlled hostname to a loopback or internal address, overwrite the User-Agent, and POST a job to the dashboard, which executes it. The advisory further states the same browser-as-intermediary path can be turned against network-adjacent Ray instances, so a single developer workstation reaches cluster nodes that were never meant to be addressable from outside. The fix is Ray 2.52.0, which the project notes also, finally, adds an authentication feature — one that is disabled by default, so upgrading alone leaves the endpoints open to anything that can already reach them.

Detection, telemetry class first. The observable sequence is a browser process making a local or internal HTTP request it has no business making. In DNS and resolver telemetry, the rebinding step is a hostname whose answer changes to a loopback or RFC 1918 address within a short TTL window on a host that has just browsed externally — the classic signature, and the one that fires before anything reaches Ray. In the Ray dashboard's own access logs, the anchor is a POST to the job-submission endpoints carrying an Origin or Referer that names an external site rather than local tooling. In host process and network telemetry, correlate an outbound browser session with a subsequent connection to the dashboard port (8265 by default) from that same browser process, and then with Ray spawning a job-worker process tree that no scheduler or CLI invocation accounts for. Triage: legitimate dashboard traffic comes from the Ray CLI, a notebook kernel or an IDE extension — local, non-browser processes with no cross-origin headers, and job submissions that correlate with a developer's own session. Browser-originated POSTs to those endpoints have no benign equivalent, and the DNS answer that recently pointed elsewhere is the corroborating half.

UPDATE — GeoServer's actively exploited jsonArrayContains SQL injection now has a fix, a published root cause and a service-dependent exploitation path: WFS 1.0 reaches top-level SQL, WFS 2.0 does not

UPDATE · originally covered GeoServer: an unauthenticated SQL injection in the jsonArrayContains filter is being exploited with no CVE and no patch — and NCSC-CH has put it in front of Swiss operators (2026-08-15)

the flaw this pipeline described as exploited with no vendor fix — where the only advice available was exposure reduction — has been patched, and the patch arrived with enough published detail to change how an operator scopes the exposure. GeoServer released 3.0.1, 2.28.5 and 2.27.6 on 2026-08-14, each bundling the corresponding GeoTools fix, and the project calls the release "an urgent update for production systems" (GeoServer project, 2026-08-14). Switzerland's NCSC appended the fixed versions to its own advisory on 2026-08-17, while still recording the exploitation status as "Actively Exploited, Proof of Concept Available" (NCSC-CH, 2026-08-17). The advisory is tracked as GHSA-mqjf-5f49-2fjh; GeoTools scopes the affected package to org.geotools:gt-jdbc-postgis versions 35.0, ≥34.0 and ≥33.1, fixed in 35.1, 34.5 and 33.6 (GeoTools, 2026-08-15). No CVE identifier exists yet, so this remains invisible to a purely CVE-driven patch process.

The mechanism, now public. GeoServer hands CQL-to-SQL translation to GeoTools, and the jsonArrayContains filter function builds its SQL by formatting the attacker-supplied value straight into a PostgreSQL jsonb_path_exists() jsonpath expression: "The value comes directly from the CQL filter, which comes directly from the HTTP request. It is dropped into a SQL string literal with no escaping" (Hadrian, 2026-08-14). Every other GeoTools filter function uses parameterised queries; this one does not, because PostgreSQL does not accept bind parameters inside a jsonpath expression, so the function was written with string formatting instead. The reachable surface is the CQL_FILTER parameter of the public OGC WMS and WFS endpoints, which accept unauthenticated input by design, against any PostGIS-backed layer that "requires a Text or JSON column; affects PostGIS 12 and up" (GeoServer project, 2026-08-14). GeoTools describes the flaw as a regression of CVE-2023-25158 confined to this single function.

Why the service version decides the outcome. The escalation from arbitrary SQL to arbitrary commands turns on the shape of the query GeoServer generates, which differs per service. WFS 2.0 has to populate numberMatched, so it wraps the filter in a derived-table count query and a semicolon in the injected value never escapes the wrapper. WFS 1.0 carries no numberMatched in its response schema, so no wrapper is generated: "WFS 1.0 provides a path where a stacked PostgreSQL statement executes at the top level of the query" (Hadrian, 2026-08-14). Where the stacked statement lands and the PostgreSQL role holds superuser or pg_execute_server_program, COPY ... TO PROGRAM executes a command on the database host — Hadrian confirmed this against a lab deployment, with the command running as the postgres account. WMS GetMap is also exploitable but needs a geometry column and more parenthesis closure. The JDBC setting operators reach for first is not a control: "Exploitation does not require preferQueryMode=simple on the JDBC connection. Default pgJDBC configuration is sufficient" — the driver splits semicolon-separated SQL and executes each sub-statement even in extended mode.

What a locked-down database role does and does not buy. Removing superuser and pg_execute_server_program removes the command-execution path, and nothing else: "A restricted PostgreSQL account reduces the impact. It does not remove the injection" (Hadrian, 2026-08-14). Two extraction routes survive it — an error-based route that casts an expression to an integer so PostgreSQL leaks the result inside its type error, which works through both WFS and WMS with no special JDBC settings, and a time-based blind route through a subquery, which works even where prepared statements are enabled precisely because a subquery is not a stacked statement. Anything the GeoServer database user can read is therefore reachable, including credentials and connection strings held in other tables. On whether any configuration change helps, the vendor advisory and the reversing analysis disagree, and the disagreement is worth stating plainly rather than resolving. GeoTools says no mitigation is available, and specifically that the CVE-2023-25158 mitigation of enabling prepared statements and disabling encode functions is not effective (GeoTools, 2026-08-15). Hadrian's remediation guidance says the opposite of one half of that pairing: "Disabling the encode functions option on the PostGIS datastore prevents jsonArrayContains from being translated into the vulnerable SQL form" (Hadrian, 2026-08-14). The two are not quite addressing the same thing — the advisory rates the 2023 pairing as a whole, the analysis isolates one setting — but an operator who cannot patch this week has one source telling them a switch closes the path and the vendor telling them it does not. Treat it as unproven and not a substitute for the upgrade: it is worth setting where the estate can tolerate it, and worth verifying against your own deployment rather than trusting either statement.

Detection, telemetry class first. In web and reverse-proxy access logs, the anchor is an unauthenticated WMS or WFS request whose CQL_FILTER parameter invokes jsonArrayContains, with the WFS 1.0 service version the one that matters most because it is the version that reaches top-level SQL. In application logs, a JDBC driver error reporting that multiple result sets were returned by the query is a by-product of a stacked statement having executed, not a parsing failure — it is a post-exploitation signal, not a probe. In database audit telemetry (PostgreSQL statement logging or pgAudit), the signals are a COPY ... TO PROGRAM invocation from the GeoServer service role, malformed jsonpath arguments to jsonb_path_exists(), repeated integer-cast type errors from the same client session, and pg_sleep inside a subquery. Triage: legitimate GIS clients do call jsonArrayContains, so the function name alone is not the signal — the discriminators are quote and semicolon characters inside the value argument, the same client session producing a run of type-conversion errors against a layer it otherwise reads cleanly, and a shift of that client's traffic onto the WFS 1.0 endpoint when the rest of the estate's tooling speaks WFS 2.0.

UPDATE — Microsoft has acknowledged ShieldBreak and assigned CVE-2026-69414, rating the Defender privilege-escalation bypass 'Exploitation More Likely' with no update yet available

UPDATE · originally covered ShieldBreak — a public proof-of-concept defeats Microsoft's July fix for the RoguePlanet Defender flaw, claims 100% reliability where the original was a coin flip, and now covers Windows Server 2025 (2026-08-12)

the original entry recorded that no patch existed, no vendor had publicly reproduced the ShieldBreak proof-of-concept, and Microsoft had not commented. Two of those three have changed. Microsoft published an advisory on 2026-08-14 that names the technique directly — the vulnerability is described as an elevation of privilege in the Microsoft Malware Protection Engine in Microsoft Defender publicly referred to as "ShieldBreak" — and assigned it CVE-2026-69414 (Microsoft, 2026-08-14). The third has not: on the fix, Microsoft states only that "We are working to provide a high quality security update that addresses this vulnerability."

The vendor's own calibration is the useful part of the delta. Microsoft rates the flaw Important with a CVSS 3.1 base score of 7.8 for a local, low-privilege, no-interaction elevation, records it as publicly disclosed, records exploitation as not detected, and sets its exploitability assessment to "Exploitation More Likely" (Microsoft, 2026-08-14). That combination — publicly available exploit code, a vendor expectation of exploitation, and no update — is the shape that justifies attention outside the normal patch cycle, and it is a materially different footing from a researcher's unverified GitHub claim.

The relay is what brought it into this constituency's field of view. Switzerland's NCSC amended its rolling Nightmare Eclipse advisory on 2026-08-17 to record that "ShieldBreak is tracked as CVE-2026-69414 by Microsoft" (NCSC-CH, 2026-08-17), and CERT-FR issued advisory CERTFR-2026-AVI-1035 the same day, listing the Microsoft Malware Protection Engine among affected systems alongside an unrelated, already-patched PowerShell flaw (CERT-FR, 2026-08-17). CERT-FR's bulletin carries its standard instruction to consult the vendor advisory for fixes; for this CVE that advisory has none to offer, which is worth knowing before an operator treats the bulletin as a patchable item.

Detection, telemetry class first. No new behavioural detail was published with the CVE, so nothing here supersedes what the original entry carried. The durable anchor remains process-creation telemetry with parent lineage: the Malware Protection Engine has no legitimate reason to be the parent of an interactive shell or an unexpected child process, so any such process tree rooted at the engine is the signal irrespective of which variant produced it. Triage: the engine's own remediation work — quarantine, deletion, signature updates — runs inside the service rather than by launching command interpreters, so a shell parented to it does not have a benign counterpart; the discriminator is the parent-child relationship itself, not the child's command line.