Node.js, Python და Next.js პატჩების კვირა: როგორ ვაახლებ production სერვერებს

ერთ კვირაში გამოვიდა უსაფრთხოების შესწორებები Node.js-ის, Python-ისა და .NET-ისთვის, ხოლო Next.js-მა ბაგფიქსების ბექპორტი გამოუშვა მხარდაჭერილ განშტოებაში. თუ საკუთარი სერვერი, საიტი ან ინტეგრაციები გაქვთ, რაღაც უნდა გაკეთდეს, და ეს იმან უნდა გააკეთოს, ვინც სერვერზე პასუხისმგებელია, წინასწარ ცნობილი რიგით. ქვემოთ რა გამოვიდა და როგორ ვაახლებ მე.

რა გამოვიდა

Node.js-მა 21 ოქტომბერს უსაფრთხოების სამი რელიზი გამოუშვა: 26.12.1, 24.22.1 LTS და 22.23.4 LTS. 26.12.1 ცხრა CVE-ს ხურავს, 24.22.1 რვას, 22.23.4 შვიდს. ყველა ხაზში არის High დონის სისუსტეები: tls-ში არაკანონიკური IP მისამართების უარყოფა, dns-ში resolve-ის შემავალი მონაცემების შემოწმება ნულოვან ბაიტებზე და ხვრელი Brotli-ის გახსნაში, CVE-2026-111497. სამივე რელიზი root სერტიფიკატების სიას NSS 3.131.1-მდე აახლებს და დაბლოკილი საჯარო გასაღებების ჯაჭვებს უარყოფს. მიზეზს შენიშვნებში არ ასახელებენ, მაგრამ თარიღებით ეს eMudhra სასერტიფიკატო ცენტრის ამბავია, რომელზეც რამდენიმე დღით ადრე ვწერდი.

Python-მა 25 ოქტომბერს გამოუშვა 3.14.10 და 3.13.18. ორივე რელიზი დაჩქარებულია და სწორედ eMudhra-ს გამო: კომპრომეტირებულ გასაღებებს ახლა ssl მოდული ბლოკავს, და ჩვეულებრივი pip, თავად pip-ის განახლების ჩათვლით, დაცულია ამ გასაღებებით შეტევებისგან, მაშინაც კი, თუ pip ჯერ არ განუახლებიათ. 3.14.10-ში ამას გარდა დაახლოებით 120 შესწორებაა 63 მონაწილისგან და დახურული ხვრელი tarfile.tar_filter-ში, CVE-2026-114583. 3.13 განშტოება უკვე „მხოლოდ უსაფრთხოების შესწორებების“ რეჯიმშია 2028 წლის ოქტომბრამდე, ინსტალერები მისთვის აღარ გამოდის, მხოლოდ საწყისი კოდი.

Microsoft-მა 25 ოქტომბერს გამოუშვა .NET-ის გეგმის გარეშე განახლებები: 8.0.33, 9.0.22, 10.0.14 და .NET 11 RC3. იქ იგივე CVE-2026-111497 არის Brotli-ში, რაც Node.js-ში: ბუფერის გადავსება გახსნისას პროცესის მეხსიერების წაკითხვით ან დაზიანებით. .NET-ში ის მხოლოდ იქ მუშაობს, სადაც აპლიკაცია Brotli-ს ხსნის: ASP.NET Core-ის request decompression-ში, HttpClient-ის პასუხების ავტომატურ გახსნაში ან System.IO.Compression-ის გავლით. იქვე არის მოქმედებების სია, რომელიც არა მხოლოდ .NET-ს გამოადგება: framework-dependent აპლიკაციები რანთაიმს აახლებენ და გადაიტვირთებიან, self-contained ხელახლა იწყობა, კონტეინერები განახლებული იმიჯებიდან ხელახლა იწყობა.

Next.js-მა 23 ოქტომბერს გამოუშვა 16.4.3. ეს შესწორებების ბექპორტია აქტიურ LTS განშტოებაში, ახალი ფუნქციების გარეშე: მათ შორის Google-ის ფონტების URL და OpenTelemetry-ის ტრეისები. უსაფრთხოებაზე იქ არაფერია ნათქვამი. ჩემი საიტი kononov.dev Next.js-ზე და Node.js 24-ზე დგას, ასე რომ ეს განახლება იმავე ციკლში ხვდება, რაც Node.

რატომ გადადებენ განახლებებს

ავიღოთ 30 კაციანი სერვისული კომპანია. აქვს საიტი, გამყიდველების აპლიკაცია, ტელეფონია და დოკუმენტების პარსერები, და ეს ყველაფერი ერთ სერვერზეა. Node.js-ის განახლება ნიშნავს API-ს გადატვირთვას, რომლითაც საიტიც მუშაობს და აპლიკაციაც. დღისით კლიენტები რეკავენ, ღამით არავინაა, რომ მიხედოს, და განახლებას შემდეგ კვირაზე გადადებენ. ასე გადის თვე, მერე პატჩების შემდეგი პორცია გამოდის, და ერთბაშად ორი ვერსია უნდა გადაახტე.

დასკვნა: განახლებას გადადებენ, როცა ის რეპეტირებული არ არის. თუ რიგი ცნობილია და ერთ საათს იღებს, იმავე დღეს აკეთებენ.

როგორ ვაახლებ მე

ჩემი სერვერები: PDR კომპანია აშშ-ში, სადაც Debian-ზე Google Cloud-ში მუშაობს API Node.js-ზე, საიტი, ტელეფონია და დოკუმენტების პარსერები Python-ზე; საწარმოო კომპანია, სადაც შეკვეთების გაანგარიშება სერვერზე ცხოვრობს Node.js-ით და Express-ით PM2-ის ქვეშ; ჩემი საიტი Next.js-ზე და Node.js 24-ზე Docker-ში; და შიდა სერვისი „ყავა ერთად“ სტუდიის იმავე საერთო სერვერზე 2 GB მეხსიერებით. რიგი ყველგან ერთია.

პირველ რიგში ინვენტარიზაცია. ვიწერ, სად რა ვერსიის რანთაიმი დგას: სისტემაში, თითოეულ Docker იმიჯში, პარსერების ვირტუალურ გარემოში. ამ სიის გარეშე ვერ იტყვი, დახურულია თუ არა ჩვენთან ის, რაც რელიზში დახურეს.

შემდეგ ვკითხულობ, რა გაასწორეს, და ჩემს კოდს ვადარებ. Brotli იქ იხსნება, სადაც HTTP კლიენტი შეკუმშულ პასუხებს იღებს, ესე იგი ეს API-ს და ყველაფერს ეხება, რაც გარე სერვისებთან დადის. dns-ის ხვრელი ყველაფერს ეხება, რაც მომხმარებლის მონაცემებიდან მისამართებს არჩევს. ასე ნათელია, რა უნდა განახლდეს პირველად.

შემდეგ აწყობა. კონტეინერებისთვის ვცვლი საბაზო იმიჯს, ვაწყობ და აპლიკაციას ლოკალურად ვატარებ. სტუდიის სერვერზე აწყობას ზოგჯერ მეხსიერება არ ჰყოფნის, ამიტომ იმიჯი სერვერის გარეთ იწყობა და მზა იტვირთება. წინა იმიჯი ადგილზე რჩება, რომ იყოს, სად დავბრუნდე.

გაშვება. „ყავა ერთადში“ განახლებისას ძველი ეგზემპლარი ახლის გაშვებამდე ჩერდება: ორ ასლს 2 GB-ზე ვიწროა, ამიტომ კონტეინერებს მეხსიერების მკაცრი ლიმიტები აქვს. პარსერებისთვის ჯერ ვამოწმებ, რომ დამუშავებაში არაფერი კიდია, და მხოლოდ მერე გადავტვირთავ.

გაშვების შემდეგ ლოგებს ვუყურებ და ერთ სამუშაო სცენარს ხელით ვამოწმებ. თუ რამე არ არის წესრიგში, წინა იმიჯს ვაბრუნებ. როცა რიგი რეპეტირებულია, პატჩების მთელი კვირა საათებში ჯდება.

რას გავაკეთებდი თქვენს ადგილზე

ვკითხავდი იმას, ვინც სერვერს უძღვება, Node.js-ის, Python-ის ან .NET-ის რა ვერსიები გიდგათ და ზუსტად სად. თუ პასუხი ერთ დღეში არ არის, ეს პირველი პრობლემაა.

შევთანხმდებოდი განახლების ფანჯარაზე: როდის შეიძლება სისტემის გადატვირთვა და ვინ შეამოწმებს, რომ აიწია.

ვთხოვდი, რომ განახლება იმიჯების ხელახალი აწყობით წავიდეს და წინა ვერსია ხელთ დარჩეს.

ერთხელ ჩავწერდი რიგს. შემდეგ ასეთ კვირაში ის ისევ დაგჭირდებათ, და მაშინ განახლებას ერთი საათი წაიღებს.

იმაზე, როგორ გადაიტანენ ფონური ამოცანები გადატვირთვას: სტატია ვორკერები: ფონური ამოცანები და განმეორებითი ცდები. ინფრასტრუქტურა, რომლის გამოშვება და აღდგენა შესაძლებელია: DevOps და ინფრასტრუქტურა. სერვერი და API, რომლებზეც აქ არის საუბარი, აღწერილია ქეისში ტექნიკური პარტნიორობა PDR კომპანიასთან და გვერდზე საკუთარი API რამდენიმე აპლიკაციისთვის. ახლო მიმოხილვებიდან: PHP2Shell და საკუთარი სერვერების შემოწმება, განახლების დაზიანების რადიუსი და ბექაპი, რომელიც არავის აღუდგენია; ადრე ვწერდი Docker აპლიკაციის გამოშვებაზე ვერსიის დაბრუნებით. თუ სერვერი გაქვთ, განახლების რიგი კი არა, მომიყევით, რა დგას მასზე, და შემოგთავაზებ, საიდან დავიწყოთ. ამოცანის განხილვა.