CUPS RCE pe VPS Linux: CVE-2026-34980 se înlănțuie până la root — verifică dacă ești expus chiar acum

Două vulnerabilități publicate pe 2 aprilie 2026 — CVE-2026-34980 și CVE-2026-34990 — se înlănțuie într-un exploit complet neautentificat, de la acces de rețea la root, împotriva oricărui server Linux care rulează CUPS cu o coadă PostScript partajată accesibilă în rețea. Exploatarea activă a fost confirmată. Remedierea este un singur rând de comandă dacă nu imprimai nimic, respectiv un singur upgrade de pachet dacă imprimați. Rulează verificarea de mai jos imediat, înainte de a citi restul.

systemctl is-active cups 2>/dev/null || echo "CUPS not running"

Dacă rezultatul este active, serverul tău este expus până când iei măsuri. Dacă returnează inactive, unknown sau CUPS not running, nu ești expus imediat vectorului de rețea — dar verifică dacă pachetul este instalat, deoarece CVE-2026-34990 are o cale de escaladare locală a privilegiilor care contează chiar și dacă serviciul este oprit.

De ce serverele VPS sunt ținta principală

CUPS nu a fost conceput pentru medii server. Este un subsistem desktop de imprimare. Problema este că multe imagini de bază ale distribuțiilor — inclusiv cele folosite pentru templateurile VPS — instalează CUPS ca dependență recomandată a altor pachete, adesea fără nicio solicitare explicită din partea operatorului. Un sistem Rocky Linux sau Ubuntu Server provizionat dintr-o imagine standard poate avea cupsd rulând pe portul 631, ascultând conexiuni, deși acel VPS nu a văzut niciodată o imprimantă în toată existența sa.

Aceasta este suprafața de atac care face CVE-2026-34980 disproporționat de periculos pentru infrastructura cloud față de sistemele desktop. Pe un desktop, CUPS este de așteptat să fie prezent, iar un firewall local blochează de obicei portul 631 de la accesul extern. Pe un VPS, același port este adesea deschis spre internet pentru că nimeni nu s-a gândit să auditeze un daemon de imprimare pe un server web. Conform cercetătorului care a descoperit lanțul de exploatare, condițiile necesare — un cupsd expus în rețea cu o coadă PostScript partajată — sunt îndeplinite în practică pe o proporție mare din serverele Linux scanate în perioada de dezvăluire responsabilă.

Cum funcționează lanțul celor două CVE-uri

Înțelegerea mecanismului contează deoarece determină ce măsură de remediere se aplică situației tale. Cele două vulnerabilități sunt independente la nivel de cod, dar secvențiale în calea de atac.

CVE-2026-34980 — RCE neautentificat ca utilizator lp

CUPS acceptă implicit cereri anonime de tip Print-Job pentru cozile partajate — verificarea autentificării blochează doar joburile de la distanță către cozile nepartajate. Vulnerabilitatea este o eroare de parsare în modul în care cupsd gestionează valoarea opțiunii page-border transmisă ca textWithoutLanguage într-o cerere IPP construită malițios. Un atacator injectează un caracter de linie nouă în interiorul valorii opțiunii. CUPS păstrează linia nouă prin etapa de escapare și re-parsare a opțiunilor, iar linia rezultată este interpretată ca o înregistrare de control de tip PPD a schedulerului — provenind dintr-o sursă de încredere — în loc de date furnizate de utilizator.

Un job de imprimare raw ulterior exploatează înregistrarea de control injectată pentru a instrui schedulerul să execute un binar existent pe server. Atacatorul obține execuție de cod ca contul de serviciu lp. Prin el însuși, acesta este un risc serios, dar nu decisiv — lp este un cont cu privilegii reduse și nu poate citi direct fișiere sensibile sau scrie în căile de sistem. Aici intră al doilea CVE.

CVE-2026-34990 — de la lp la root prin abuzul tokenului IPP de pe localhost

Al doilea defect există în politica de autorizare implicită CUPS pentru conexiunile de pe localhost. CUPS emite tokenuri reutilizabile Authorization: Local pentru conexiunile locale și — critic — operațiunea IPP CUPS-Create-Local-Printer nu este restricționată prin autentificare de administrator atunci când cererea provine de pe localhost în politica implicită.

Cu execuție de cod ca lp, atacatorul forțează cupsd să se autentifice la un serviciu IPP controlat de atacator pe un port ales de localhost. CUPS transmite un token local. Atacatorul reutilizează acel token pentru a emite cereri directe către /admin/ împotriva instanței cupsd active. Folosind CUPS-Create-Local-Printer cu printer-is-shared=true și un URI file:///, atacatorul înregistrează o imprimantă falsă care pointează către orice cale de fișier din sistem. Politica normală FileDevice respinge URI-urile file://, dar acest bypass ocolește restricția prin calea Create-Local-Printer. Declanșarea unui job de imprimare către acea imprimantă falsă produce o suprascriere arbitrară de fișier ca root. Dovada de concept publicată scrie un fragment sudoers care acordă atacatorului execuție completă de comenzi ca root.

Lanțul complet: atacator de rețea neautentificat → job IPP de imprimare → RCE ca lp → capturare token localhost → acces API admin → suprascriere fișier ca root → intrare sudoers → shell root. Nicio credențială nu este necesară în nicio etapă a intrării inițiale.

Versiuni afectate și starea patch-urilor

Ambele CVE-uri afectează CUPS versiunea 2.4.16 și anterioare. OpenPrinting a lansat CUPS 2.4.17 pe 16 aprilie 2026, care remediază CVE-2026-34980 (filtrarea caracterelor de control în valorile opțiunilor) și CVE-2026-34990 (gestionarea certificatelor locale pe interfața loopback), alături de alte patru CVE-uri corectate în aceeași versiune.

Disponibilitatea patch-urilor la nivel de distribuție la data de 20 aprilie 2026:

Distribuție	Status CVE-2026-34980	Status CVE-2026-34990	Acțiune necesară
Ubuntu 22.04 / 24.04	Patch în curs	Patch în curs	Dezactivează sau blochează portul 631 imediat
Debian 11 Bullseye	Vulnerabil (2.3.3op2)	Vulnerabil	Dezactivează sau blochează portul 631 imediat
Debian 12 Bookworm	Vulnerabil (2.4.2)	Vulnerabil	Dezactivează sau blochează portul 631 imediat
Rocky Linux 8 / 9	Advisory Red Hat activ	Advisory Red Hat activ	Dezactivează sau aplică updateul din advisory
AlmaLinux 8 / 9	Advisory Red Hat activ	Advisory Red Hat activ	Dezactivează sau aplică updateul din advisory
openSUSE / SLES	Advisory SUSE activ	Advisory SUSE activ	Aplică update de securitate via zypper
Arch Linux	cups 2.4.17 în repo	cups 2.4.17 în repo	pacman -Syu
Alpine Linux	Verifică tracker-ul aports	Verifică tracker-ul aports	Dezactivează sau apk upgrade cups

Pentru distribuțiile unde pachetul corectat nu este încă disponibil în repo-urile oficiale, dezactivarea completă a serviciului este măsura corectă — nu așteptarea. Un VPS care nu folosește o imprimantă nu are niciun motiv să ruleze cupsd.

Pasul 1 — Verificare completă a expunerii

Rulează acest bloc în consola VPS-ului tău sau prin SSH. Verifică dacă serviciul rulează, ce versiune este instalată și dacă portul 631 este accesibil din exterior:

# Verifică dacă cupsd rulează
systemctl is-active cups 2>/dev/null && echo "EXPUS: cupsd este activ" || echo "cupsd nu rulează"

# Verifică versiunea instalată
cups-config --version 2>/dev/null || dpkg -l cups 2>/dev/null | grep ^ii || rpm -q cups 2>/dev/null

# Verifică dacă portul 631 ascultă și pe ce interfață
ss -tlnp | grep 631

A treia comandă este cea mai importantă. Dacă portul 631 apare ca 0.0.0.0:631 sau :::631, daemonul ascultă pe toate interfețele și este accesibil din internet. Dacă apare ca 127.0.0.1:631, vectorul de atac de rețea al CVE-2026-34980 este blocat — dar calea de escaladare locală a CVE-2026-34990 rămâne aplicabilă dacă există conturi de utilizator local pe mașină.

Pasul 2a — Dacă VPS-ul tău nu imprimă (majoritatea workload-urilor VPS)

Oprește și dezactivează permanent CUPS. Dezactivează și cups-browsed dacă este prezent — este un serviciu separat care participă la lanțul de vulnerabilități CUPS din 2024 și nu are niciun scop pe un server:

# Oprește și dezactivează schedulerul principal CUPS
systemctl stop cups
systemctl disable cups
systemctl mask cups

# Oprește și dezactivează cups-browsed dacă este instalat
systemctl stop cups-browsed 2>/dev/null
systemctl disable cups-browsed 2>/dev/null
systemctl mask cups-browsed 2>/dev/null

# Verifică că ambele sunt oprite
systemctl is-active cups cups-browsed 2>/dev/null

Comanda mask merge mai departe decât disable — creează un symlink al unității de serviciu către /dev/null, împiedicând orice alt pachet sau proces să îl pornească ca dependență. Pe Alpine Linux (OpenRC), echivalentul este:

rc-service cups stop
rc-update del cups
rc-update del cups-browsed 2>/dev/null

Pe FreeBSD, previne pornirea la boot:

sysrc cupsd_enable="NO"
service cupsd stop 2>/dev/null

După mascare, rulează din nou blocul de verificare a expunerii și confirmă că portul 631 nu mai apare în rezultatul ss.

Pasul 2b — Dacă VPS-ul tău rulează un server de imprimare (upgrade necesar)

Dacă rulezi CUPS în mod deliberat — de exemplu, un server de imprimare partajat sau un VPS de tip workstation cu interfață grafică — dezactivarea serviciului nu este o opțiune. Acțiunea corectă este upgrade-ul la CUPS 2.4.17, singura versiune care corectează ambele CVE-uri.

Pe Arch Linux, unde 2.4.17 este deja în repo-uri:

pacman -Syu cups

Pe distribuțiile unde 2.4.17 nu este încă disponibil prin managerul de pachete al sistemului, aplică updateul de securitate disponibil din advisory ca măsură parțială și adaugă imediat o regulă de firewall pentru a restricționa portul 631 la adrese IP sursă de încredere:

# Ubuntu / Debian — blochează accesul extern la portul CUPS
ufw deny 631/tcp
ufw deny 631/udp
ufw reload

# Rocky Linux / AlmaLinux / RHEL
firewall-cmd --permanent --remove-service=mdns
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="631" protocol="tcp" reject'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="631" protocol="udp" reject'
firewall-cmd --reload

Regula de firewall neutralizează vectorul de rețea al CVE-2026-34980 fără a dezactiva funcționalitatea de imprimare pentru utilizatorii locali. CVE-2026-34990 rămâne un risc atât timp cât serviciul rulează și conturile neprivilegiate au acces local, deci upgrade-ul la CUPS 2.4.17 rămâne necesar imediat ce pachetul corectat ajunge în repo-ul distribuției tale.

Pasul 3 — Verificarea remedierii

După aplicarea oricărei măsuri de remediere, confirmă starea cu o verificare finală:

# Confirmă că serviciul nu rulează (calea de dezactivare)
systemctl is-active cups && echo "ATENȚIE: încă activ" || echo "OK: nu rulează"

# Confirmă că portul 631 nu mai este expus (ambele căi)
ss -tlnp | grep 631 && echo "ATENȚIE: portul încă deschis" || echo "OK: portul 631 nu ascultă"

# Confirmă că masca este activă (calea de dezactivare)
systemctl is-enabled cups

Ultima comandă trebuie să returneze masked, nu disabled. O unitate mascată nu poate fi pornită de niciun trigger, inclusiv updateuri de pachete. O unitate doar dezactivată poate fi pornită manual sau ca dependență — mascarea este starea corectă pentru un serviciu pe care l-ai eliminat intenționat de pe un server.

Context de hardening mai larg

Situația CUPS este un exemplu specific al unei probleme generale: serviciile care aparțin mediilor workstation ajung pe servere deoarece imaginile de bază ale sistemelor de operare sunt construite pentru acoperire largă, nu pentru suprafață minimă de atac. Un VPS Ubuntu Server sau Rocky Linux proaspăt instalat poate rula un daemon de imprimare, un responder Avahi mDNS, un stub de stivă Bluetooth și un agent SNMP — niciunul din ele nu aparține unui server cloud, toate au un istoric CVE relevant.

Practica corectă pe termen lung este un audit explicit al serviciilor care rulează imediat după provizionarea unui VPS nou:

systemctl list-units --type=service --state=running

Orice serviciu pentru care nu poți explica un motiv specific ar trebui oprit și mascat. Aceasta aduce VPS-ul la o stare minimă de rulare unde suprafața de atac corespunde workload-ului real, nu ipotezelor implicite ale unui manifest de pachete desktop.

Dacă ai nevoie de ajutor pentru auditarea și hardening-ul unui VPS — inclusiv identificarea serviciilor neașteptate care rulează, configurarea regulilor de firewall și aplicarea advisory-urilor de securitate în așteptare — serviciul de administrare Linux gestionat ServerSpan acoperă direct această categorie de lucru. Pentru serverele nou provizionate care au nevoie de un punct de plecare curat, toate planurile VPS ServerSpan includ acces root complet și disponibilitate consolă astfel încât să poți aplica acești pași imediat după provizionare.

Rezumat acțiuni necesare la data de 20 aprilie 2026: Dacă VPS-ul tău rulează CUPS și nu ai nevoie de el — oprește, dezactivează și maschează serviciul chiar acum. Dacă ai nevoie de CUPS și ești pe Arch Linux, fă upgrade la 2.4.17 via pacman -Syu. Dacă ai nevoie de CUPS pe orice altă distribuție unde 2.4.17 nu este încă în repo-uri, adaugă o regulă de firewall care blochează portul 631 extern și urmărește apariția pachetului corectat. Niciun patch, nicio excepție — CVE-2026-34990 acordă root oricărui utilizator local pe o configurație CUPS implicită.