Dolibarr API-hiba: amikor egy nagybetű átjut a szűrőn
A nagybetű, amely átcsúszott a szűrőn: mit tanít a Dolibarr CVE-2026-89012?
A Dolibarr 24.0.0 API-védelme kisbetűs mezőnevet tiltott, miközben az adatbázis a nagybetűs változatot is felismerte. Egy apró eltérésből komoly adatvédelmi rés lett.
2026. szeptember 11-én magas súlyosságú sérülékenységként tették közzé a CVE-2026-89012 azonosítójú Dolibarr-hibát. A probléma különlegessége, hogy nem egy látványos programozási baki, hanem két réteg eltérő nyelvtana okozta: az alkalmazás biztonsági tiltólistája megkülönböztette a kis- és nagybetűket, az adatbázis viszont ugyanannak a mezőnévnek tekinthette őket.
Ha Dolibarr 24.0.0 fut és a REST API használatban van, a 24.0.1-re frissítést prioritásként kell kezelni. Előtte teljes mentés, tesztkörnyezet és az egyedi modulok ellenőrzése szükséges. A verziószámot és az API-kitettséget ne feltételezésből, hanem a tényleges telepítésből állapítsuk meg.
Hogyan fér át ugyanaz a név kétféleképpen?
A Dolibarr REST API sqlfilters paramétere összetett szűréseket tesz lehetővé. A védelem bizonyos érzékeny mezőneveket tiltólistával zárt ki. A közzétett leírás szerint a Dolibarr 24.0.0 előtti ellenőrzés kis- és nagybetű-érzékeny volt, miközben az adatbázis oszlopfeloldása nem feltétlenül az.
Egyszerűsítve: ha a szűrő a secretfield nevet tiltotta, a SECRETFIELD alak átjuthatott rajta, majd az adatbázis mégis az eredeti oszlopként értelmezhette. Ez nem azt jelenti, hogy a támadó egyetlen válaszban megkapta az érzékeny értéket. A közlemény szerint logikai feltételekkel, igen–nem jellegű válaszokból lehetett karakterenként következtetni rá — ezt nevezik boolean oracle technikának.
| Réteg | Mit lát? | Miért veszélyes az eltérés? |
|---|---|---|
| API-védelem | A beküldött mezőnév pontos írásmódját | Az eltérő kis- és nagybetűs alakot más névnek tekintheti. |
| Adatbázis | Az oszlopnév adatbázis szerinti feloldását | Ugyanazt az oszlopot találhatja meg az eltérő írásmód mögött. |
| Támadó válaszai | A feltétel sikerét vagy kudarcát | Sok kérésből fokozatosan információ következtethető ki. |
Mit tudunk biztosan az érintettségről?
A GitHub Advisory szerint a hiba a Dolibarr 24.0.0-t érintette a 24.0.1 előtt, hálózaton keresztül, alacsony jogosultságú hitelesített felhasználóval, felhasználói közreműködés nélkül volt kihasználható. A közlemény 7,1-es CVSS v4 értéket és magas titkossági hatást jelöl. A leírt cél a felhasználói jelszóhash-ek — akár adminisztrátori fióké — kikövetkeztetése lehetett.
Fontos árnyalat: a GitHub tanácsadó „affected versions” és „patched versions” mezője nincs külön kitöltve; az érintett és javított változatot maga a leírás nevezi meg. A 24.0.1 hivatalos kiadása 2026. szeptember 7-i, míg a CVE-adatlap szeptember 11-én jelent meg. Vagyis a javított kiadás már elérhető volt a részletes nyilvános ismertetés előtt.
A közlemény nem állítja, hogy minden 24.0.0 telepítést ténylegesen megtámadtak. Az érintettség, a kihasználhatóság és a bizonyított kompromittálódás három külön kérdés. Ugyanakkor a REST API-nak adott alacsony jogosultság sem teszi jelentéktelenné a kockázatot.
Miért több ez egyetlen Dolibarr-hibánál?
A denylist — vagyis „mindent engedünk, kivéve ezeket a neveket” — törékeny biztonsági minta. Nemcsak a kis- és nagybetű okozhat eltérést: aliasok, kódolások, adatbázis-dialektusok és később hozzáadott mezők is új kerülőutat nyithatnak. Biztonságosabb az engedélyezett mezők szűk, normalizált listájából kiindulni, és ugyanabban a formában összehasonlítani, amelyben a következő réteg értelmez.
Az eset az egyedi Dolibarr-modulokra is vonatkozik. Ha egy REST-végpont dinamikus rendezést, mezőválasztást vagy szűrőfeltételt fogad, a paraméterezett SQL önmagában nem old meg minden problémát. A paraméterezés az értékeket védi; a dinamikus oszlopnevekhez külön allowlist és kanonizálás kell.
Ugyanazt a bemenetet minden rétegben ugyanazzal a jelentéssel kell kezelni. Ha az alkalmazás és az adatbázis másképp dönti el, mi „ugyanaz”, a kettő közötti rés támadási felületté válhat.
Gyakorlati ellenőrzőlista üzemeltetőknek
- Azonosítsuk a tényleges verziót. Ne csak a Docker taget vagy egy telepítési jegyzetet nézzünk; ellenőrizzük a futó alkalmazást.
- Frissítsünk 24.0.1-re vagy újabb támogatott javított kiadásra. Mentés és visszaállítási próba nélkül ne indítsunk éles frissítést.
- Leltározzuk az API-kulcsokat. Kié a kulcs, milyen jogokkal, honnan használható, és mikor használták utoljára?
- Vonjuk vissza a felesleges hozzáférést. Egy elfelejtett integrációs kulcs ugyanúgy hitelesített belépési pont.
- Vizsgáljuk át a naplókat. Szokatlanul sok, változó szűrőfeltételt tartalmazó API-kérés vagy ismeretlen forráscím indokolhat további elemzést. A napló hiánya nem bizonyítja, hogy nem történt visszaélés.
- Gyanú esetén kezeljük incidensként. Az API-kulcsok és munkamenetek visszavonása mellett a jelszavak cseréjét is meg kell fontolni; a pontos lépést a naplók, a kitettség és a helyi architektúra alapján kell meghatározni.
- Teszteljük az egyedi végpontokat. Mezőnevek, rendezések és szűrők kis- és nagybetűs, kódolt és nem várt változatai is kerüljenek negatív tesztbe.
Források
- GitHub Advisory Database – CVE-2026-89012 / GHSA-vhvr-3m2v-rrfq: érintettség, támadási feltételek, CVSS és technikai összefoglaló.
- NIST NVD – CVE-2026-89012: a sérülékenység nemzeti adatbázis-bejegyzése.
- Dolibarr javító commit – 7a04d9c: a tanácsadó által hivatkozott forráskódváltozás.
- Dolibarr 24.0.1 hivatalos kiadás: a javított karbantartási verzió kiadási oldala.
- MITRE CWE-178: a kis- és nagybetű-érzékenység hibás kezelésének általános hibakategóriája.
Forrásállapot: 2026. szeptember 18. A cikk védekező, üzemeltetői összefoglaló; szándékosan nem közöl reprodukálható támadási kéréseket. A frissítés módját a telepített verzió, az egyedi modulok és az üzemeltetési környezet alapján kell megtervezni.
Nézze meg, milyen Dolibarr-folyamat illeszkedhet a vállalkozásához, vagy küldje el röviden a saját helyzetét.
Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.