Verzie GLPI 11.0.9 a 10.0.27 vyšli 16. septembra 2026. Oznámenie projektu k nim pripája vetu, ktorá je pre prevádzku dôležitejšia než samotný zoznam opráv: v najbližších mesiacoch má frekvencia vydaní stúpnuť a počítať treba s bezpečnostnými vydaniami zhruba každé dva týždne. Dôvodom je nápor bezpečnostných hlásení: projekt ho pripisuje nástupu LLM a pentestovaniu riadenému agentmi, ktoré podľa neho výrazne zvýšili objem hlásení — rovnako ako v iných známych open source projektoch.
Čo opravuje táto dávka
Oznámenie na blogu vypichuje šesť zraniteľností, poznámky k vydaniu na GitHube sú podrobnejšie — 11.0.9 uvádza dvanásť bezpečnostných položiek, 10.0.27 sedem. Päť opráv so závažnosťou High zdieľajú obe vetvy:
- neautentifikovaná SQL injection v plánovaní
- úspešná X509 autentifikácia s neovereným certifikátom
- race condition v marketplace umožňujúca inštaláciu škodlivého pluginu
- nahranie škodlivej stránky na webový server
- mazanie ľubovoľných súborov pri vytváraní dokumentov
Prvá položka je dôvod, prečo sa tu s údržbovým oknom neoplatí čakať: neautentifikovaná znamená bez prihlásenia. Kto má GLPI dostupné z internetu — typicky kvôli samoobslužnému portálu — je exponovaný bez ohľadu na to, ako má nastavené profily a oprávnenia. Rovnako nepríjemná je X509: autentifikácia certifikátom sa nasadzuje práve preto, aby bola prísnejšia než heslo, a tu prijímala aj neoverené certifikáty.
Ďalšie dve položky so strednou závažnosťou sa tiež týkajú oboch vetiev — prístup k následným krokom, úlohám a riešeniam vygenerovaným zo šablón a rozšírenie viditeľnosti článkov znalostnej bázy, pripomienok a RSS kanálov. Vetva 11.0 má navyše XSS cez import ilustrácie formulára, stored XSS v aktéroch tiketu, v názve aktíva a v modeloch sieťových zariadení, plus obídenie MFA iným prihláseným používateľom. Kto zostal na 10.0.x, teda nie je mimo hry — len má kratší zoznam.
Na CVE čísla sa čakať nedá
Poznámky k vydaniu CVE identifikátory neuvádzajú. Pri predchádzajúcej dávke vyšli 11.0.8 a 10.0.26 24. júna a zodpovedajúce advisories s CVE číslami pribudli na GitHube v dvoch vlnách — päť 21. júla, zvyšných jedenásť 27. júla, teda 27 až 33 dní po oprave. Proces riadenia zraniteľností, ktorý sa spolieha na to, že problém ohlási skener podľa CVE, tak beží približne mesiac za opravou, ktorá je už verejne dostupná. A verejná oprava v open source projekte je zároveň návod, kde chybu hľadať. Zdrojom pravdy pre GLPI je tag vydania, nie databáza zraniteľností.
Dvojtýždňový cyklus je iný prevádzkový režim
Aktualizácia raz za štvrťrok sa dá odbaviť ako malý projekt: dohodnúť termín, zvolať ľudí, otestovať. Pri štrnásťdňovom cykle to nevychádza — z aktualizácie musí byť rutina, ktorá má vlastníka, pevné okno a nacvičený postup. Prakticky to znamená:
- stále údržbové okno, o ktorom vedia používatelia aj prevádzka, namiesto ad hoc dohadovania
- písomný postup: záloha databázy aj súborov, údržbový režim, výmena súborov,
php bin/console db:update - testovaciu inštanciu, ktorá sa dá obnoviť z produkčnej zálohy za hodinu, nie za deň
- zoznam pluginov s kontaktom na autora a informáciou, kedy naposledy vyšla kompatibilná verzia
- rollback vopred odskúšaný, nie improvizovaný o polnoci
Pluginy sú pri tejto kadencii hlavná brzda a race condition v marketplace je dobrá pripomienka, že ich inštalácia patrí medzi kontrolované operácie. Pre subjekty v pôsobnosti NIS2 to navyše nie je len otázka prevádzkovej hygieny — vyhláška 227/2025 vyžaduje riadenie zraniteľností ako doložiteľný proces a pri dvojtýždňovom cykle vydaní sa „čakali sme na ďalšie plánované okno“ zdôvodňuje ťažko.
A dvanástka
V ten istý deň vyšla aj verzia 12.0.0-rc2 — stále release candidate, stále s poznámkou, že do produkcie nepatrí. Stabilná dvanástka má prísť v októbri. Čakanie na ňu nie je dôvod odkladať 11.0.9: prechod na GLPI 12 je samostatný projekt s vlastným testovaním pluginov a infraštruktúry, kým 11.0.9 je výmena súborov a jeden príkaz. Jedno druhé nenahrádza.