E meta kritike në libheif lejon që imazhet HEIC të ekzekutojnë kod në servera
Më 1 shtator 2026, projekti libheif publikoi versionin 1.23.3 për të mbyllur një tejmbushje kritike të buferit heap në bibliotekën e imazheve të përdorur gjerësisht. E meta u zbulua dhe u raportua katër ditë më parë nga ekipi Wordfence Threat Intelligence duke përdorur Wordfence Argus, dhe mirëmbajtësi i libheif Dirk Farin e vlerësoi atë 9.8 nga 10 në shkallën CVSS. Me fjalë të thjeshta, një imazh HEIC i krijuar posaçërisht mund të shkruajë bajte të kontrolluara nga sulmuesi përtej fundit të një buferi memorie, dhe në një server të cenueshëm kjo mund të çojë në leximin e skedarëve të mbrojtur nga procesi i përpunimit të imazheve ose në ekzekutimin e kodit me lejet e tij. Versionet e prekura janë 1.18.0 deri në 1.23.2 kur biblioteka është ndërtuar me kodekun e saj të pakompresuar të aktivizuar, dhe rregullimi është në 1.23.3; 1.23.4 është versioni aktual i sigurisë në rrjedhën e sipërme. Kjo nuk është një cenueshmëri vetëm për WordPress.
Për të kuptuar pse kjo ka rëndësi për një sajt WordPress, ndihmon të dish se çfarë bën në të vërtetë libheif. Pronarët e iPhone kanë krijuar skedarë HEIC që kur iOS 11 e bëri atë formatin e parazgjedhur të fotografive në 2017, sepse HEIC ruan një pamje më të mirë në rreth gjysmën e hapësirës së një JPEG. HEIC është një format kontejneri, në thelb një kuti me një listë paketimi që përshkruan se çfarë ka brenda dhe si është koduar. Pothuajse askush nuk shkruan kodin e vet për ta hapur atë; shumica e sistemeve Linux mbështeten te libheif. Vetë WordPress nuk dekodon imazhe. Kur një përdorues ngarkon një foto, WordPress ia dorëzon skedarin një redaktuesi imazhesh në mënyrë që të ndërtojë miniatura dhe të nxjerrë metadata. Në serverat e prekur, zgjerimi PHP Imagick thërret ImageMagick, i cili njeh HEIF dhe ia kalon skedarin libheif. Kjo do të thotë se një bibliotekë C++ është brenda procesit të përpunimit të imazheve PHP, duke analizuar bajte që kanë ardhur nga interneti me lejet e atij procesi. E njëjta bibliotekë qëndron gjithashtu nën shikuesit e imazheve të desktopit, galeritë e fotografive, serverat e medias të vetë-strehuar dhe gjeneratorët e miniaturave, kështu që çdo softuer që hap skedarë HEIC nga njerëz të tjerë është potencialisht i ekspozuar.
A duhet të shqetësohet një pronar sajti? Një rezultat CVSS prej 9.8 është afër maksimumit dhe thotë se kur një aplikacion e ekspozon këtë bibliotekë ndaj imazheve të pabesueshme në rrjet pa kërkuar hyrje, rezultati më i keq është një kompromis i plotë i serverit. Kjo nuk do të thotë se çdo sajt WordPress i lejon të huajt të ngarkojnë skedarë HEIC. Demonstrimi i Wordfence kundër një instalimi të pastër WordPress përdori një llogari të zakonshme Autori, e cila është roli i parë që lejohet të ngarkojë media në një sajt standard WordPress. Sistemet moderne gjithashtu i bëjnë të metat e korrupsionit të memories më të vështira për t'u shfrytëzuar: ASLR përzien vendndodhjen e kodit dhe të dhënave në memorie, dhe RELRO i bën disa tabela të brendshme vetëm për lexim. Megjithatë, Wordfence provoi se e meta mund të shkojë më tej. Në një konfigurim specifik WordPress që ekzekutonte Debian dhe glibc, një skedar HEIC i krijuar i lejoi studiuesit të lexonin një skedar të mbrojtur dhe të ekzekutonin kod. Një test më i ngushtë që kopjoi një imazh të ngarkuar në një vendndodhje tjetër funksionoi në 29 nga 30 përpjekje kundër një serveri Apache që ishte tashmë duke ekzekutuar dhe ripërdorur proceset e punës. Kjo është dëshmi e fortë e ndikimit real, por jo një shfrytëzim universal; ngarkesa varet nga ndërtimi i saktë i libheif, mënyra se si serveri menaxhon memorien dhe kërkesat që arrijnë te një proces me gjendjen e duhur. Një sulmues mund të ketë nevojë për një skedar të ndryshëm për një mjedis të ndryshëm. Megjithatë, nëse qindra ose mijëra sajte përdorin të njëjtin imazh hostimi, puna e bërë për njërin mund të bartet te të tjerët. Objektivat me vlerë të lartë dhe flotat e hostimit të ndërtuara nga një imazh i përbashkët meritojnë vëmendje të veçantë.
Gjetja nuk duhet të hidhet poshtë vetëm sepse një shfrytëzim duhet të përshtatet. HEIF Heist, kërkimi nga Hacktron që i ktheu disa cenueshmëri të tjera të libheif në sulme funksionale kundër shërbimeve reale të përpunimit të imazheve, tregon se sa shpejt mund të ndodhë përshtatja. Discourse konfirmoi ekzekutimin e kodit përmes një ngarkimi të prekur imazhi, dhe Vercel konfirmoi ekzekutimin e kodit të paautentikuar kur aplikacionet e prekura Next.js përpunuan një imazh AVIF të krijuar. Gjetja e Wordfence Argus është një e metë më e re, e veçantë me një shkak rrënjësor të ndryshëm dhe u rregullua më vonë; libheif 1.23.2 trajtoi dy cenueshmëri kritike të paraqitura në HEIF Heist, por kjo mbeti deri në 1.23.3. Hacktron thotë se përshtatja e shfrytëzimeve të tij ndaj një objektivi të ri zakonisht zgjaste rreth një ose dy ditë. Me fjalë të tjera, "duhet të përshtatet" është një pengesë shpejtësie dhe jo një kontroll sigurie, dhe arnimi duhet të jetë prioritet për çdo aplikacion që pranon skedarë HEIC ose HEIF nga njerëz që nuk i besoni.
Për sajtet WordPress në mënyrë specifike, rruga e zakonshme e përpunimit të imazheve është e ekspozuar vetëm nëse të gjitha këto janë të vërteta njëkohësisht: serveri ka zgjerimin PHP Imagick, sepse redaktuesi tjetër i imazheve i WordPress nuk mund të lexojë fare HEIC; instalimi i ImageMagick ishte i paketuar me mbështetje HEIF; versioni i libheif është midis 1.18.0 dhe 1.23.2; dhe ai libheif ishte kompiluar me kodekun e tij të pakompresuar të aktivizuar. Kjo kusht i fundit do të thotë se vetëm numri i versionit nuk mund të të tregojë nëse je i cenueshëm. Wordfence testoi nëntë konfigurime reale më 5 shtator duke i kërkuar secilit të dekodonte një skedar të vlefshëm HEIF të pakompresuar. Seti i cenueshëm përfshinte imazhin zyrtar Docker të WordPress (libheif 1.19.8), Debian 13 trixie (1.19.8), Ubuntu 26.04 (1.21.2) dhe Fedora 44 (1.21.2). Seti jo i cenueshëm përfshinte Ubuntu 24.04 LTS (1.17.6), Debian 12 bookworm (1.15.1), Alpine 3.22 (1.19.8), Alpine 3.23 (1.23.0) dhe AlmaLinux 10 (1.17.6). Debian 13 dhe Alpine 3.22 të dy ofrojnë libheif 1.19.8, por njëri është i cenueshëm dhe tjetri jo, sepse njëri aktivizon kodekun e pakompresuar në kohën e ndërtimit dhe tjetri jo. Imazhi zyrtar Docker i WordPress ishte i ekspozuar që në fillim: i ndërtuar mbi Debian 13, ai ofronte zgjerimin Imagick, raportonte mbështetje HEIC dhe libheif i tij dekodonte formatin e cenueshëm, me çdo kusht të plotësuar dhe pa asnjë veprim nga operatori. Për të kontrolluar sajtin tënd, hap Tools, Site Health, Info, Media Handling, i cili liston formatet e skedarëve që mbështet ImageMagick. Nëse HEIC nuk është i listuar, kjo rrugë e veçantë Imagick e WordPress nuk është e ekspozuar, megjithëse softuer tjetër në server mund të përdorë ende libheif. Nëse nuk mund të arnosh ende, ndalo pranimin e këtyre skedarëve duke hequr të katër llojet HEIF që pranon WordPress (heic, heif, heics, heifs) nga llojet e tua të lejuara të ngarkimit. Çaktivizimi i ekzekutimit PHP në direktorinë e ngarkimeve është gjithashtu një ide e mirë në përgjithësi. Nëse përdor imazhin zyrtar, merr një bazë të përditësuar, rindërto imazhin tënd pa u mbështetur në një shtresë të memorizuar dhe riimplementoje atë.
Si funksionon në të vërtetë e meta? Një foto me ngjyra ruhet si tre fotografi të veçanta: njëra mban ndriçimin dhe dy të tjerat mbajnë ngjyrën, njëra për sa blu është çdo pjesë e figurës dhe njëra për sa e kuqe. Sytë e njeriut vërejnë detajet në ndriçim shumë më tepër sesa detajet në ngjyrë, kështu që dy fotografitë me ngjyra mund të ruhen me rezolucion më të ulët dhe askush nuk e sheh ndryshimin. Në fjalorin e vetë skedarit, secila prej këtyre quhet plan. Çdo plan deklaron se sa hapësirë kanë nevojë pikat e tij, e quajtur thellësi biti. Tetë bit për pikë është e zakonshme dhe merr një bajt memorie; gjashtëmbëdhjetë bit jep gradacione më të imta dhe merr dy bajte. Formati lejon që çdo plan të deklarojë thellësinë e vet, një veçori e arsyeshme sepse i njëjti format mbart imazhe shkencore dhe sensorë ku pjesët ndryshojnë vërtet në saktësi. Një program që lexon një imazh i kërkon sistemit një bllok memorie mjaft të madh për ta mbajtur atë, i quajtur bufer. Nëse programi shkruan më shumë të dhëna sesa mund të mbajë buferi, teprica derdhet në memorien përtej buferit, e cila mund të përmbajë të dhëna të tjera ose shënime të përdorura nga programi. Kjo është një tejmbushje buferi, dhe nëse një sulmues kontrollon atë që shkruhet, ai mund të jetë në gjendje ta drejtojë programin të ekzekutojë kod sipas zgjedhjes së tij. Në libheif 1.23.2, buferi i secilit plan përmasohet nga thellësia e deklaruar e atij plani, gjë që është e saktë. Çështja qëndron në mënyrën se si shkruhet fotografia. Dy planet me ngjyra ruhen të endura së bashku në skedar, një pikë nga secili, duke alternuar përgjatë rreshtit, kështu që një cikël i vetëm mbush të dy buferat njëkohësisht. Ai cikël kërkon sa e gjerë është një pikë vetëm një herë, nga cilido plan ngjyrash që skedari e liston të parin. Nëse bluja gjashtëmbëdhjetë-bitëshe është e listuar e para, cikli merr dy bajte si gjerësi dhe shkruan pika dy-bajtëshe në të dy buferat. Buferi i blusë mund t'i mbajë ato, por buferi i së kuqes është përmasuar për pika një-bajtëshe, kështu që çdo pikë e shkruar në të është dyfishi i madhësisë që duhet të jetë dhe bie dy herë më larg. Çdo rresht tejmbush në rreshtin poshtë tij, dhe rreshti i fundit kalon përtej fundit të buferit në memorien që i përket diçkaje tjetër. Bajtet që derdhen vijnë nga skedari i imazhit, kështu që kushdo që e bën skedarin zgjedh atë që shkruhet atje, dhe sasia që derdhet rritet me dimensionet e deklaruara të imazhit. Sipas fjalëve të mirëmbajtësit Dirk Farin, "si bajtet e shkruara ashtu edhe gjatësia e tejmbushjes kontrollohen nga skedari." Gabimi është i dukshëm në regjistrimin që libheif mban për çdo plan: dy tregues, dy gjatësi rreshtash, por vetëm një fushë bytes_per_component_sample, kështu që kodi supozon se të dy planet me ngjyra përdorin të njëjtën thellësi edhe pse skedari lejohet të deklarojë se nuk e bëjnë. Direkt mbi këtë cikël është një koment që përshkruan një shkrim tjetër jashtë kufijve në të njëjtin funksion që ishte rregulluar disa muaj më parë, kështu që i njëjti kod ishte arnuar tashmë një herë për shkrimin përtej fundit të një plani ngjyrash.
Wordfence Argus zbuloi cenueshmërinë më 28 gusht 2026 gjatë një vlerësimi sigurie të WordPress 7.1. Ekipi e riprodhoi atë kundër libheif zyrtar 1.23.2 me një ndërtim sanitizues dhe një skedar kontrolli të përputhur, konfirmoi një ndërtim të dytë të prekur, demonstroi ndikimin në një instalim të pastër WordPress dhe e raportoi atë te mirëmbajtësi i libheif përmes raportimit privat të cenueshmërive të GitHub. Më 31 gusht mirëmbajtësi kreu një rregullim dhe më 1 shtator u publikua libheif 1.23.3 dhe u publikua këshilla. Kërkimi pasues më 2 shtator mati besueshmërinë nëpër versione dhe konfigurime ndërtimi. Për pronarët e sajteve në hostim të menaxhuar WordPress si AEU Hosting, hapi praktik është të pyesni ofruesin tuaj drejtpërdrejt nëse libheif i serverit është i arnuar dhe nëse ngarkimet HEIC pranohen, pasi një shërbim i menaxhuar duhet të jetë në gjendje të përditësojë bibliotekat e sistemit dhe të rindërtojë kontejnerët në emrin tuaj. E njëjta pyetje vlen kudo që përdoret libheif: a e dekodon ky softuer skedarët HEIC që kanë ardhur nga dikush tjetër? Nëse përpunoni skedarë nga burime të pabesueshme, qoftë një shërbim i ndarjes së fotografive, tubacion dokumentesh, aplikacion bisede që gjeneron pamje paraprake, ose server media i vetë-strehuar, zhvendoseni këtë drejt krye të listës suaj të arnimeve. Kontrolloni si versionin e instaluar të libheif ashtu edhe nëse ishte ndërtuar me kodekun e pakompresuar të aktivizuar, instaloni paketën e rregulluar të shitësit tuaj, izoloni ose sandboxoni përpunimin e imazheve ku është e mundur dhe çaktivizoni mbështetjen HEIF nëse nuk ju nevojitet. Mësimi më i thellë është se cenueshmëritë që dëmtojnë sajtet WordPress nuk jetojnë gjithmonë në vetë WordPress; disa prej tyre jetojnë disa shtresa më poshtë në biblioteka të përbashkëta, të arritura nga një veçori aq e zakonshme sa ngarkimi i një fotoje pushimesh.