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

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.