EDPB Coordinated Enforcement Framework 2026 — 25 DPAs target GDPR Articles 12-14 transparency obligations

NCSC Switzerland's Week 23 report (9 June) documents three concurrent technique chains aimed at job seekers in Switzerland (NCSC-CH, 2026-06-09). The first sends fake interview-confirmation emails for plausible Swiss employers, linking to a counterfeit Google login that harvests credentials (T1566.002, T1078). The second uses fraudulent job offers demanding identity documents for "onboarding," with stolen Swiss IDs then used to order goods and run parcel-reshipping (freight-forwarder) fraud. The third operates through compromised LinkedIn recruiter profiles that direct candidates to download a "technical assessment" or "onboarding" GitHub repository carrying infostealer malware that targets crypto wallets, browser cookies and saved credentials (T1566.003, T1059.001, T1555). NCSC notes attackers systematically exploit applicants' urgency and unfamiliarity with new-employer processes to lower vigilance.

Why it matters to us: the LinkedIn→GitHub chain is a credible vector into corporate endpoints via employees in job-search mode and HR/talent teams handling external candidate code. Detection signal: git clone / GitHub downloads followed by script execution minutes after a LinkedIn contact (Sysmon EID 1, parent git.exe / python.exe from a freshly-cloned path). This is a national-CERT primary disclosure for its own jurisdiction.

Twenty-five data-protection authorities across the EEA simultaneously launched investigations examining compliance with GDPR Articles 12–14 (transparency and information obligations) as CEF 2026. Investigations focus on how organisations communicate data-collection, use, and sharing practices to data subjects — including the specificity required on third-country transfers, retention periods, and automated decision-making. Swiss public-sector entities operating under the revised Data Protection Act (revDSG, in force September 2023) face parallel expectations since Swiss DPA enforcement also focuses on transparency obligations. Enforcement decisions from CEF 2026 are expected in the second half of 2026 and could establish EU-wide precedent on the required granularity of privacy notices — particularly regarding identification of individual third countries for data transfers and naming of each algorithmic profiling system where Article 13(2)(f) automated-decision disclosure applies (EDPB news; ComplianceHub.Wiki analysis).

W19 status-update: the CEF 2026 launch was previewed in the W19 weekly; this W20 update reflects the operational live-investigation status across the 25 DPAs and adds the H2-2026 decision-timeline expectation.

On 19 March 2026 the European Data Protection Board launched its annual Coordinated Enforcement Framework (CEF) action, with 25 participating DPAs across Europe examining compliance with GDPR Articles 12, 13, and 14 — the transparency and information obligations requiring controllers to clearly disclose what data is processed, on what legal basis, and for what purposes. Unlike prior CEF years (right of access 2024, right to erasure 2025), transparency obligations are broadly applicable to every data-processing controller in every sector, making this year's sweep unusually wide (EDPB, 2026-03-19). Participating DPAs include Austria, Denmark, Germany (Brandenburg, Niedersachsen), Finland, France, Greece, Spain, Italy, Malta, Slovenia, Slovakia. Each DPA may conduct either formal enforcement actions or lighter-touch fact-finding exercises; findings consolidated into an aggregated EDPB report in H2 2026. What defenders need to do differently: audit privacy notices — website cookie banners, HR processing notices, CCTV notices, AI-generated data notices — against the Articles 12–14 checklist; given the EU's 2026 AI Act obligations also arriving in August, transparency failures in AI-generated personal-data processing are likely to attract enforcement attention. CEF findings frequently trigger follow-on national investigations at DPAs that identify outliers. Single-source national-CERT carve-out applies (EDPB is the primary disclosing authority for its own programme).

UPDATE (originally covered 2026-05-09): Microsoft Threat Intelligence published Active attack: Dirty Frag Linux vulnerability expands post-compromise risk on 2026-05-08 reporting "limited in-the-wild activity where privilege escalation involving su is observed." The attack chain observed: SSH initial access → shell spawn → execution of an ELF binary that triggers the LPE primitive in either CVE-2026-43284 (xfrm-ESP page-cache write) or CVE-2026-43500 (RxRPC page-cache write). This is the first formal "exploited in the wild" attribution since the V4bel write-up published on 2026-05-07.

Red Hat published RHSB-2026-003 covering both CVEs on 2026-05-07 and updated it on 2026-05-09, with backported errata rolling out to RHEL 8/9/10 and OpenShift 4 (Red Hat RHSB-2026-003). NCSC.ch issued Security Hub post 12547 on 2026-05-08 noting "Proof of Concept Available" and advising temporary blacklisting of the esp4, esp6 and rxrpc kernel modules pending distribution backports. Belgium's CCB issued a parallel advisory (CCB Belgium, 2026-05-08).

The upstream xfrm-ESP fix merged on 2026-05-07 (kernel commit referenced by V4bel and corroborated by Red Hat); the RxRPC fix was still pending in the netdev tree at time of writing. AlmaLinux backported kernels on 2026-05-08; Ubuntu noted fixes will arrive via the kernel image package. Defender hunt focus: outbound SSH-to-unprivileged-shell-to-ELF-execution chains immediately followed by setuid(0) or su invocations, plus suspicious setsockopt(AF_ALG) patterns on the esp4/esp6/rxrpc modules followed by splice() syscalls into the page cache of read-only files. The Microsoft post emphasises that the page-cache write primitive bypasses on-disk file integrity monitoring (AIDE / IMA-EVM / auditd watch rules) — post-incident forensics must compare in-memory page contents against on-disk checksums, not just md5sum of the file.

Mitigation note (carried from 2026-05-09): on Ubuntu where unprivileged user namespaces are blocked by default, the esp4/esp6 path is harder to reach because CAP_NET_ADMIN is required — but the RxRPC path remains exploitable without user-namespaces; the two CVEs are designed to complement each other. Where IPsec is in use, Red Hat suggests kernel.unprivileged_userns_clone=0 (sysctl) as a less disruptive mitigation than full esp4/esp6 module blacklisting. AFS users cannot blacklist rxrpc without losing AFS — wait for the distribution backport.