Կրիտիկական MongoDB թերությունը (CVE-2026-118383) կարող է վթարել հետ մնացող սերվերները failover-ի ժամանակ

MongoDB-ը թողարկել է CVE-2026-118383-ի շտկված տարբերակները՝ MongoDB Server-ի կրիտիկական նախնական նույնականացման թերության համար, որը կարող է վթարել ռեպլիկա հավաքածուի անդամին, եթե այն հաղթում է ընտրությունում՝ ռեպլիկացիայում հետ մնալով և ստանալով երկու չնույնականացված հարցում։ Թերությունը use-after-free է՝ 9,5/10 CVSS 4.0 սանդղակով։ Տուժած են ռեպլիկա հավաքածուի, ինչպես նաև բաժանված կլաստերների shard և config server անդամները։ առանձին mongod-ը չի տուժում։

Ինչպես է գործում թերությունը

Խոցելի տարբերակներում նույնականացման միացումը չի կանգնեցնում երկու հարցումները։ Դրանք ping հրամաններ են՝ readConcern.afterOpTime արժեքով, և յուրաքանչյուրը խնդրում է սերվերին սպասել, մինչև ռեպլիկացիան հասնի որոշակի կետի, ստեղծելով waiter սպասող ծանուցում։ Waiter-ները չեն լրանում և մնում են մինչև անդամի վերագործարկումը, rollback-ը կամ primary-ից հեռանալը։ Վթարը տեղի է ունենում, երբ դրանք ստացած անդամը հետագա ընտրությունում հաղթում է՝ չնայած մեկ այլ անդամից հետ մնալուն։ catch-up-ի ավարտին cleanup-ը կատարվում է երկու անգամ և վերաօգտագործում է ազատված հիշողությունը՝ վթարելով նոր primary-ը մինչև այն գրառումներ ընդունի։ Հետազոտողները ասել են, որ այդ պայմանները բավարարվելուց հետո վթարը չի կախված ժամանակային մրցավազքի հաղթանակից, և հարձակվողը չի կարող թիրախային անդամին ստիպել հետ մնալ կամ հաղթել ընտրությունում, կամ տեսնել, թե երբ է դա տեղի ունենում։

Տուժած տարբերակները և շտկումները

MongoDB-ը յուրաքանչյուր տուժած ճյուղի համար թողարկել է շտկված տարբերակ, և ճյուղի յուրաքանչյուր ավելի վաղ տարբերակ տուժած է՝ մինչև ճյուղի առաջին թողարկումը։ Ինքնակառավարվող տեղակայումները յուրաքանչյուր ռեպլիկա հավաքածուի անդամի վրա պետք է ունենան շտկված թողարկումը, և թարմացումից հետո ադմինիստրատորները պետք է ստուգեն յուրաքանչյուր անդամի տարբերակը՝ ներառյալ կոնտեյներներում գտնվող անդամները և սպասարկման ընթացքում անցանց եղածները։ MongoDB Atlas կլաստերները սպասարկման ընթացքում ինքնաբերաբար ստանում են շտկված տարբերակներ, և սպասարկումը հետաձգող հաճախորդները պետք է թարմացումը կիրառեն հնարավորինս շուտ։ 8.2 ճյուղը նշված տուժած տարբերակների թվում չէ, և դրա նորագույն թողարկումը 8.2.12 է, բայց GitHub-ում հրապարակված proof of concept-ը հաղորդում է, որ 8.2.12-ը դեռ ցուցադրել է թերությունը լաբորատոր փորձում՝ օգտագործելով միայն փորձարկման համար նախատեսված կարգավորում։ Ըստ ընկերության կյանքի ցիկլի ժամանակացույցի՝ 8.2 ճյուղը հուլիսի 31-ին հասել է կյանքի ավարտին։

Հայտնաբերում և մեղմացում

Մինչև անդամը կարող է թարմացվել, հետազոտողները խորհուրդ են տալիս տվյալների բազայի ցանցային մուտքը սահմանափակել միայն դրա կարիքն ունեցող համակարգերին, ինչը սահմանափակում է, թե ով կարող է ուղարկել երկու հարցումները, բայց չի շտկում թերությունը։ Տեղադրված waiter-ների կամ վթարի հետքերը գտնելու համար ստուգեք կառուցվածքային տեղեկամատյանները՝ 51803 ID-ով COMMAND Slow query գրառում՝ readConcern.afterOpTime կրող չնույնականացված ping-ի համար, որը ավարտվել է MaxTimeMSExpired-ով։ 21359 ID-ով primary catch-up մտնող անդամ և այնուհետև 21363 ID-ով երկու անգամ դուրս եկող՝ մեկ անցման ընթացքում։ և այդ դուրս գալուց հետո CatchupState::abort_inlock()-ը ներառող ֆատալ ազդանշան կամ backtrace։ Հարցումները կարող են ժամանել անջատումից առաջ, հետևաբար նույն անդամի ավելի վաղ տեղեկամատյանները ևս պետք է ստուգվեն։

Կոդի կատարման պնդումները

MongoDB-ը ասում է, որ թերությունը որոշակի պայմաններում կարող է հանգեցնել կամայական կոդի կատարման՝ սերվերի գործընթացում։ Լաբորատորիայում հետազոտողները ասել են, որ կոդի կատարում չեն հասել, և նրանց արդյունքները չեն ցույց տալիս, թե որքան հաճախ կաշխատի հարձակումը այլ միջավայրերում։ Proof-of-concept կոդը վերարտադրում է թերությունը լաբորատոր ռեպլիկա հավաքածուում։ դրա հուսալի ռեժիմը պահանջում է միայն փորձարկման համար նախատեսված կարգավորում, որը հեռավոր հարձակվողը չի կարող միացնել, և դրա նշված ազդեցությունը վթար կամ հիշողության վնասում է։ Proof-of-concept լաբորատոր փորձում՝ նույնականացումը անջատած վիճակում, շտկված 8.0.37-ը ընդունել է տեղադրված waiter-ները, բայց cleanup-ը կատարել է միայն մեկ անգամ։

Աղբյուրներ՝ The Hacker News