Chyba v Node.js môže odhaliť súkromný TLS kľúč. Čo preveriť vo firme?

Čo Node.js opravil

CVE-2026-123864 je chyba s vysokou závažnosťou v spracovaní HTTPS. Podľa projektu môže klient bez prihlásenia za určitých podmienok prečítať údaje z pamäte procesu, ktoré patria inému spojeniu. Môže ísť o obsah požiadaviek ďalších používateľov aj o súkromný kľúč, ktorý server používa pri TLS. Na dosah chyby vplýva spôsob, akým aplikácia spracúva a vracia alebo ukladá prijaté údaje. Riziko preto závisí od konkrétnej konfigurácie služby.

Ten istý balík rieši aj samostatné chyby v HTTP/2. CVE-2026-123865 môže viesť k hromadeniu neuzavretých spojení a vyčerpaniu pamäte či dostupných súborových deskriptorov. Aplikácia môže postupne prestať prijímať ďalšie spojenia. Aj keď HTTPS ukončujete pred Node.js, stále si overte, akým protokolom proxy komunikuje s aplikáciou a či Node.js obsluhuje HTTP/2 na inom rozhraní.

Opravy aj oznámenie projektu sú datované 11. novembra 2026. Kórejský KrCERT/CC vydal odporúčanie na aktualizáciu 12. novembra a v ten istý deň o opravách informoval The Hacker News. Oznámenie Node.js neuvádza potvrdené zneužitie v prevádzke. Pri príprave článku sme nenašli potvrdený prípad úniku ani výpadku spôsobeného týmito chybami na Slovensku alebo v Česku.

Ako zistiť, či sa to týka vašej firmy

Začnite pri produkčných službách, ktoré prijímajú prevádzku z internetu alebo spracúvajú citlivé údaje. Zahrňte zákaznícke portály, API, prihlasovacie služby a integračné brány. Pri aplikáciách spravovaných dodávateľom požiadajte o verziu, dátum nasadenia a popis toku prevádzky. Rovnakú kontrolu urobte pri cloudovej službe, pri ktorej si verziu Node.js nastavujete sami.

1. Zistite bežiacu verziu. Overte ju priamo v nasadenej inštancii, kontajneri alebo konzole spravovanej služby. Príkaz node --version spustený na pracovnom počítači hovorí iba o jeho lokálnej verzii. Preverte aj staršie repliky a záložné prostredie.
2. Zmapujte ukončenie TLS. Ak certifikát a kľúč drží iba reverzná proxy či load balancer a backend používa obyčajné node:http, tento tok komunikácie nespadá pod uvedenú chybu HTTPS. Ak proxy vytvára ďalšie šifrované spojenie až do Node.js alebo možno backend osloviť priamo, posúďte aj túto cestu.
3. Overte konfiguráciu s vývojárom. Pri Node.js, ktorý obsluhuje HTTPS priamo, nech vývojár skontroluje dotknuté spracovanie požiadaviek podľa oficiálneho oznámenia. Na posúdenie potrebujete verziu, konfiguráciu a revíziu aplikácie nasadenú v čase expozície.

Pri kontrole sa oplatí porovnať produkciu a testovacie prostredie. Napríklad verejný portál môže ukončovať TLS na load balanceri, zatiaľ čo testovacia verzia má vlastný certifikát a je priamo dostupná partnerom. Zahrňte aj službu, ktorá beží mimo hlavného klastra kvôli staršej integrácii. V inventári sa často skrýva pod názvom aplikácie alebo dodávateľa.

V prehľade si pri každej službe poznačte, kto ju spravuje, odkiaľ je dostupná, kde je uložený súkromný kľúč a či máte záznamy z obdobia pred opravou. Získate podklady na rozhodnutie o aktualizácii aj o výmene kľúča.

Ako nasadiť bezpečnostnú aktualizáciu

Opravy z 11. novembra obsahujú vydania 22.23.5, 24.22.3 a 26.13.1. Použite príslušnú verziu alebo novšie opravené vydanie svojej podporovanej vetvy. Pri kontajneroch zostavte nový obraz a nasaďte ho do všetkých replík. Pri staršej vetve po skončení podpory naplánujte prechod na podporovanú verziu. Kým ho dokončíte, zvážte obmedzenie prístupu k dotknutej službe podľa toho, kto ju potrebuje používať.

Ak máte viac replík, opravte najprv jednu, overte ju a potom postupne vymeňte zvyšok. Skontrolujte prihlásenie, bežné API volania a spojenie medzi proxy a aplikáciou. Po nasadení sledujte pamäť, chybové odpovede a neočakávané reštarty. Ak máte záložné prostredie, aktualizujte ho pred tým, ako doň presmerujete prevádzku. Pri probléme s nasadením použite otestovaný postup obnovy, ktorý službu znova nevystaví zraniteľnej verzii.

Kedy vymeniť TLS kľúč a čo preveriť v záznamoch

Ak bol zraniteľný HTTPS proces dostupný nedôveryhodným klientom, spĺňal podmienky chyby a mal súkromný kľúč v pamäti, posúďte ho ako potenciálne ohrozený. Po uzavretí expozície vytvorte nový pár kľúčov a vydajte certifikát s novým kľúčom. Zabezpečte výmenu na všetkých miestach, ktoré používali rovnaký kľúč, a pri podozrení na kompromitáciu požiadajte certifikačnú autoritu o zneplatnenie pôvodného certifikátu.

Pri výmene si s vlastníkmi integrácií potvrďte, ktoré služby používajú certifikát na overenie identity servera. Po nasadení overte, že každý koncový bod predkladá nový certifikát a že pripojenia partnerov fungujú aj po výmene.

Uchovajte záznamy proxy, aplikácie a nasadení. Zosúlaďte časové údaje a preverte neobvyklé chyby, výpadky, nárast pamäte aj podozrivé použitie relácií alebo tokenov v čase expozície. Bežné záznamy spravidla neukazujú, aké údaje boli v pamäti procesu. Pri dôvodnom podozrení zapojte tím reakcie na incident a podľa rozsahu posúďte zneplatnenie dotknutých relácií či výmenu tokenov. Obsah požiadaviek a súkromné kľúče kvôli kontrole nepridávajte do logov.

Čo si má vedenie nechať potvrdiť

• Ktoré služby používali dotknutý Node.js a kto mal k nim prístup.
• Kedy dostali opravu všetky produkčné aj záložné inštancie.
• Kde sa ukončovalo TLS a ako IT posúdilo potrebu výmeny kľúčov alebo tokenov.