Dolibarr költségjóváhagyás: mit tanít a CVE-2026-71509?
Amikor a beküldő maga lehet a jóváhagyó: mit tanít a Dolibarr költségjelentési hibája?
Egy frissen közzétett, magas súlyosságú Dolibarr-hiba megmutatta: ha az API átírhatja a workflow védett mezőit, a jóváhagyási folyamat csak látszólagos kontroll.
2026. augusztus 24-én magas súlyosságú biztonsági bejegyzés jelent meg a Dolibarr költségjelentési REST API-járól. A CVE-2026-71509 leírása szerint a 24.0.0 előtti verziókban egy hitelesített, költség létrehozására jogosult felhasználó az API-n át közvetlenül módosíthatta a jóváhagyási állapotot és a jóváhagyó személyét. Így a dedikált jóváhagyási jog nélkül is jóváhagyott vagy lezárt állapotba vihette a saját költségjelentését.
Egy pénzügyi workflow-ban a „jóváhagyva” állapot egy döntés eredménye. Ha ugyanúgy írható, mint egy megjegyzés, az alkalmazás megkerülheti azt a kontrollt, amelyet a felület egyébként látszólag kikényszerít.
Mi történt pontosan?
A nyilvános advisory szerint a támadáshoz érvényes bejelentkezés és költséglétrehozási jogosultság kellett; felhasználói közreműködés nem. A probléma nem az volt, hogy bárki kívülről egyetlen kattintással költséget hagyhatott jóvá, hanem az, hogy egy alacsonyabb jogosultságú, hitelesített API-felhasználó olyan workflow-mezőket is átadhatott a frissítési kérésben, amelyeknek szerveroldalon védettnek kellett volna lenniük.
A GitHub Advisory Database 7,1-es CVSS v4 alappontszámot és magas integritási hatást közöl. A bejegyzés azt is kiemeli, hogy a jóváhagyási időbélyeg hiánya miatt a napló és a tényleges állapot között forenzikus ellentmondás keletkezhetett. A hivatkozott javítás kiszűri a jóváhagyási és lezárási folyamat védett mezőit az általános API-frissítésből.
Miért veszélyesebb ez egy hibás összegnél?
| Kontroll | Elvárt működés | A megkerülés kockázata |
|---|---|---|
| Feladatok szétválasztása | A beküldő és a jóváhagyó két külön szerep | A saját tétel önjóváhagyása |
| Állapotgép | Csak engedélyezett átmenet történhet | Köztes ellenőrzések átugrása |
| Auditnyom | Személy, időpont és döntés összhangban marad | Jóváhagyott állapot hiányos bizonyítékkal |
| API és felület | Ugyanazok az üzleti szabályok érvényesek | A felület tilt, az API mégis enged |
Ez az eset klasszikus mass assignment jellegű tanulságot hordoz: attól, hogy egy objektumnak van egy mezője, az még nem jelenti azt, hogy azt minden általános létrehozási vagy módosítási végpontnak el kell fogadnia. A jóváhagyó, a jóváhagyás ideje és a lezárási állapot nem bemeneti adat, hanem ellenőrzött művelet eredménye.
Hat ellenőrzés Dolibarr-üzemeltetőknek
- Rögzítse a pontos verziót. A nyilvános leírás a 24.0.0 előtti Dolibarr-kiadásokat nevezi meg; ne csak a főverziót ellenőrizze.
- Leltározza az API-kulcsokat. Nézze meg, mely felhasználók és integrációk rendelkeznek költségmodulhoz kapcsolódó írási joggal.
- Frissítsen támogatott csomagra. Teljes adatbázis- és dokumentumtár-mentés után, tesztpéldányon ellenőrizze a 24-es ágra vagy a saját támogatott ághoz kiadott javításra való átállást.
- Tesztelje negatív esettel is. Költséget létrehozni jogosult, de jóváhagyni nem jogosult felhasználóval próbálja meg módosítani a védett állapotokat a felületen és az API-n keresztül is.
- Vizsgálja az előzményeket. Keressen szokatlanul gyors beküldés–jóváhagyás átmenetet, hiányzó jóváhagyási időpontot, váratlan jóváhagyót és API-n végzett költségmódosítást.
- Vonja vissza a felesleges hozzáférést. A nem használt kulcsokat és túl széles jogosultságokat szüntesse meg; gyanú esetén őrizze meg a naplókat, majd kérjen incidenskezelési segítséget.
Ne csak azt bizonyítsuk, hogy a jogosult vezető jóvá tud hagyni. Azt is, hogy a beküldő, egy másik részleg és egy korlátozott API-fiók sem a felületen, sem közvetlen kéréssel nem tudja megkerülni a döntési pontot.
Mit érdemes ebből minden ERP-fejlesztésbe átvinni?
A jogosultságot nem elég a gomb elrejtésével kezelni. Minden állapotváltásnál szerveroldalon kell ellenőrizni az aktuális állapotot, a kért következő állapotot, a felhasználó jogát és az objektum tulajdonviszonyát. Ugyanennek a szabálynak kell érvényesülnie a böngészős felületen, REST API-n, importban, automatizmusban és egyedi modulban.
Az eset a naplózás határát is megmutatja: egy adatbázissor önmagában nem auditnyom. Megbízható bizonyítékhoz együtt kell maradnia a műveletnek, a döntéshozónak, az időpontnak, az előző és új állapotnak, valamint a kérés forrásának.
Források
- GitHub Advisory Database: GHSA-fp99-c8qh-4mjj / CVE-2026-71509
- NIST NVD: CVE-2026-71509 adatlap
- Dolibarr GitHub: a bejegyzésben hivatkozott javító commit
- Dolibarr 24.0.0 hivatalos kiadási oldala
- Dolibarr biztonsági szabályzata és bejelentési csatornái
Forrásállapot: 2026. szeptember 12. A cikk védekezési és üzemeltetési útmutató; nem tartalmaz kihasználási mintát, és nem helyettesít célzott incidensvizsgálatot.
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.