Copy Fail - One WordPress away from root

Thursday, April 30, 2026

One WordPress away from root

A aparut o vulnerabilitate noua in kernelul Linux, denumita Copy Fail si urmarita ca CVE-2026-31431.

Pe scurt: daca un atacator reuseste sa ruleze cod local ca user neprivilegiat, in anumite conditii poate ajunge la root. Nu este o vulnerabilitate remote directa, dar pentru serverele de hosting diferenta asta nu ne linisteste foarte mult.

De ce? Pentru ca intr-un mediu de shared hosting nu pornim discutia de la „are cineva SSH?”, ci de la scenarii mult mai banale:

  • un WordPress compromis;
  • un plugin vulnerabil;
  • un webshell incarcat printr-un formular prost protejat;
  • un cont de client compromis;
  • un script PHP care ajunge sa execute comenzi local.

De aici si titlul: One WordPress away from root.

Ce face Copy Fail

Vulnerabilitatea este in kernelul Linux, in zona subsistemului crypto, mai exact in mecanismele legate de algif_aead / authencesn.

Fara sa intram in detalii de exploatare, problema permite unui utilizator local sa modifice continut aflat in page cache pentru anumite fisiere citibile. In anumite conditii, acest lucru poate afecta modul in care sistemul incarca un binar privilegiat, cum ar fi /usr/bin/su, ceea ce poate duce la executie cu privilegii de root.

Altfel spus: atacatorul nu trebuie sa sparga parola de root. Daca poate executa cod local pe un sistem vulnerabil, poate incerca sa abuzeze bugul din kernel pentru a sari direct la privilegii administrative.

Este exploatabila remote?

Nu direct.

Copy Fail este o vulnerabilitate de tip local privilege escalation. Atacatorul trebuie sa aiba deja o forma de executie locala pe server.

Problema este ca, in hosting, executia locala poate veni din foarte multe locuri. Un singur site compromis poate fi suficient ca punct de plecare. Din acest motiv, impactul practic este serios pentru servere shared, servere cPanel, DirectAdmin, noduri cu mai multi useri, containere, CI runners sau orice sistem unde ruleaza cod al unor utilizatori diferiti.

Ce sisteme sunt afectate

Sunt afectate sisteme Linux cu kerneluri vulnerabile si cu modulul afectat disponibil/incarcat.

Din informatiile publice, vulnerabilitatea afecteaza mai multe distributii majore, inclusiv familii precum:

  • Debian;
  • Ubuntu;
  • RHEL;
  • AlmaLinux;
  • Rocky Linux;
  • SUSE;
  • Amazon Linux.

Nu toate versiunile sunt afectate la fel, iar exploitul public nu functioneaza identic pe toate distributiile. Asta nu inseamna automat ca un sistem este sigur. Inseamna doar ca trebuie verificata versiunea exacta de kernel si statusul patchurilor oferite de vendor.

AlmaLinux / RHEL 9 si 10

Pe AlmaLinux/RHEL 9 si 10, exploitul public pare sa nu functioneze in aceeasi forma pe toate sistemele sau nu este la fel de trivial, in functie de versiunea de kernel, configuratie si module disponibile.

Asta nu trebuie interpretat ca „nu sunt afectate”. Interpretarea corecta este:

Daca vendorul nu a confirmat clar ca versiunea ta nu este vulnerabila, trateaza sistemul ca potential afectat si aplica update-ul de kernel cand devine disponibil.

In productie, nu recomandam sa ne bazam pe faptul ca un PoC public nu functioneaza. PoC-ul public este doar o implementare. Vulnerabilitatea reala este in kernel.

Workaround temporar

Pana la instalarea unui kernel fixat, workaroundul recomandat este dezactivarea modulului algif_aead:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Aceasta comanda blocheaza incarcarea modulului vulnerabil si incearca sa il descarce daca este deja incarcat.

Verificare:

lsmod | grep algif_aead

Daca nu apare nimic, modulul nu este incarcat.

Atentie: workaroundul este temporar. Solutia corecta ramane update-ul de kernel si reboot.

Update si reboot

Pe AlmaLinux / Rocky / RHEL:

dnf update kernel
reboot

Dupa reboot:

uname -r

Daca folositi dnf-utils, puteti verifica daca sistemul mai necesita reboot:

needs-restarting -r

Pe Debian / Ubuntu:

apt update
apt upgrade
reboot

Dupa reboot:

uname -r

Ce servere trebuie tratate prioritar

  • servere shared hosting;
  • servere cPanel / WHM;
  • servere DirectAdmin;
  • servere cu useri SSH;
  • servere cu aplicatii web multe si greu de controlat;
  • noduri de virtualizare sau containere;
  • CI/CD runners;
  • orice sistem unde ruleaza cod primit de la clienti sau third-party.

Un server cu un singur site static si fara acces pentru alti useri are un risc practic mai mic. Un server de shared hosting cu sute de site-uri are un risc mult mai mare.

Ce facem noi

Monitorizam situatia, verificam versiunile de kernel si aplicam masurile necesare pe infrastructura administrata.

Unde este posibil, aplicam workaroundul temporar. Pe masura ce distributiile publica update-uri stabile de kernel, acestea vor fi instalate si serverele vor fi repornite controlat.

Pentru clientii cu servere administrate, recomandarea este simpla: permiteti aplicarea update-urilor de kernel si planificati un reboot. Fara reboot, un kernel vulnerabil poate ramane activ chiar daca pachetul nou a fost instalat.

Copy Fail este inca un exemplu de problema care arata de ce izolarea intre conturi, update-urile la timp si limitarea executiei locale conteaza. Un site compromis nu trebuie tratat ca o problema izolata de WordPress. Pe un sistem vulnerabil, poate deveni primul pas spre compromiterea intregului server.

« înapoi