
LMCache-ის 9.8-ქულიანი ხარვეზი კოდს ავტორიზაციის გარეშე უშვებს

JFrog-ის მკვლევრის, იუვალ მორავჩიკის, 2026 წლის 7 ოქტომბრის ტექნიკური აღწერის მიხედვით, LMCache-ის multiprocess ZeroMQ ტრანსპორტში აღმოჩენილი CVE-2026-105192 კრიტიკული, 9.8-ქულიანი ხარვეზია: ნაგულისხმევად 5555 პორტზე მისაწვდომ სერვერზე გაგზავნილ ერთ შეტყობინებას კოდის გაშვება შეუძლია ავტორიზაციის გარეშე. კოდი სრულდება იმ მომხმარებლის უფლებებით, რომლითაც LMCache-ის პროცესი მუშაობს. 9.8-ქულიანი შეფასება ეხება კონფიგურაციას, რომელშიც სერვერი სხვა ჰოსტებიდან მისაწვდომია.
GitHub-ის უსაფრთხოების ჩანაწერში ხარვეზი კრიტიკულადაა შეფასებული, ხოლო შესწორებული ვერსია უცნობად არის მითითებული. ადმინისტრატორისთვის დაუყოვნებელი კითხვა ამიტომ ასეთია: გაშვებულია თუ არა ცალკე multiprocess სერვერი და შეუძლია თუ არა არასანდო ჰოსტს მის ZeroMQ პორტთან დაკავშირება? მხოლოდ დაყენებული LMCache-ის ვერსია ამ ქსელურ წვდომას ვერ აჩვენებს.
როგორ იწვევს ქსელური შეტყობინება კოდის გაშვებას
Multiprocess რეჟიმში ქეშის სერვერი ცალკე პროცესად მუშაობს. სხვა LMCache პროცესები მას ZeroMQ-ით უკავშირდებიან, რეგისტრირდებიან და KV ქეშის ბლოკებს იზიარებენ. ამ სატრანსპორტო არხზე კლიენტის ავთენტიფიკაცია არ არის, ამიტომ სერვერი დამაკავშირებელი პროცესის ვინაობას თავად არ ამოწმებს.
შეტყობინებები msgpack ფორმატში იგზავნება, მაგრამ მათი ერთ-ერთი გაფართოების დამუშავება Python-ის pickle დესერიალიზაციამდე მიდის. არასანდო pickle მონაცემის წაკითხვისას შესაძლებელია კოდის შესრულება. ეს ხდება მოთხოვნის არგუმენტების გაშიფვრის ეტაპზე, სანამ შესაბამისი დამმუშავებელი ამოქმედდება; შეტყობინების შემდგომი უარყოფა უკვე შესრულებულ კოდს უკან ვერ დააბრუნებს.
მკვლევრის აღწერილ შემოწმებაში სერვერმა ჯერ ბრძანება შეასრულა, შემდეგ კი მოთხოვნის ტიპის შეცდომა დააფიქსირა. ამიტომ აპლიკაციის შეცდომა ვერ გამოდგება იმის ნიშნად, რომ ასეთი შეტყობინება უვნებლად დასრულდა. ოფიციალურ კონტეინერულ გამოსახულებებში LMCache-ის პროცესი root უფლებებით მუშაობს; სხვა განლაგებაში შესაძლო ზიანის ფარგლებს კონკრეტული პროცესის უფლებები და მისთვის ხელმისაწვდომი რესურსები განსაზღვრავს.
The Hacker News-ის 7 ოქტომბრის ცნობაში აღწერილია, რომ დაუცველი გზა 0.3.9 ვერსიიდან 0.5.5 სტაბილურ გამოშვებამდე გვხვდება და 0.5.6-ის წინასწარ ვერსიებსა და განვითარების განშტოებაშიც იყო. წინასწარი ვერსიის უფრო ახალი ნომერი თავისთავად შესწორებას არ ნიშნავს. ვერსიასთან ერთად გადამწყვეტია, ჩართულია თუ არა სწორედ ის ცალკე სერვერი, რომელიც ქსელურ შეტყობინებებს იღებს.
როდის არის ZeroMQ სერვერი სხვა ჰოსტისთვის მისაწვდომი
LMCache-ის ერთ vLLM პროცესში გამოყენება აღწერილ multiprocess პორტს არ ხსნის. ცალკე სერვერის გაშვების შემთხვევაშიც ნაგულისხმევი bind მისამართი localhost-ია: სხვა მანქანა ასეთ მისამართზე პირდაპირ ვერ უკავშირდება. იმავე ჰოსტზე ან ქსელის იმავე იზოლირებულ სივრცეში მომუშავე პროცესების ნდობა მაინც მნიშვნელოვანია, რადგან მათ ადგილობრივ სერვერთან კავშირის შესაძლებლობა შეიძლება ჰქონდეთ.
მრავალკვანძიან განლაგებაში ოპერატორმა შეიძლება სერვერს მარშრუტიზებადი მისამართი მიუთითოს, რათა სხვა კვანძებმა ქეშით ისარგებლონ. ამ დროს პორტთან მისვლა დამოკიდებულია მისამართთან ერთად firewall-ის წესებზე, კონტეინერების ქსელზე, სერვისის გამოქვეყნებასა და კლასტერში დაშვებულ კავშირებზე. ყველა ინტერფეისზე მოსმენა ავტომატურად საჯარო ინტერნეტიდან წვდომას არ ნიშნავს, თუმცა კავშირის შესაძლებლობას იმ ქსელებშიც ქმნის, რომლებამდე მარშრუტი არსებობს.
ამიტომ „შიდა ქსელშია“ არასაკმარისი აღწერაა. მნიშვნელოვანია, რომელი კონკრეტული ჰოსტები აღწევენ სერვერამდე და ყველა მათგანი სანდოა თუ არა. ქსელური შეზღუდვა დაუცველ არხთან დაკავშირების მსურველთა წრეს ამცირებს; ნებისმიერ დაშვებულ კლიენტს კვლავ შეუძლია შეტყობინების გაგზავნა, რადგან თავად ZeroMQ ტრანსპორტს ავთენტიფიკაცია არ აქვს.
უსაფრთხო შემოწმება მოქმედ განლაგებაში
ექსპლოიტის გაგზავნა წვდომის დასადგენად საჭირო არ არის. ადმინისტრატორს შეუძლია გაშვების პარამეტრები, რეალური მოსმენის მისამართი და ქსელური წესები შეამოწმოს. გადაწყვეტილების მიმდევრობა რეჟიმიდან იწყება, შემდეგ პორტამდე მისასვლელ გზას ადგენს და ბოლოს აფასებს, რა უფლებებით შესრულდებოდა კოდი შესაძლო გამოყენების შემთხვევაში.
- დაადგინეთ მუშაობის რეჟიმი. გაშვების კონფიგურაციაში მოძებნეთ ცალკე multiprocess სერვერი. მხოლოდ ერთ vLLM პროცესში ჩართული LMCache იმავე ZeroMQ ზედაპირს არ ქმნის, ამიტომ ამ შემთხვევებს ერთმანეთში ნუ აურევთ.
- შეამოწმეთ რეალური bind მისამართი. შეადარეთ გაშვებული პროცესის მოსმენის მისამართი კონფიგურაციაში ჩაწერილს. localhost-ზე მიბმული სერვერი და ქსელში მარშრუტიზებად მისამართზე მიბმული სერვერი სხვა ჰოსტებისთვის განსხვავებულად მისაწვდომია.
- დაადგინეთ პორტამდე გზა. გადაამოწმეთ ჰოსტის firewall, კონტეინერის ქსელი, Kubernetes Service, პორტის გარე გამოქვეყნება და კლასტერში დაშვებული წყაროები. ინტერნეტიდან დახურული პორტი ჯერ კიდევ შეიძლება მისაწვდომი იყოს არასანდო შიდა ჰოსტისთვის.
- შეაფასეთ პროცესის უფლებები. დაადგინეთ, რომელი მომხმარებლით მუშაობს LMCache და რომელ ფაილებს, საიდუმლოებებსა თუ სხვა რესურსებს სწვდება. ნაკლები უფლებები შესაძლო ზიანს ზღუდავს, თუმცა შეტყობინების დაუმოწმებელ დესერიალიზაციას არ ასწორებს.
- შეამოწმეთ იზოლაცია. მრავალკვანძიან გარემოში გამოყავით კვანძები, რომლებსაც ქეშთან კავშირი ნამდვილად სჭირდებათ, და დანარჩენებს ქსელური წვდომა შეუზღუდეთ. თუ სერვერი მხოლოდ ადგილობრივად მუშაობს, შეაფასეთ იმ პროცესებისა და კონტეინერების ნდობა, რომლებიც მის ქსელურ სივრცეს იზიარებენ.
რა არის ცნობილი შესწორებაზე
გამოქვეყნებულ უსაფრთხოების ჩანაწერში დადასტურებული შესწორებული ვერსია მითითებული არ არის. ამიტომ წინასწარი გამოშვების დაყენება ან განვითარების განშტოებაზე გადასვლა პატჩად ვერ ჩაითვლება მხოლოდ იმიტომ, რომ მისი ნომერი უფრო ახალია. შესწორების დასადასტურებლად გამოშვების აღწერამ სწორედ ქსელიდან მიღებული მონაცემის pickle-ით დამუშავების ცვლილება უნდა აჩვენოს.
თუ განლაგება ამის საშუალებას იძლევა, multiprocess სერვერის localhost-ზე დატოვება სხვა ჰოსტებიდან პირდაპირ კავშირს გამორიცხავს. მრავალკვანძიან გარემოში პორტთან წვდომის მხოლოდ აუცილებელი სანდო კვანძებისთვის დაშვება და პროცესის მინიმალური უფლებებით გაშვება შესაძლო ზიანს ზღუდავს. დაშვებული კვანძიდან დაუმოწმებელი შეტყობინების რისკი დარჩება მანამდე, სანამ გამოსწორებული სატრანსპორტო და დესერიალიზაციის გზა დადასტურებულ გამოშვებაში არ გამოჩნდება.
ასევე წაიკითხეთ:
მსგავსი სტატიები


Docker Compose თუ Kubernetes: ნაკლები CPU ყოველთვის ნაკლებ ხარჯს არ ნიშნავს

Anthropic-ის OSS Scanner უფასოა — ანგარიშს ადამიანი წინასწარ არ ამოწმებს

Cisco SD-WAN-ის ხარვეზს უკვე იყენებენ — დროებითი დაცვა საკმარისი არაა

Zimbra-ს ხარვეზს ერთი წერილიც ააქტიურებს — პატჩი კვალს არ შლის

Atlassian-ის ხარვეზს უკვე იყენებენ — Cloud ვერსია მოქმედებას არ ითხოვს
გამოიწერეთ ჩვენი ბიულეტენი
მიიღეთ უახლესი ამბები Web3-ის, AI-სა და კრიპტოს შესახებ პირდაპირ თქვენს ელფოსტაზე.