Bezpečnostní hrozby · 14. listopadu 2026

OpenMage Magento LTS: chyba v OAuth může útočníkovi dát trvalý přístup k API e-shopu

Kritická chyba CVE-2026-128049 v OpenMage Magento LTS umožňuje útočníkovi s přístupovými údaji OAuth aplikace získat trvalý přístup k API jménem přihlášeného správce nebo zákazníka, pokud ho naláká na odkaz. Zneužití zatím není známo. Aktualizujte na 20.18.2 nebo 20.19.0.

Co se stalo

OpenMage Magento LTS je komunitou udržované pokračování e-shopového systému Magento 1, který původní výrobce přestal podporovat v roce 2020. Tým OpenMage zveřejnil 26. října 2026 bezpečnostní upozornění GHSA-grrq-9gq2-vm55 a chybu v něm označil jako kritickou. Společnost VulnCheck ji popsala 12. listopadu 2026 a v databázi NVD je od 13. listopadu 2026 pod označením CVE-2026-128049.

Chyba je v kroku, kterým správce nebo zákazník schvaluje externí aplikaci přístup k obchodu přes rozhraní REST API (schvalování typu OAuth). Schválení šlo potvrdit pouhým otevřením odkazu, bez kontroly, zda ho člověk opravdu chtěl potvrdit. Útočník, který má přístupové údaje zaregistrované aplikace, tak může přihlášeného správce nalákat na připravený odkaz a získat trvalý přístup k API jeho jménem.

Chybu nahlásilo soukromě přes platformu HackerOne několik výzkumníků nezávisle na sobě. OpenMage v upozornění neuvádí, že by byla zneužita. Není ani v katalogu CISA KEV a evropská databáze zranitelností EUVD u ní zneužívání neeviduje.

Proč je to nebezpečné

Jde o typ chyby CSRF (cross-site request forgery, tedy podvržený požadavek z jiné stránky). Prohlížeč při každé návštěvě obchodu automaticky posílá i vaše přihlášení. Pokud obchod nekontroluje, zda akci opravdu spustil člověk v jeho vlastním formuláři, stačí, aby oběť otevřela odkaz v e-mailu nebo na jiném webu, a obchod akci provede, jako by ji potvrdila sama. Je to, jako by vám někdo podstrčil plnou moc a za podepsanou by se považovala už ve chvíli, kdy se na ni podíváte.

Výsledkem je přístupový token k REST API vázaný na oběť, tedy na správce nebo zákazníka. Funguje nezávisle na jejím přihlášení v prohlížeči a platí, dokud ho někdo nezruší. Podle OpenMage je token správce užitečný jen tehdy, má-li správce přidělenou REST roli. Útočník pak získá vše, co tato role dovoluje, což v obchodech používajících API obvykle znamená čtení a změny údajů o zákaznících, objednávkách, produktech a skladových zásobách.

Útok vede přes internet, ale nemůže ho provést kdokoli. Útočník potřebuje platné přístupové údaje OAuth aplikace, tedy oprávnění na úrovni integrátora, nikoli účet správce. Oběť musí být přihlášená a musí odkaz otevřít.

OpenMage i společnost VulnCheck hodnotí chybu skórem 9,0 z 10 podle CVSS 3.1, což je kritická úroveň. VulnCheck uvádí i hodnocení podle novější verze CVSS 4.0, a to 9,4. CVSS měří závažnost, ne to, zda chybu někdo zneužívá. K tomu slouží katalog CISA KEV s potvrzeně zneužívanými chybami, ve kterém tato není. Skóre EPSS, které odhaduje pravděpodobnost zneužití v příštích 30 dnech, je přibližně 0,23 %, což je nízká hodnota.

Koho se to týká

Týká se to obchodů na OpenMage Magento LTS ve všech verzích starších než 20.18.2. Zasažena je i vývojová řada 21.x od 21.0.0-beta1 po verzi před 21.0.0-beta3. Chyba je v administraci i v zákaznické části obchodu.

OpenMage obvykle běží na webhostingu nebo vlastním serveru s PHP, často v obchodech, které začínaly na Magento 1 a nepřešly na Magento 2. Největší riziko mají obchody, které přes REST API propojují ERP, sklad, účetnictví nebo tržiště a mají správce s přidělenou REST rolí.

  • Pokud REST API nepoužíváte a nemáte zaregistrovanou žádnou OAuth aplikaci, útočník nemá s čím začít. Aktualizovat byste i tak měli.
  • Magento 2 a Adobe Commerce jsou samostatné produkty a upozornění OpenMage se na ně nevztahuje.
  • Zda je zasaženo i původní Magento 1, OpenMage neuvádí. Takový obchod ale od roku 2020 nedostává bezpečnostní opravy a je rizikový sám o sobě.

Jak zjistit, zda jste zasaženi

Verzi zjistíte v adresáři, kde je obchod nainstalován. Pokud jste ho instalovali přes Composer, podívejte se na řádek versions ve výpisu:

composer show openmage/magento-lts

Bez Composeru vypíšete verzi přímo přes PHP. Příkaz jen načte jádro obchodu a nic nemění:

php -r 'require "app/Mage.php"; echo Mage::getOpenMageVersion(), PHP_EOL;'

V administraci pak zkontrolujte System › Web Services › REST OAuth Consumers, zda máte zaregistrované OAuth aplikace, a System › Web Services › REST Roles, zda mají někteří správci přidělenou REST roli. Pokud ano a verze je zranitelná, aktualizace je naléhavá.

Jak to opravit

Opravené verze jsou 20.18.2 a 20.19.0, pro vývojovou řadu 21.x je to 21.0.0-beta3. Po opravě vyžaduje potvrzení přístupu OAuth odeslání formuláře s ochranným klíčem. Pouhé otevření schvalovacího odkazu vrátí chybu 404.

  • 1. Pokud nemůžete aktualizovat hned, ještě dnes zaveďte dočasná opatření níže.
  • 2. Zálohujte soubory i databázi obchodu.
  • 3. Aktualizaci vyzkoušejte nejprve na testovací kopii. Pokud vaše šablona vzhledu přepisuje soubory oauth/authorize/button.phtml nebo button-simple.phtml, upravte je podle nové verze, jinak schvalování integrací přestane fungovat.
  • 4. Aktualizujte na 20.19.0 nebo 20.18.2, například přes Composer, a vyčistěte cache.
  • 5. Ověřte verzi a vyzkoušejte, zda fungují vaše integrace.
  • 6. Projděte vydané tokeny a OAuth aplikace podle poslední sekce.

Dočasná opatření, která doporučuje OpenMage:

  • Pokud REST API nepoužíváte, odstraňte nebo vypněte všechny OAuth aplikace v System › Web Services › REST OAuth Consumers.
  • Zrušte aplikace, kterým plně nedůvěřujete, a zkontrolujte vydané tokeny.
  • Nepřidělujte REST role správcům, kteří přístup k API nepotřebují.
  • Omezte přístup k administraci, například jen na vybrané IP adresy nebo přes VPN.

Co když už jste mohli být napadeni

Ukradený token platí, dokud ho nezrušíte, a samotná aktualizace ho neodstraní. Po opravě proto zkontrolujte:

  • System › Web Services › REST OAuth Authorized Tokens: tokeny, které neznáte, zrušte.
  • REST My Apps u účtů správců a My Applications v zákaznických účtech.
  • OAuth aplikace, které neznáte, a REST role s nepřiměřeně širokými právy.
  • Nečekané změny cen, produktů, zásob, objednávek nebo údajů zákazníků.

V lozích webového serveru můžete hledat požadavky na schvalovací adresy OAuth. Logy bývají v /var/log/apache2/, /var/log/httpd/ nebo /var/log/nginx/, na webhostingu je najdete v administraci hostingu. Takové požadavky před opravou zanechávaly i běžné integrace, proto je porovnejte s tím, kdy jste skutečně připojovali nějakou aplikaci.

zgrep -E "oauth(_authorize|/authorize)/confirm" /var/log/apache2/*access* /var/log/httpd/*access* /var/log/nginx/*access* 2>/dev/null

Pokud najdete token, který nikdo neumí vysvětlit, zrušte ho i s aplikací, vyměňte klíče integrací a přizvěte odborníka na bezpečnost. Pokud došlo k úniku osobních údajů, GDPR zpravidla vyžaduje ohlásit ho do 72 hodin od zjištění dozorovému úřadu. V Česku je to Úřad pro ochranu osobních údajů, na Slovensku Úrad na ochranu osobných údajov SR.

Zdroje

Články sestavuje AI agent z veřejných zdrojů (výrobci, CISA, ENISA, NVD, NÚKIB, SK-CERT) a čísla verzí i CVE proti nim automaticky ověřuje. Před zásahem do produkce si postup vždy ověřte v bulletinu výrobce.

← Všechny hrozby · RSS

Potřebujete pomoct s opravou nebo kontrolou?

Pomohu vám zjistit, které systémy jsou zasažené, bezpečně je aktualizovat a zkontrolovat, zda útočník už nebyl uvnitř. Začněme úvodní konzultací, při spolupráci se odečte z ceny projektu.