OpenSSH 10.6p2: vulnerabilitatea care permite accesul prin SSH cu o parolă foarte lungă pe Alpine Linux

Publicat pe 6 noiembrie 2026 · Echipa mitza.es

SSH este „cheia universală” cu care se administrează majoritatea serverelor Linux: servește pentru a intra la distanță pe o mașină și a executa comenzi. Dacă cineva reușește să ocolească parola, serverul ajunge pe mâna lui. Pe 5 noiembrie 2026, proiectul OpenSSH a publicat versiunea 10.6p2, iar Alpine Linux a difuzat în aceeași zi un aviz de securitate despre o vulnerabilitate de acest tip. O rezumăm la data de 6 noiembrie 2026, limitându-ne la ce au publicat cele două proiecte.

Ce spun OpenSSH și Alpine

Notele de versiune OpenSSH 10.6p2 vorbesc despre corectarea unei ocoliri a autentificării prin parolă care poate fi exploatată prin sshd și care „afectează unele sisteme Linux atunci când sunt compilate și rulate cu suportul PAM dezactivat”. Proiectul însuși consideră că cauza principală se află în afara sshd și descrie corecția ca pe o măsură de securitate critică pentru sistemele Linux cu biblioteca musl și PAM dezactivat.

Avizul Alpine, din aceeași dată, precizează mecanismul: funcția crypt() din musl returnează textul * ca indicator de eroare atunci când cheia depășește 256 de octeți. Un atacator care trimite o parolă foarte lungă (de 257 până la 1.024 de octeți) poate ajunge să se autentifice fără să cunoască parola, cu condiția să fie îndeplinite două condiții: să existe un cont al cărui câmp de parolă este * (un cont fără parolă de autentificare) și să existe cel puțin un alt cont cu o parolă criptată cu un hash de tip $5$ sau $6$. Potrivit Alpine, atacul funcționează întotdeauna și nu necesită reîncercări.

Aceste detalii tehnice te ajută să înțelegi riscul; nu trebuie să le memorezi. Important este rezultatul: în anumite configurații, parola încetează să mai protejeze accesul.

Pe cine afectează

• Alpine Linux cu pachetul openssh-server, care este compilat fără PAM, și, de asemenea, cu openssh-server-pam dacă are UsePAM no. Cu openssh-server-pam și UsePAM yes nu există nicio problemă.
• Toate versiunile Alpine verificate: de la 3.21 la 3.24 și edge, plus cele vechi, fără actualizări regulate (de la 3.16 la 3.20).
• Imaginile cloud Alpine (tiny-cloud) de la 3.18.11 până la 3.24.3 (formate precum qcow2, VHD sau AMI), dacă pe mașină există vreo parolă cu hash $6$.
• Nu sunt afectați cei care folosesc containere Docker în care nu rulează sshd. Dacă ai un container cu un server SSH în interior, tratează-l ca pe orice alt server.

Alpine este frecvent în containere și în mașini virtuale ușoare, și mai puțin pe servere de uz general. Dacă firma ta are un VPS, un server propriu sau un echipament de rețea, întrebarea utilă este simplă: ce sistem de operare folosește și este portul SSH deschis către internet? Dacă nu știi, întreabă-l pe cel care îl administrează.

Versiuni corectate

OpenSSH corectează vulnerabilitatea în versiunea 10.6p2. La Alpine, pachetele corectate pe ramuri sunt următoarele:

• edge: 10.6_p2-r0
• 3.24: 10.3_p1-r2
• 3.23: 10.2_p1-r1
• 3.22: 10.0_p1-r11
• 3.21: 9.9_p2-r1

Alpine a publicat și pachete corectate pentru ramurile mai vechi (de la 3.16 la 3.20) și noi imagini cloud începând cu versiunile 3.21.10, 3.22.8, 3.23.8 și 3.24.4. Verifică avizul original Alpine înainte să acționezi, pentru că este sursa care se poate actualiza. Repornește serviciul SSH după actualizare: potrivit Alpine, actualizarea pachetului nu repornește un sshd care rula deja, iar cât timp nu este repornit continuă să ruleze versiunea vulnerabilă (la Alpine, rc-service sshd restart).

Este exploatată?

Nici OpenSSH, nici Alpine nu raportează atacuri observate. Alpine preciza, în plus, că, la momentul redactării avizului, nu fusese încă atribuit un identificator CVE. Dacă vezi alte date în presă sau în panourile de vulnerabilități (un număr CVE, un scor sau referiri la atacuri), compară-le cu avizele oficiale OpenSSH și Alpine înainte să le consideri sigure. Merită totuși tratată ca urgentă: potrivit chiar avizului, atacul este simplu și fiabil.

Ce faci astăzi: lista de verificare

1. Identifică serverele tale cu SSH accesibil și sistemul lor de operare (cat /etc/os-release). Dacă folosesc Alpine, urmează pașii de mai jos.
2. Actualizează OpenSSH la pachetul corectat pentru ramura ta și repornește sshd.
3. Dacă nu poți actualiza imediat, dezactivează accesul cu parolă: setează PasswordAuthentication no în configurația sshd și repornește serviciul. Potrivit Alpine, oricare dintre cele două măsuri (patch-ul sau dezactivarea parolelor) închide breșa. Înainte să o faci, asigură-te că ai acces pe bază de chei sau pe altă cale, ca să nu rămâi pe dinafară.
4. Verifică jurnalele de acces în căutarea liniilor „Accepted password for” ale unor conturi care nu ar trebui să poată intra cu parolă. Este indiciul pe care îl sugerează Alpine.
5. Dacă există indicii de intruziune, schimbă credențialele și cheile, izolează serverul și consultă-te cu furnizorul tău de servicii informatice sau sună la INCIBE la numărul 017.

Bune practici SSH care reduc aceste riscuri

• Intră cu chei, nu cu parole. Dezactivează autentificarea prin parolă ori de câte ori este posibil; această vulnerabilitate este un motiv bun.
• Limitează cine se poate conecta: un firewall care permite doar anumite adrese sau un VPN și AllowUsers pentru a restrânge conturile. Face parte din ce explicăm în ce este un firewall și de ce are nevoie un IMM.
• Fără acces direct ca administrator (root): folosește un utilizator obișnuit cu permisiuni ridicate.
• Instrumente împotriva încercărilor în masă, precum fail2ban, și alerte când intră cineva neașteptat.
• Inventar și termen maxim de aplicare a patch-urilor pentru defectele critice (de exemplu, 48 de ore).
• Copii de siguranță testate, pentru cazul în care ar trebui reconstruit un server: regula 3-2-1.

Întrebări rapide

Mă afectează dacă folosesc Ubuntu, Debian sau Red Hat?

Avizul Alpine descrie o problemă a combinației dintre musl, pe care o folosește Alpine, și sshd fără PAM. Distribuțiile bazate pe glibc care folosesc PAM nu se potrivesc cu ce este descris, dar prudent este să verifici avizul distribuției tale și versiunea OpenSSH instalată. Iar dacă serverul este administrat cu parolă, este un moment bun să treci la chei.

Și dacă site-ul meu este pe un hosting partajat?

Atunci administrarea serverului ține de furnizor. Îl poți întreba dacă folosește Alpine cu SSH expus și când aplică patch-urile de securitate. Vezi și ghidul nostru despre domeniu și hosting.

Și dacă am un NAS sau un router cu SSH activat?

Avizul Alpine nu le menționează, așa că nu putem spune că te afectează. Dar multe echipamente de rețea și de stocare rulează Linux, iar producătorul este cel care publică patch-urile lor: întreabă care este starea SSH și dezactivează-l dacă nu îl folosești.

Cum te ajutăm la Mitza

Facem inventarul serverelor, verificăm accesele la distanță și aplicăm patch-uri și o configurație sigură a SSH. Vezi cum lucrăm în mentenanța IT pentru IMM-uri sau scrie-ne din pagina de contact.

Citește și: vulnerabilitatea critică din kernelul Linux CVE-2026-98432 și auditul de securitate web.