npm trusted publishing tani skadon konfigurimet e paverifikuara
npm trusted publishing është forcuar pasi Bloom Security gjeti një boshllëk që mund t’i lejonte një sulmuesi të publikonte një version të ri të paketës npm të dikujt tjetër pa vjedhur kredencialet e mirëmbajtësit.
GitHub, që zotëron npm, ka ndryshuar mënyrën se si trajtohen konfigurimet e paverifikuara të trusted publishing. Një konfigurim trusted publisher i krijuar rishtas tani ka 48 orë për të kryer publikimin e parë të suksesshëm të paketës. Pas atij publikimi të parë të suksesshëm, konfigurimi verifikohet dhe përjashtohet nga skadimi. GitHub thotë se ndryshimi i identitetit të repository ose projektit krijon një marrëdhënie të re besimi dhe nis një dritare të re verifikimi prej 48 orësh, ndërsa ndryshimet e zakonshme nuk e rinisin afatin.
Ndryshimi synon një dobësi specifike në mënyrën se si besimi lidhej fillimisht me emrin e një GitHub repository. Trusted publishing, i prezantuar për npm në korrik 2025, është një mënyrë pa kredenciale për të publikuar paketa npm nga një platformë continuous integration dhe continuous delivery, shpesh e shkurtuar si CI/CD, si GitHub Actions. CI/CD do të thotë sisteme të automatizuara që ndërtojnë, testojnë dhe publikojnë software. Në vend që të ruajë një sekret npm afatgjatë, ofruesi CI/CD krijon një OpenID Connect token jetëshkurtër, shpesh të quajtur OIDC token, për një ekzekutim të caktuar workflow. Më pas npm e kontrollon atë token kundrejt një konfigurimi publikimi të miratuar paraprakisht.
Ky model ul nevojën që mirëmbajtësit të ruajnë dhe të rrotullojnë kredencialet npm, gjë që zvogëlon rrezikun që një sekret i rrjedhur të përdoret për të publikuar paketa keqdashëse. Ai gjithashtu krijon provenance attestations për paketat npm, që janë të dhëna që ndihmojnë të tregohet se ku është ndërtuar një paketë dhe kush e ka publikuar atë. Dobësia që raportoi Bloom Security nuk ishte te ideja e përgjithshme e publikimit të bazuar në token, por te lidhja e hershme e besimit midis npm dhe GitHub repository.
Bloom Security i raportoi gjetjet e saj te GitHub më 6 qershor 2026. Kompania tha se npm fillimisht regjistronte adresën e lexueshme nga njeriu të repository, të quajtur edhe slug, në formën owner/repository. Sipas kërkimit, npm nuk mbështetej te ID-ja numerike e përhershme e GitHub repository deri pas publikimit të parë të suksesshëm nga ai repository. OIDC tokens të GitHub mbajnë ID numerike që mbeten të vlefshme pas riemërimeve dhe transferimeve të repository, por Bloom Security zbuloi se npm i shpërfillte këto ID para publikimit të parë të suksesshëm.
Kjo krijonte një boshllëk nëse një konfigurim trusted publisher tregonte te një repository slug që më vonë bëhej i disponueshëm. Bloom Security e quajti sulmin SlugFest. Që sulmi të funksiononte, trusted publisher i viktimës duhej të tregonte te një GitHub slug që një sulmues mund ta merrte, dhe ai repository nuk duhej të ishte përdorur ende për të publikuar një version të paketës në npm. Slug mund të bëhej i disponueshëm pasi një mirëmbajtës të kishte riemërtuar, transferuar ose fshirë një repository.
Rruga e sulmit e përshkruar nga Bloom Security është e drejtpërdrejtë. Një sulmues krijon një repository në shtegun e liruar owner/repository. GitHub i cakton atij repository të ri ID-në e vet numerike. Më pas sulmuesi krijon dhe ekzekuton një npm publishing workflow, i cili prodhon një OIDC token që përfshin slug të rimarrë dhe ID-në e re të repository. Kur ai token dërgohet te exchange endpoint i npm, npm sheh repository claim që përputhet me slug të ruajtur dhe lëshon një kredencial me kohë të kufizuar për publikim. Sulmuesi pastaj mund të publikojë një version të ri të një pakete që nuk e zotëron.
Ndikimi është serioz sepse versioni keqdashës do të shfaqej nën emrin legjitim të paketës. Ai do të përfitonte nga reputacioni ekzistues i paketës, historia e shkarkimeve dhe marrëdhëniet me projektet që varen prej saj. Bloom Security tha se gjeti më shumë se 1,500 paketa të cenueshme, me shkarkime të kombinuara prej më shumë se 10 milionë. Në supply chain security, kjo ka rëndësi sepse një paketë e komprometuar mund të tërhiqet automatikisht në shumë projekte të mëvonshme.
Bloom Security paralajmëroi gjithashtu se AI agents që funksionojnë në pajisjet e zhvilluesve mund ta rrisin rrezikun. Kompania tha se agents mund t’i zgjidhin vetë dependencies, shpesh zgjedhin versionin më të fundit dhe mund të mos kontrollojnë se nga e ka origjinën një paketë. Në atë situatë, një version keqdashës i publikuar përmes një repository slug të rimarrë mund të instalohet dhe të ekzekutohet pa e shqyrtuar më parë një person vendimin.
Përgjigjja e GitHub shton një periudhë skadimi për konfigurimet e reja trusted publishing që ende nuk janë verifikuar nga një publikim i suksesshëm. GitHub thotë gjithashtu se npm tani refuzon trusted publishing tokens nga eventet issue_comment të GitHub Actions. Ky kufizim shtohet krahas një kufizimi ekzistues për eventet pull_request_target. Të dyja llojet e eventeve kanë rëndësi sepse publishing tokens duhet të pranohen vetëm nga workflows që npm mund t’u besojë për aktivitet publikimi.
Për mirëmbajtësit, mesazhi praktik është të kontrollojnë nëse lidhjet e tyre npm trusted publisher ende tregojnë te repositories që ata kontrollojnë. Bloom Security i këshillon zhvilluesit të auditojnë lidhjet trusted publisher, të konfirmojnë se slug i listuar ende hapet te repository i tyre, ta fshijnë dhe ta rikrijojnë lidhjen nëse një repository është riemërtuar ose transferuar, të ndjekin me kujdes evente të papritura npm publish dhe të heqin lidhjet e besimit sa herë që një repository fshihet, transferohet ose riemërtohet.
Ky nuk është i vetmi problem supply chain që Bloom Security ka raportuar rreth emrave të besuar dhe hapësirave të papretenduara. Më herët në gusht, kompania tha se Open VSX dhe Microsoft’s VS Code Marketplace lejonin extension packs të referonin extensions që nuk ekzistonin në marketplaces. Bloom Security e quajti atë teknikë Extension Resurrection dhe tha se 87 packs në Open VSX dhe 677 packs në VS Code Marketplace ishin të cenueshme. Në atë skenar, një sulmues mund të pretendonte një vend bosh extension dhe të bënte që code të instalohej krahas një pack të besuar. Kompania vuri në dukje se extensions ekzekutohen me full host access, duke e bërë këtë një rrugë drejt remote code execution nën një shteg instalimi që duket i besuar.
Për pronarët e faqeve të internetit dhe bizneset, çështja npm është një kujtesë se faqet moderne shpesh varen nga paketa software të mirëmbajtura jashtë organizatës. Një dependency e vogël e përdorur në një build pipeline mund të ndikojë te një faqe publike, një panel administrimi ose një mjet i brendshëm nëse code keqdashës hyn në release chain. AEU-I ofron IT, infrastrukturë dhe këshillim me prioritet sigurinë, gjë që është e rëndësishme për ekipet që rishikojnë se si software, hosting dhe proceset e tyre operative trajtojnë rrezikun nga third-party dependencies.
Mësimi kryesor është i ngushtë, por i rëndësishëm: një cilësim besimi i bazuar në një emër të ndryshueshëm mund të bëhet i pasigurt kur ai emër ripërdoret më vonë. Skadimi i ri 48-orësh i GitHub për konfigurimet npm trusted publishing të paverifikuara e zvogëlon dritaren për atë kusht specifik, por mirëmbajtësit ende duhet të pastrojnë lidhjet e vjetra kur repositories riemërtohen, zhvendosen ose fshihen.