213 javítás a Chrome 157-ben – és a többi böngésző?

Mit kapott a Chrome 157 (és mit nem ír a Google)

A Chrome Releases blogon 2026. november 3-án, kedden jelent meg a Stable Channel Update for Desktop című bejegyzés. A verziószámok: Linuxon 157.0.8103.38, Windowson és macOS-en 157.0.8103.38, illetve 157.0.8103.39. A bejegyzés a szokásos fordulattal írja le, mennyi hiba zárult le a kiadással: „This update includes 213 security fixes.” Ez kiugróan sok egyetlen stabil kiadáshoz; a bejegyzés hibalistáját végigszámolva a 213 ki is jön, szóval nem elírás a Google oldalán.

A súlyosság szerinti megoszlás – ha összeadjuk a bejegyzés saját címkéit – a következő: 7 kritikus, 77 magas, 75 közepes és 54 alacsony besorolású hiba. Vagyis a 213-as szám nem 213 egyformán vészes sebezhetőséget jelent: a nagy része közepes vagy alacsony kockázatú. Arról, hogy ezek a hibák honnan kerülnek elő, a bejegyzés egy állandó megjegyzést tesz: „Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.” Vagyis a Chrome biztonsági hibáinak nagy részét a projekt saját, automatizált elemző- és fuzzolóeszközei találják meg – ezt azonban a Google általánosságban írja le, nem erre a kiadásra lebontva.

Két dolgot érdemes kiemelni arról, amit a bejelentés nem tartalmaz. Az egyik: nincs benne utalás arra, hogy bármelyik hibát éles támadásban kihasználták volna. A Chrome-bejelentésekben erre a Google egy jól bevált fordulatot használ, amikor van ilyen eset – ebben a mostani szövegben ez a fordulat nem szerepel egyszer sem. Ez nem garancia semmire, de azt jelenti, hogy a kiadás pillanatában a Google nem tud ismert, aktív kihasználásról. Nem kell tehát pánikolni és nem kell azonnal mindent félretenni; frissíteni viszont érdemes, méghozzá ma.

A másik: a bejelentés nem írja le, milyen támadásra adnak lehetőséget a hibák. Minden tételhez kikerül a CVE-azonosító, a besorolás, a hiba típusa és az érintett komponens neve, a bejelentő, a bejelentés dátuma és a kifizetett jutalom – a hiba leírása viszont nem. Ez a Chrome-nál szándékos gyakorlat, és a bejegyzés ki is mondja: „Access to bug details and links may be kept restricted until a majority of users are updated with a fix.” Vagyis a részletekhez való hozzáférés korlátozott maradhat, amíg a felhasználók többsége meg nem kapta a javítást. Ebből az következik, hogy a „mennyire vagyok veszélyben, ha még nem frissítettem” kérdésre kívülről senki nem tud pontos választ adni – ezért érdemes a frissítést egyszerűen letudni.

A kiadás nem egyszerre érkezik meg mindenkihez. A Google maga írja, hogy a verzió a következő napokban-hetekben jut el a felhasználókhoz. Ez a fokozatos kiosztás azt jelenti, hogy ha ma megnyitod a Chrome frissítési oldalát, és még a 156-os sorozatot látod, az nem hiba: a frissítés egyszerűen még nem jutott el a gépedhez. A jó hír, hogy a kézi ellenőrzés általában előre is hozza, erről a cikk végén részletesen írunk.

Androidon ugyanazon a napon jelent meg a Chrome for Android Update bejegyzés a 157-es verzióval (157.0.8103.38). A Google itt azt is jelzi, hogy az androidos kiadások ugyanazokat a biztonsági javításokat tartalmazzák, mint a megfelelő asztali kiadás – azzal a megszorítással, hogy ha ez valahol másképp van, azt külön jelölik. Androidon viszont nem a böngésző frissíti magát, hanem a Play Áruház, úgyhogy ott a Play Áruház Alkalmazások és eszköz kezelése menüpontjában látszik, van-e várakozó Chrome-frissítés.

Egy apró zavaró körülmény: november 4-én megjelent egy Early Stable Update for Desktop bejegyzés is, amely a Windows-felhasználók kis részét már a 158.0.8127.18, illetve .19 verzióra állítja. Ebben a bejegyzésben nincs biztonsági tartalom. Ha tehát valaki 158-as Chrome-ot lát a gépén, az nem hiba: az early stable a következő főverzió előreengedett szelete, amelyet a Google a felhasználók egy kisebb hányadának ad meg a széles körű kiadás előtt. Azt, hogy pontosan mely javítások vannak benne, ez a bejegyzés nem sorolja fel.

A hét kritikus hiba – és hol vannak

A 213 javításból hetet minősített kritikusnak a Google. A Chrome-nál a kritikus besorolás nagyjából azt jelenti, hogy a hiba elvben kitörhet a böngésző védett homokozójából, vagyis a megnyitott weboldal kódja hatást gyakorolhat magára a gépre. Ezért érdemes megnézni, hol vannak ezek a hibák – mert a hét közül négy ugyanarra a területre esik: a grafikus réteg környékére.

A CVE-2026-121156 puffertúlcsordulás a Dawn nevű komponensben, és ezért fizette a Google a kiadás legnagyobb jutalmát, 10 000 dollárt. A CVE-2026-121247 szintén puffertúlcsordulás ugyanitt, a Dawnban, ezt a Google saját csapata jelentette. A Dawn a Chromium WebGPU-megvalósítása: ez az a réteg, amely a weboldalak kódját a videokártya képességeihez engedi hozzá. A CVE-2026-121229 memóriasérülés az ANGLE-ben – ez a komponens fordítja le a weboldalak grafikus hívásait arra, amit az adott rendszer grafikus API-ja megért, Windowson a Direct3D-re, macOS-en a Metalra. Érte 1000 dollár jutalom járt. A negyedik grafikai hiba, a CVE-2026-121246, felszabadítás utáni használat a WebGL-ben, vagyis abban az API-ban, amelyen keresztül a böngészőben futó háromdimenziós tartalom működik; ezt is a Google jelentette.

Hogy miért éppen itt sűrűsödnek a kritikus hibák, annak prózai oka van. A grafikus réteg az a kevés hely, ahol egy weboldal kódja a lehető legközelebb jut a hardverhez és az illesztőprogramokhoz, és ahol a számítások teljesítményokokból nagyon kevés ellenőrzéssel futnak. Ezért a támadók és a hibakeresők is itt kutatnak a legszívesebben.

A maradék három kritikus hiba a böngészőmotor belső rétegeiben van. A CVE-2026-121035 felszabadítás utáni használat a Prerender komponensben – ez az a mechanizmus, amely a valószínűnek tartott következő oldalt már a kattintás előtt elkezdi betölteni a háttérben. A bejelentőnél ez áll a bejegyzésben: „Reported by Xinyang Ge (Anthropic), assisted by Claude on 2026-09-28”, vagyis a munkát MI-modell segítette. És ez nem elszigetelt eset: a 213 tételből 14-nél olyan bejelentő szerepel, akinek a neve mellett ott van az Anthropic és az „assisted by Claude” megjegyzés. A nagy böngészőmotorok hibakeresésében tehát egyre nagyobb szerepet kapnak az MI-vel támogatott bejelentések.

A CVE-2026-121203 felszabadítás utáni használat a Geometry, a CVE-2026-121126 pedig ugyanilyen típusú hiba a Core komponensben. A Geometry az oldal elemeinek méretét és elhelyezését számolja ki, vagyis olyan kód, amely minden megnyitott weboldalon lefut. A Core ennél jóval általánosabb gyűjtőnév a motor belsejében: a Google ehhez a komponenshez a mostani listán egészen másfajta hibákat is sorol, és közelebbi leírást nem ad róla.

Három hibatípus tér vissza a listán, és érdemes tudni, mit jelentenek. A felszabadítás utáni használat azt, hogy a program egy már eldobott memóriaterületre hivatkozik tovább; ha a támadó pontosan időzíti, mi kerül közben arra a helyre, befolyásolhatja a program működését. A puffertúlcsordulás azt, hogy a kód több adatot ír egy területre, mint amennyi elfér benne, és így a szomszédos adatokat írja át. A memóriasérülés ennek a tágabb kategóriája. Ezeknél a hibatípusoknál a kiindulópont jellemzően ugyanaz: elég egy megnyitott weboldal, nem kell letölteni és futtatni semmit. Hogy a mostani hét hibánál pontosan így van-e, kívülről nem ellenőrizhető, mert a Google a részleteket nem közli.

Egy fontos megjegyzés a jutalmakhoz: a kifizetett összegből nem lehet kiolvasni, melyik hiba a veszélyesebb. A listán két 10 000 dolláros bejelentés van, és a kettő közül csak az egyik kritikus – a másik egy magas besorolású hiba a BackgroundFetch komponensben. A hét kritikus hiba között pedig az 1000 dolláros ANGLE-bejelentés ugyanabba a kategóriába esik, mint a 10 000 dolláros Dawn-hiba. Ráadásul 39 tételnél a jutalom még „TBD”, vagyis el sem dőlt, a Google saját csapata által jelentett hibáknál pedig eleve nem szerepel összeg.

Miért érint ez több böngészőt egyszerre

A Google Chrome nem egyedül használja azt a kódot, amelyben ezek a hibák vannak. A Chromium nyílt forráskódú projekt, és ma a legnépszerűbb asztali böngészők többsége erre épül: az Edge, a Brave, az Opera, a Vivaldi és – még néhány hétig – az Arc is. A gyártók a Chromium-alapot átveszik, ráteszik a saját felületüket, hirdetésszűrőjüket, szinkronizálásukat és egyéb szolgáltatásaikat, aztán időről időre újabb Chromium-verzióra ültetik át az egészet. Ez az átültetés nem automatikus és nem azonnali.

Ebből következik a cikk alapkérdése. Amikor a Google kiad egy biztonsági javítást, az a Chrome-felhasználókhoz napok alatt eljut, a többi böngésző felhasználóihoz viszont csak akkor, amikor az adott gyártó a saját kiadási ütemében rálép az új Chromium-alapra. Van, aki ezt néhány napon belül megteszi, van, aki négyhetes ciklusban dolgozik, és van, aki szándékosan egy lassabban mozgó, hosszabban támogatott Chromium-ágon marad.

Fontos azonban, hogy ezt ne fordítsuk le rögtön „akkor a Brave és a Vivaldi most sebezhető” típusú kijelentésre, mert az nem igaz. Két dolog miatt sem. Egyrészt a gyártók visszaültethetnek egyes javításokat a saját, régebbi alapjukra anélkül, hogy a Chromium-főverziószámot emelnék – a verziószámból tehát nem lehet biztonsági állapotot kiolvasni. Másrészt a Chromiumnak van egy úgynevezett Extended Stable ága, amely a sima stabil csatorna négyhetes ritmusa helyett nyolchetes főverziós ciklusban mozog. A projekt dokumentációja szerint a cél az, hogy a fontos biztonsági javításokat ide is visszaültessék – a nagyobb, összetettebb biztonsági fejlesztések viszont csak a sima stabil csatornára kerülnek. Aki ilyen ágon van, annak tehát alacsonyabb a Chromium-főverziószáma, miközben a biztonsági javítások nagy része már nála is ott van.

Amit tehát a verziószámokból ki lehet olvasni, az nem az, hogy ki van veszélyben, hanem az, hogy ki hol tart a sorban – és hogy a saját gyártója mit közöl erről nyilvánosan. A következő három szakaszban pontosan ez van: mit írnak a gyártók a saját oldalukon, 2026. november 6-i állapot szerint.

Egy szempont, amiért a sorrend egyáltalán számít: a Chromium nyílt forráskódú, így amikor a javítás bekerül, a változás a forrástörténetben követhetővé válik. A Google ugyan zárva tartja a részletes hibaleírásokat, de a kódbeli javítás maga nyilvános. Ez a szakmában régóta ismert helyzet: a javítás megjelenése és a lassabb gyártók kiadása közötti idő az, amikor a hiba már leírható, de még nem mindenkinél van orvosolva. Ez nem jelent közvetlen veszélyt egy átlagos felhasználóra, de magyarázza, miért nem mindegy, hogy egy böngésző néhány napot vagy néhány hetet késik.

A mobilos helyzet egészen más. Androidon a Chromium-alapú böngészők a Play Áruházon keresztül frissülnek, és mindegyik a saját, beépített motorjával jelenít meg oldalakat. Van emellett egy külön rendszerkomponens, az Android System WebView: ezt azok az alkalmazások használják, amelyek a saját felületükön nyitnak meg weboldalakat. Ez is a Play Áruházból frissül, külön tételként – vagyis a WebView frissítése nem a böngésződet, hanem a többi alkalmazás beépített weblapmegjelenítőjét javítja. iOS-en pedig a gyakorlatban mindegyik böngésző az Apple rendszerbe épített WebKit-motorjával jelenít meg oldalakat – az Apple az EU-ban elvben 2024 óta engedélyez más motort is, de a nagy böngészők ezzel a gyakorlatban nem éltek. Vagyis az iPhone-os Chrome, Edge vagy Brave nem ugyanazt a megjelenítő kódot futtatja, mint az asztali párja. A motor biztonsági javításai ezért a rendszerfrissítésekkel érkeznek, nem a böngésző frissítésével – maguk a böngészőalkalmazások persze továbbra is kapnak frissítést az App Store-ból. Ha tehát iPhone-on olvasod ezt: itt nem csak a böngészőt, hanem elsősorban az iOS-t érdemes frissíteni.

A böngészők közötti különbségekről, a motorokról és arról, hogy melyik mire jó, külön nagy összehasonlítást írtunk: Legjobb böngészők 2026 – nagy összehasonlítás magyarul.

Edge: a Microsoft saját oldala szerint még készül a javítás

A legérdekesebb eset a Microsoft Edge, mert itt nem kell találgatni: a Microsoft külön oldalt tart fenn az Edge biztonsági frissítéseiről, és ott maga írja le, hol tart. A Release notes for Microsoft Edge Security Updates oldal legfrissebb bejegyzése november 3-i keltezésű, és így szól: „Microsoft is aware of the recent Chromium security fixes. We are actively working on releasing a security fix.” Magyarul: a Microsoft tud a friss Chromium-javításokról, és dolgozik a biztonsági frissítés kiadásán. Verziószám, dátum és határidő nincs mellette.

Ez nem drámai bejelentés: a Microsoft ezzel a formulával jelzi, hogy az upstream javítás megjelent, a saját kiadása viszont még nincs kész. Attól azonban még ez őszinte beismerése annak, hogy az Edge-felhasználóknál a javítás a cikk írásakor még nem volt elérhető. Az oldal utolsó módosítása november 3-i, és november 6-án újra megnéztük: a bejegyzés változatlan volt.

A legfrissebb tényleges Edge Stable kiadás, amely ezen az oldalon szerepel, a 156.0.4314.58, október 30-i dátummal. Ennél a tételnél egy másik árulkodó megjegyzés is ott van: „Note: CVE’s will be added as soon as available.” Vagyis a Microsoft kiadta a frissítést, de a benne javított sebezhetőségek azonosítóit még nem sorolta fel – és amikor ezt a cikket írtuk, még mindig nem voltak ott. Ez a mobilos kiadásoknál is hasonló: november 2-án az androidos és iOS-es Edge a 156.0.4314.56-os verziót kapta meg.

Mikor várható a 157-es Edge? A Microsoft kiadási menetrendje is nyilvános, és abban az Edge 157 Stable a november 5-i hétre van betervezve. Ugyanez az oldal azt is leszögezi, hogy a dátumok közelítőek, és a build állapotától függően változhatnak. A menetrend egy másik részlete itt hasznos háttér: „Starting with Stable channel version 152, Microsoft Edge is moving to a 2-week major release cycle cadence.” Az Edge tehát a 152-es verzió óta kéthetes főverziós ritmusban dolgozik – vagyis sűrűbben ad ki főverziót, mint amilyen ütemben a Chrome érkezik.

Két dolgot érdemes ebből leszűrni. Az egyik: ne írjuk azt, hogy a Chrome 157 és az Edge 157 egyszerre jött ki, mert nem. A Chrome 157 Stable november 3-án már elérhető volt, az Edge 157 Stable ugyanakkor még céldátumként szerepelt a Microsoft menetrendjében. A másik: ha Edge-et használsz, érdemes a következő napokban többször ránézned a frissítésre. A kéthetes ritmus miatt a 157 nagy valószínűséggel pár napon belül megérkezik, de ettől még a te gépedre nem kerül fel magától azonnal – a lépcsőzetes kiosztás itt is működik.

Addig is van értelme kézzel ellenőrizni. Az Edge-ben az edge://settings/help cím beírása egyszerre megmutatja a telepített verziót és elindítja a frissítéskeresést. Ha ott a 156-os sorozatot látod, akkor a Microsoft saját közlése szerinti állapotban vagy: a frissítés készül.

Brave, Opera, Vivaldi, Arc – hol tartanak

A Brave legfrissebb kiadása a saját kiadási jegyzete szerint az 1.98.63, október 30-i dátummal, és a jegyzetben ott van a számunkra érdekes sor is: „Upgraded Chromium to 156.0.8078.80.” A Brave tehát a 156-os Chromium-ágon áll, és a projekt a nagyobb kiadásokat körülbelül négyhetes ciklusban adja ki. Ez a gyakorlatban azt jelenti, hogy a Chrome 157 javításait tartalmazó Brave-kiadás a következő hetekben várható – a pontos dátumot a Brave nem jelzi előre.

Az Opera november 4-én adott ki frissítést, a 139.0.6053.38-as verziót. Érdekes részlet, hogy ez a bejegyzés egyáltalán nem írja le, melyik Chromium-alapon áll a kiadás. A visszakeresés viszont segít: az Opera 139 bemutatásakor, október 27-én a gyártó még azt írta, hogy „Chromium is updated to 155.0.8059.85 and the major version is bumped to 139.” Vagyis az Opera a 139-es sorozatot a 155-ös Chromium-alapra építette, és a november 4-i javítókiadásnál nem közölt új alapverziót. Ebből nem lehet biztosan tudni, mi került bele – de azt sem lehet állítani, hogy az Opera már a 157-es javításoknál lenne. Az Opera GX külön sorozatként, saját verziószámokkal fut – aki GX-et használ, annak a böngésző saját frissítési oldalán kell megnéznie, hol tart.

A Vivaldi november 5-én jelentette be a 8.3-as verziót, majd november 6-án jött hozzá egy kisebb javítás. A bejelentés itt sem ír Chromium-alapverziót, de kideríthető: a 8.3-at előkészítő, október 19-i fejlesztői kiadásnál a Vivaldi azt írta, hogy „[Chromium] Update to 156.0.8078.35”. A 8.3-as sorozat tehát a 156-os Chromium-ágra épül – ugyanarra, amelyen a Brave is áll. A Vivaldi egyébként jó példa arra, miért félrevezető a verziószám: a megelőző, 8.2-es sorozatnál a gyártó maga magyarázta el, hogy a Chromium 152-es, Extended Stable kiadására álltak át, amely „in turn includes security fixes from upstream Chromium 156”, vagyis magában hordozza a frissebb Chromium-ágak biztonsági javításait.

Az Arc esete más okból érdekes, és ez most a legfontosabb hír a listán. Az Arc gyártója bejelentette, hogy megszünteti a böngészőt: a korábbi kezdőoldal helyén ma egy búcsúszöveg és egy kérdés-válasz rész áll, amelyben pontos dátum is van: „On December 22, 2026, Arc for macOS and Windows will stop working, and you will no longer be able to sign in to your Arc account.” Vagyis december 22-én nem csak a böngésző áll le, hanem az Arc-fiókba sem lehet többé belépni. Addig a gyártó közlése szerint az Arc a megszokott módon működik, és „basic updates”, vagyis alapvető frissítéseket kap. Azt a gyártó nem írja le, hogy ez pontosan mit jelent biztonsági frissítések tekintetében, és az Arc nyilvános verziószámait sem lehet ma kívülről követni. Ha valaki Arcot használ, ebből két dolog következik: egyrészt a Chromium-javítások ütemét itt nem lehet ellenőrizni, másrészt amúgy is érdemes másik böngészőre átállni még karácsony előtt, mert az Arc december 22-én egyszerűen leáll.

A ChatGPT Atlas esetében pedig már múlt időt kell használni. Az OpenAI saját súgócikkében ez áll: „Atlas is scheduled to stop working on August 9, 2026.” Vagyis az OpenAI ütemezése szerint a böngésző 2026. augusztus 9-én leállt, és a cég a bemutatóoldalára is kitett egy utólagos megjegyzést arról, hogy az Atlast megszüntették. A súgócikk azt is leírja, mit kellett a leállás előtt elintézni. A könyvjelzőkről például ezt írja: „Bookmarks will not transfer automatically.” Vagyis azokat exportálni, majd egy másik böngészőbe importálni kellett. Az Atlas tehát nem késik a Chromium-javításokkal – egyszerűen nem fut többé.

A DuckDuckGo böngészője annyiban kilóg a sorból, hogy a projekt egyáltalán nem tesz közzé verziószámot az asztali kiadásokhoz, és azt sem írja le nyilvánosan, melyik motorra épül az adott platformon. Itt tehát nem arról van szó, hogy késik vagy nem késik: a gyártó oldalain egyszerűen nincs mit ellenőrizni.

Ha pedig valaki azért vált böngészőt, mert elege lett a beépített MI-funkciókból, arról is írtunk külön útmutatót: Eleged lett az MI-ből a böngészőben? Így kapcsolod ki mindegyikben.

A Firefox-alapúak (LibreWolf, Floorp, Zen, Tor) más helyzetben vannak

Van a böngészőknek egy másik csoportja, amelyet ez a 213 javítás egyáltalán nem érint: azok, amelyek nem a Chromiumra, hanem a Mozilla Firefoxra épülnek. A Firefox saját motort használ, a Chromium hibái tehát nincsenek benne – ahogy a Firefox hibái sincsenek benne a Chrome-ban. Ez technikai alapvetés, nem valamiféle minőségi rangsor: a két kódbázis külön fejlődik, és mindkettőben vannak hibák.

A Firefox oldalán is éppen most jött frissítés. A 159.0.1-es verzió ugyanazon a napon, november 3-án jelent meg, és tartozik hozzá biztonsági közlemény is: az MFSA 2026-123 címe „Security Vulnerabilities fixed in Firefox 159.0.1”, hatása a Mozilla minősítése szerint magas. Egyetlen hiba van benne, a CVE-2026-120572, amelyet a közlemény így ír le: „Incorrect boundary conditions in the Layout: Block and Inline component”, vagyis helytelen határellenőrzés az oldalszerkezetet számoló komponensben. A bejelentő maga a Mozilla, kritikus besorolású hiba nincs a listán, és aktív kihasználásról ez a közlemény sem ír.

Itt ne essünk abba a hibába, hogy összehasonlítjuk a 213-at az eggyel. A kettő nem ugyanazt méri. A Firefox 159.0.1 egy apró javítókiadás, amely a nagy, 159.0-s kiadás után jött ki egyetlen hibával; a nagyobb sebezhetőségcsomagot a Firefoxnál a főverziók hozzák, a Chrome 157 pedig éppen egy főverzió. Ráadásul a Google és a Mozilla másképp csomagolja és másképp számolja a hibákat, és a Chrome listájának jelentős része belső, automatizált hibakeresésből származik. A számok közti különbség tehát nem fordítható le arra, hogy melyik böngésző biztonságosabb.

Ami a Firefoxra épülő böngészőket illeti, ott a mostani helyzet kivételesen jól áll. A LibreWolf november 4-én adta ki a 159.0.1-1-es verziót, és a kiadási jegyzet rövid, de beszédes: „Upstream release, see the Firefox 159.0.1 Release Notes”, mellette pedig annyi áll, hogy a LibreWolf oldalán nincs említésre méltó változás. Vagyis a LibreWolf egy nappal követte a Mozillát. A Floorp ugyanazon a napon, november 4-én adta ki a 12.21.1-es verziót, és a kiadási jegyzet kimondottan leszögezi, hogy a kiadás tartalmazza a Firefox 159.0.1 biztonsági javítását.

A Zen Browser egy fokkal hátrébb van. A projekt legfrissebb kiadása az 1.24b, amely a projekt saját oldalán október 28-i, a GitHubon október 29-i dátummal szerepel – ez valószínűleg időzóna-különbség. A kiadás jegyzetében ez áll: „Updated to Firefox 159.0”. Vagyis a Zen a 159-es főverziónál tart, de a november 3-i 159.0.1-es javítókiadást a cikk írásakor még nem adta ki. Egy javítókiadással van tehát lemaradva, nem hetekkel. A Zen kiadási ritmusa a saját jegyzékének dátumai alapján nagyjából heti, és a frissebb Firefox-verziókat általában néhány napon belül átvette, úgyhogy itt rövid várakozásra lehet számítani. Azt viszont érdemes tudni, hogy a projekt nem közöl nyilvános szabályzatot arról, hogyan és milyen határidővel veszi át a Firefox biztonsági javításait.

A Tor Browser megint más logika szerint működik, és ezt sokan félreértik. A Tor Browser 16.0 október 29-én jelent meg, és a Tor Project maga írja róla: „This is our first stable release based on Firefox ESR 153, incorporating a year’s worth of changes that have been shipped upstream in Firefox.” A változásnaplóban pedig szerepel, hogy a Firefoxot a 153.6.0esr verzióra frissítették. Az ESR, vagyis a kiterjesztett támogatású kiadás egy szándékosan lassabban mozgó Firefox-ág, amelybe a Mozilla visszaülteti a biztonsági javításokat. A 153-as szám tehát nem azt jelenti, hogy a Tor Browser hat főverziót késik a biztonsági javításokkal. Hasonló a logika, mint a Chromium Extended Stable ágánál, csak jóval hosszabb időskálán: a Tor Project maga írja, hogy a 16.0 egy év felhalmozott változásait hozza.

A Mullvad Browser jelenlegi verziója a letöltőoldal szerint 16.0, dátum nélkül. Azt a Mullvad nem közli, melyik Firefox-verzióra vagy melyik Firefox-ágra épül a kiadás, és azt sem írja le, ki fejleszti. Annyit ír: „The Mullvad Browser has the same fingerprinting protection as the Tor Browser – it just connects to the internet with (or without) a VPN instead of the Tor Network.” Vagyis ugyanazt az ujjlenyomat-védelmet adja, mint a Tor Browser, csak nem a Tor-hálózaton keresztül kapcsolódik. A verziószám egyezése a Tor Browserrel sok mindenre utalhat, de a gyártó oldalairól nem lehet megállapítani, hol tart a Firefox biztonsági javításaival.

30 másodperc: így nézed meg és erőszakolod ki a frissítést

A legtöbb böngészőnél ugyanaz a három lépés működik, és valóban elég rá fél perc. Először megnyitod a böngésző névjegy- vagy frissítési oldalát. Ennek már a megnyitása elindítja a frissítéskeresést – ez a lényeg, mert a háttérben futó automatikus ellenőrzés ritkábban fut le. Másodszor megvárod, amíg a letöltés végez. Harmadszor rákattintasz az Újraindítás gombra, mert a letöltött verzió csak az újraindítás után lép életbe.

A gyorsabb út az, ha a címsorba beírod a megfelelő belső címet. Böngészőnként ezek a címek:

Chrome: chrome://settings/help – a Chrome névjegye, egyben frissítéskeresés
Edge: edge://settings/help
Brave: brave://settings/help
Vivaldi: vivaldi://about, a frissítéskeresés pedig a menü Súgó részében indul
Opera: opera://update – ez közvetlenül a Frissítés és visszaállítás oldalt nyitja meg
Firefox, Floorp, Zen: a menü Súgó menüpontjában a névjegy megnyitása indítja a keresést, a verziószám pedig megjelenik ugyanott

Linuxon érdemes tudni, hogy a Brave és a Vivaldi nem tartalmaz beépített frissítőt: ezek az oldalak ott megmutatják a verziót, az új csomag viszont a terjesztés csomagkezelőjéből érkezik.

Néhány böngésző kivétel. A LibreWolf nem minden platformon keres magától frissítést: jellemzően a telepítéshez használt csomagkezelőn vagy a projekt saját kiadási listáján keresztül érkezik az új verzió, úgyhogy ha ezt használod, érdemes a csomagkezelővel ellenőrizni. A Tor Browser és a Mullvad Browser pedig saját frissítési mechanizmust használ, amely a menü Súgó részéből indítható – ezeknél különösen fontos, hogy a frissítést soha ne máshonnan töltsd le, csak a projekt saját oldaláról.

Mobilon másképp működik a dolog. Androidon nem a böngésző frissíti magát, hanem a Play Áruház: a profilképre koppintva, az Alkalmazások és eszköz kezelése menüpontban látszik, van-e várakozó frissítés, és ugyanitt érdemes megnézni az Android System WebView nevű tételt is, amelyet sok alkalmazás használ weboldalak megjelenítésére. iPhone-on és iPaden az App Store frissítései mellett a legfontosabb a rendszerfrissítés, mert – ahogy a cikk korábbi szakaszában írtuk – az iOS-es böngészők a rendszer saját motorjával dolgoznak.

Mi van akkor, ha a frissítési oldal azt mondja, naprakész vagy, de a verziószám alapján mégsem a 157-es sorozatnál tartasz? Ez teljesen normális. A Google maga írja, hogy a kiadás napok-hetek alatt jut el a felhasználókhoz, és ezt a lépcsőzetes kiosztást kívülről nem lehet megkerülni. Ilyenkor az a helyes lépés, hogy másnap újra megnyitod a frissítési oldalt. Amit viszont semmiképp nem érdemes: idegen oldalakról letöltött telepítőt keresni, vagy valamilyen „frissítőprogramot” telepíteni. A böngészőfrissítés nevében terjesztett kártevő az egyik legrégebbi és még ma is működő trükk; a frissítés kizárólag a böngésző belsejéből, a gyártó saját oldaláról, a rendszer csomagkezelőjéből vagy a telefon alkalmazásáruházából jöhet.

Ha céges gépet használsz, van még egy magyarázat: a vállalati házirend gyakran késleltetve vagy központilag engedi be a frissítéseket, és ilyen gépen a frissítési oldalon többnyire megjelenik egy sor arról, hogy a beállítást a szervezet kezeli. Ezt nem tudod és nem is érdemes megkerülni – ilyenkor a rendszergazdáé a labda.

Arról, hogy miért nem elég egyszer bekapcsolni az automatikus frissítést, és miért fut mégis sok gép hónapokig régi verzióval, külön cikkünk is van: Frissül magától a böngésződ – de attól még a régi verziót futtatod.

Amit érdemes tudni a bezárás-újraindítás csapdájáról

Ez az a pont, ahol a legtöbb frissítés elakad, és ezért érdemes külön beszélni róla. A böngésző a frissítést csendben letölti, de a már futó programban nem tudja aktiválni: ahhoz a folyamatot le kell állítani és újra el kell indítani. A frissítési oldalon megjelenő Újraindítás gomb pontosan ezt teszi. Amíg nem nyomod meg, a gépen ott van az új verzió, de a régi fut.

A csapda abban van, hogy a böngésző bezárása nem mindig jelenti a leállítását. Windowson a Chrome-nak van egy beállítása, amely a háttéralkalmazások futtatását a böngésző bezárása után is engedi; ha ez be van kapcsolva, az ablak bezárása után a Chrome a tálca értesítési területén tovább él, és a frissítés addig nem lép életbe, amíg a folyamat tényleg le nem áll. Ugyanez a helyzet az Edge-ben, ahol két ilyen beállítás is van: az indítási gyorsítás és a háttérben futó bővítmények engedélyezése. Mindkettő a sebességet szolgálja, de mindkettő megakadályozhatja, hogy a böngésző valóban leálljon, és így az új verzióval induljon el.

macOS-en ennek a klasszikus változata, hogy az ablakot a piros bezárás gombbal becsukva nem léptetsz ki az alkalmazásból – az továbbra is fut a Dockban. Ott a Cmd+Q, vagyis a kilépés az, ami valóban leállítja a programot.

Van egy harmadik, a leggyakoribb változat is: a laptopot sokan nem állítják le, csak lecsukják. Ilyen használatnál a böngésző hetekig futhat megszakítás nélkül, és közben két-három frissítés is letöltődhet anélkül, hogy bármelyik érvénybe lépne. Ha ismerős a helyzet, érdemes most megnyitni a frissítési oldalt: nem kizárt, hogy ott egy kész, csak újraindításra váró frissítés fogad.

Miért nem nyomja meg mégsem senki azt a gombot? Általában azért, mert sok lap van nyitva, és félünk, hogy elveszik a munka. Ez a félelem nagyrészt alaptalan: az újraindítás a megnyitott lapokat és ablakokat visszatölti, és a Google súgója is ezt írja le normál működésként. Két dolog viszont valóban nem jön vissza. Az egyik az inkognitó- vagy privát ablakok tartalma, amelyeket a böngésző szándékosan nem állít vissza – a Google súgója ezt külön le is szögezi. A másik a félig kitöltött űrlapok, megírt, de el nem küldött hozzászólások és beírt szövegek tartalma – ezek megőrzése nem garantált. Ha tehát épp írsz valamit valahol, azt küldd el vagy mentsd ki, és csak utána indíts újra.

Az újraindítás után van még egy fontos lépés, amit szinte mindenki kihagy: nézd meg újra a verziószámot. Ez az egyetlen igazi visszaigazolás. A Chrome-nál a 157-es sorozatot kell látnod, a cikk írásakor konkrétan a 157.0.8103.38-at vagy a .39-et. Ha a frissítési oldalon továbbra is 156-os számot látsz, akkor vagy a lépcsőzetes kiosztás miatt nem érkezett még meg hozzád, vagy a böngésző valójában nem indult újra – a kettő között éppen a verziószám dönt.

Végül egy jelzés, amit érdemes felismerni. A Chrome a hárompontos menüben jellemzően külön sorral és színes jelöléssel figyelmeztet, ha egy letöltött frissítés újraindításra vár. A Google súgója a másik irányból fogalmaz: ha a menüben nem találod az Újraindítás lehetőséget, akkor a legfrissebb verziót futtatod. Ha ezt a jelölést látod a menüben, az nem reklám és nem hiba: szó szerint azt jelenti, hogy a javítás ott van a gépeden, csak még nem használod.

Összefoglalva: ha Chrome-ot használsz, nyisd meg a frissítési oldalt, és indítsd újra a böngészőt – ezzel megvagy. Ha Edge-et, akkor a Microsoft saját közlése szerint a javítás még készül, úgyhogy a következő napokban nézz rá újra. Ha Brave-et, Operát vagy Vivaldit, akkor a gyártó saját ritmusa dönt, és a verziószámból nem lehet biztonsági állapotra következtetni – de a frissítéskeresés ettől sem rossz ötlet. Ha Arcot használsz, a frissítési ütemnél nagyobb gond, hogy a böngésző december 22-én leáll, úgyhogy ott inkább a váltáson érdemes gondolkodni – a ChatGPT Atlas pedig a gyártó ütemezése szerint már augusztusban leállt. A Firefoxra épülő böngészőknél pedig ez a mostani kiadás nem a Chromium-hibákról szól: a LibreWolf és a Floorp már egy nappal a Mozilla után kiadta a javítást, a Zen egy javítókiadással van hátrébb.

Ha pedig a mobilod frissítéseivel is most foglalkozol, érdemes ezt is elolvasni: Kritikus Android-hiba, amihez nem kell semmit tenned – így nézd meg, megkaptad-e a javítást. A böngészőbővítményekkel kapcsolatos kockázatokról pedig itt írtunk: Megvették a bővítményt, aztán elkezdett jelszót lopni – 19 ilyen esetet kaptak el.

Gyakran ismételt kérdések

Veszélyben vagyok, ha ma még nem frissítettem a Chrome-ot?

A Google bejelentése nem ír arról, hogy bármelyik javított hibát éles támadásban kihasználták volna, és a technikai részleteket sem közli. Vagyis nincs ok a pánikra, de a frissítést nem érdemes napokig tologatni: a javítás elérhető, az ellenőrzés fél perc, és az újraindítás visszatölti a megnyitott lapokat.

Honnan tudom, melyik verzió fut nálam?

A Chrome-ban írd be a címsorba a chrome://settings/help címet. Ez megmutatja a telepített verziót, és egyben el is indítja a frissítéskeresést. A cikk írásakor a friss asztali verzió a 157.0.8103.38, Windowson és macOS-en emellett a 157.0.8103.39 is.

Miért nem kapom meg a frissítést, ha már kijött?

Mert a Google lépcsőzetesen osztja ki: a kiadás napok-hetek alatt jut el az összes felhasználóhoz. A frissítési oldal megnyitása gyakran előre is hozza, de nem minden esetben. Ilyenkor nem kell semmit telepíteni idegen oldalról – egyszerűen nézd meg újra másnap.

Sebezhető a Brave vagy a Vivaldi, ha régebbi Chromium-számot ír ki?

Ezt a verziószámból nem lehet megállapítani. A gyártók egyes javításokat visszaültethetnek a saját, régebbi alapjukra, a Chromiumnak pedig van egy lassabban mozgó Extended Stable ága is, amelybe a projekt a fontos biztonsági javításokat visszaülteti. A Vivaldi például a 8.3-as sorozatnál a 156-os Chromium-ágon áll, ugyanúgy, mint a Brave. A verziószám tehát azt mutatja, melyik alapon áll a böngésző, nem azt, hogy milyen biztonsági állapotban van.

Érinti ez a LibreWolfot, a Floorpot vagy a Tor Browsert?

Nem, ezek nem a Chromiumra épülnek, hanem a Firefoxra, és külön kódbázist használnak. Náluk a november 3-i Firefox 159.0.1 a releváns kiadás: a LibreWolf és a Floorp ezt már november 4-én kiadta, a Zen Browser a cikk írásakor még a Firefox 159.0-s alapnál állt, a Tor Browser pedig a lassabban mozgó, de biztonsági javításokat visszaültető ESR-ágat követi.

Mit tegyek, ha Arcot használok?

A gyártó közlése szerint az Arc 2026. december 22-én leáll a macOS-es és a windowsos gépeken is, és aznaptól az Arc-fiókba sem lehet belépni; a böngésző addig csak alapvető frissítéseket kap. Érdemes tehát még az ünnepek előtt átállni másik böngészőre, és a könyvjelzőket, jelszavakat időben kimenteni belőle.