E meta e ngarkimit të skedarëve në Elementor Pro lejon sulmuesit të ekzekutojnë kod

Elementor Pro, shtesa me pagesë e ndërtuesit të faqeve Elementor për WordPress, kishte një gabim kritik në ngarkimin e skedarëve që lejonte këdo të vendoste një program funksional në një faqe interneti dhe ta ekzekutonte atë. Gabimi është regjistruar si CVE-2026-32475 dhe ka marrë vlerësimin 9.0 në shkallën CVSS, një sistem standard vlerësimi nga 0 në 10 ku numri më i lartë tregon një gabim më të rrezikshëm. Ai prek Elementor Pro versionin 4.2.1 dhe më të hershëm, dhe versioni i rregulluar, 4.2.2, u publikua më 19 gusht 2026. Dobësia u zbulua dhe u raportua në Patchstack nga Tin Pham, i njohur si TF1T, dhe Patchstack publikoi shkrimin e tij teknik për çështjen në të njëjtën ditë që thotë se u publikua rregullimi. Patchstack deklaron se ka lëshuar rregulla zbutëse për të mbrojtur kundër shfrytëzimit të gabimit.

Për këdo që nuk merret me faqe interneti çdo ditë: WordPress është softueri që drejton një pjesë shumë të madhe të faqeve në botë, dhe një ndërtues faqesh është një shtojcë, që do të thotë një pjesë softueri shtesë, që lejon pronarin të ndërtojë faqe vizualisht në vend që të shkruajë kod. Elementor është një nga ndërtuesit më të njohur të faqeve, dhe Elementor Pro është versioni i tij komercial. Ndër veçoritë që shton Elementor Pro është një widget Formularësh, i cili lejon pronarin e faqes të ndërtojë formularë kontakti, formularë aplikimi për punë dhe formularë kërkesash mbështetjeje brenda editorit, përfshirë një fushë Ngarkimi Skedari që një vizitor të bashkëngjitë një dokument. Kjo fushë është vendi ku qëndron gabimi, brenda modulit të Formularëve të shtojcës.

Analiza e Patchstack e përshkruan gabimin si një mospërputhje midis dy cikleve në skedarin modules/forms/fields/upload.php. Kur dorëzohet një formular, dy kalime të veçanta lexojnë të njëjtën listë të hyrjeve të skedarëve të ngarkuar. I pari, një metodë e quajtur validation(), kontrollon shtesën e secilës hyrje kundrejt një liste të llojeve të lejuara dhe kundrejt një liste të zezë të atyre të ndaluara. I dyti, një metodë e quajtur process_field(), merr çdo hyrje të vlefshme dhe e zhvendos skedarin në një direktori publike. Të dy kalimet nuk bien dakord për atë që do të thotë një hyrje bosh skedari. Një hyrje bosh është një pjesë ngarkimi me emër skedari bosh, të cilën PHP e raporton si UPLOAD_ERR_NO_FILE. PHP është gjuha programuese me të cilën është shkruar vetë WordPress.

Në ciklin e validimit, një hyrje bosh e hasur kur fusha nuk është shënuar si e detyrueshme bën që e gjithë metoda të ndalet dhe të kthehet, kështu që çdo hyrje pasuese në të njëjtin dorëzim mbetet e pakontrolluar. Në ciklin e përpunimit, e njëjta hyrje bosh thjesht anashkalohet dhe cikli vazhdon. Një sulmues mund të dërgojë pra dy pjesë skedari për të njëjtën fushë: një hyrje të parë bosh me emër skedari bosh, e ndjekur nga një skedar .php. Validimi ndalon së lexuari në hyrjen e parë dhe raporton një dorëzim të pastër. Zhvendosësi e anashkalon atë hyrje të parë dhe e zhvendos skedarin .php gjithsesi. Distanca midis një mbrojtjeje funksionale dhe këtij gabimi, siç e shpreh Patchstack, është një fjalë kyçe.

Mbrojtja e synuar është një funksion i quajtur is_file_type_valid(), i cili kërkon që shtesa e një skedari të ngarkuar të shfaqet në një listë të lejuar dhe e refuzon atë nëse shfaqet gjithashtu në një listë të zezë të koduar fort. Kjo listë e zezë përmend shprehimisht php, php3, php4, php5, php6, phps, php7, phtml, shtml, pht, swf, html, asp, aspx, cmd, csh, bat, htm, hta, jar, exe dhe com, ndër të tjera. Patchstack vëren se vetë kontrolli është i shëndoshë. Ai thjesht nuk ekzekutohet kurrë.

Hapi i zhvendosjes është vendi ku ndodh dëmi. process_field() lexon shtesën nga emri i skedarit të dorëzuar, ndërton një emër të ri me funksionin uniqid() të PHP, dhe e zhvendos skedarin në direktorinë publike të formularëve të shtojcës. Emri i skedarit i dorëzuar hidhet plotësisht. Vetëm shtesa mbijeton në emrin e ruajtur. Ky detaj përjashton disa truke të tjera. Një shtesë e dyfishtë si shell.php.jpg është e padëmshme këtu, sepse skedari do të ruhej me një emër të rastësishëm që mbaron me .jpg. Një skedar .htaccess i ngarkuar është po aq i padëmshëm, sepse bëhet një skedar .htaccess me emër të rastësishëm në vend të një skedari konfigurimi direktorie. Vetëm shtesa përfundimtare ka rëndësi, dhe mospërputhja e ciklit është e mjaftueshme për ta kaluar atë përtej kontrollit. Rezultati është një skedar .php që qëndron në wp-content/uploads/elementor/forms/, një dosje që është publikisht e arritshme përmes web-it. Kushdo mund të kërkojë atë adresë drejtpërdrejt dhe të bëjë që serveri të ekzekutojë skedarin. Kjo është ekzekutim kodi në distancë: kodi i vetë sulmuesit ekzekutohet në serverin e faqes.

Kërkesat për një sulm janë minimale. Faqja e synuar ka nevojë për të paktën një faqe të publikuar që përmban një formular Elementor me një fushë Ngarkimi Skedari, të cilën Patchstack e përshkruan si një konfigurim jashtëzakonisht të zakonshëm, të përditshëm. Formularët e aplikimit për punë, formularët që kërkojnë një foto, ID ose faturë, dhe bashkëngjitjet e kërkesave të mbështetjes i përdorin të gjithë atë. Butoni i detyrueshëm i fushës është i fikur si parazgjedhje, kështu që nuk nevojitet asnjë cilësim i fortifikuar ose i pazakontë. Gjithçka që i nevojitet sulmuesit për të ndërtuar kërkesën, post_id, form_id (identifikuesi i brendshëm i Elementor për widgetin e formularit) dhe emri i hyrjes së fushës së ngarkimit, është i dukshëm në HTML-në publike të faqes për çdo vizitor. Ngarkimi trajtohet përmes veprimit AJAX elementor_pro_forms_send_form, pa cookies dhe pa nonce të kërkuar. Një nonce është një kod sigurie një-herësh që WordPress normalisht e përdor për të verifikuar që një kërkesë erdhi nga një faqe legjitime.

Një detaj e ndërlikon sulmin: përgjigja e ngarkimit nuk kthen shtegun e skedarit, kështu që emri duhet të llogaritet. Kjo është më e lirë nga sa tingëllon, sepse uniqid() nuk është i rastësishëm por i bazuar në kohë. Ai prodhon 13 karaktere heksadecimalë, nga të cilët tetë kodojnë vulën kohore Unix në sekonda të plota dhe pesë kodojnë mikrosekonda. Meqenëse koka e përgjigjes Date e vetë serverit jep sekondat drejtpërdrejt, vetëm pesë karakteret e mikrosekondave duhet të hamendësohen, dhe Patchstack vëren se edhe ai hapësirë mund të ngushtohet në dritaren rreth vetë kërkesës së shfrytëzimit. Ekziston gjithashtu një rrugë që nuk kërkon fare hamendje. Modeli i parazgjedhur i njoftimit të Elementor Pro, [all-fields], paraqet çdo fushë të dorëzuar, përfshirë një rresht me URL-në e saktë të skedarit të ngarkuar. Kur një formular ka gjithashtu një veprim të dytë emaili automatik të aktivizuar, të cilin Patchstack thotë se është i zakonshëm pikërisht në formularët e aplikimit për punë dhe kërkesave të mbështetjes që mbajnë fusha ngarkimi skedarësh, ai email dërgohet në adresën që sulmuesi ka dorëzuar, duke zbuluar URL-në e saktë të ngarkimit.

Rregullimi në versionin 4.2.2 bën që dy ciklet të bien dakord për atë që do të thotë një hyrje bosh skedari, kështu që një hyrje nuk mund të injorohet më nga validuesi ndërsa ende merret nga zhvendosësi. Patchstack shton se versionet aktuale gjithashtu ri-kontrollojnë shtesën brenda vetë process_field(), menjëherë përpara se skedari të zhvendoset, kështu që lista e zezë tani mbron drejtpërdrejt destinacionin në vend të vetëm kalimit të validimit.

Për shkak se ky gabim është pa autentikim dhe lë një skedar pas në disk, përditësimi e mbyll vrimën por nuk zhbën një përpjekje që tashmë ka pasur sukses. Faqet që kishin një version të dobët me një formular publik që përmban një fushë Ngarkimi Skedari duhet gjithashtu të shikojnë në wp-content/uploads/elementor/forms/ për çdo gjë që nuk është një nga llojet e dokumenteve ose imazheve që formularët e tyre pranojnë në të vërtetë, dhe në veçanti për skedarë që mbarojnë me .php. Për pronarët që preferojnë të mos ndjekin vetë publikimet e shtojcave, një shërbim i menaxhuar i hostimit WordPress si AEU Hosting i vendos platformën dhe mirëmbajtjen e saj të rregullt të sigurisë në duart e një ofruesi në vend të pronarit të faqes.

Patchstack e quan këtë një gabim desinkronizimi klasik: kodi që vendos nëse një ngarkim lejohet dhe kodi që vepron mbi ngarkimin ecin në të njëjtat të dhëna me rregulla të ndryshme. Asnjë cikli nuk është i gabuar më vete, dhe leximi i secilit në izolim nuk tregon asgjë alarmante. Gabimi ekziston vetëm në hendekun midis tyre. Një pjesë bosh skedari është e mjaftueshme për të bërë validuesin dhe zhvendosësin të mos bien dakord, dhe kjo mospërputhje e kthen një fushë të kufizuar ngarkimi skedarësh në një mënyrë që një i huaj të ekzekutojë kod në server. Rregullimi i shkakut rrënjësor është që të dy ciklet të ndajnë saktësisht të njëjtin pamje se cilat hyrje janë ngarkime të vërteta dhe cilat janë bosh, kështu që një hyrje nuk mund të arrijë kurrë te zhvendosësi pa kaluar më parë validuesin.

Kronologjia e publikuar e Patchstack regjistron sekuencën: më 16 korrik 2026 mori raportin nga studiuesi, dhe të njëjtën ditë konfirmoi dobësinë, kontaktoi shitësin dhe caktoi identifikuesin CVE CVE-2026-32475. Më 17 korrik 2026 shitësi përgatiti rregullimin, me publikimin ende në pritje. Më 3 gusht 2026 Patchstack shqyrtoi rregullimin e shitësit dhe konfirmoi se ai e zgjidhi dobësinë. Më 19 gusht 2026 shitësi publikoi rregullimin në versionin 4.2.2, dhe në të njëjtën ditë u publikua shkrimi i këshillës së sigurisë.