Проєкт Klever-Go оприлюднив два критичні бюлетені про вразливості, які могли створювати незабезпечені токени KLV. CVE-2026-54754 використали проти основної мережі Klever у червні, тоді як CVE-2026-54755 описує окреме переповнення під час розподілу роялті без підтвердженої експлуатації. Обидві проблеми виправлено у Klever-Go 1.7.19, тому операторам вузлів варто перевірити версію та епоху активації mainnet, а не сприймати нове розкриття як свіжий злам ключів гаманців.
Що показали бюлетені Klever
Обидві помилки порушують те саме правило обліку в різних місцях: транзакція не повинна виплачувати одержувачам більше, ніж надав відправник. В обох випадках Klever-Go могла зарахувати KLV без відповідного списання та без запису звичайної операції карбування.
| Проблема | Ризик і виправлення |
|---|---|
| CVE-2026-54754 CVSS 9.6 | Ордер маркетплейсу міг зберегти коректний відсоток реферальної виплати, а під час розрахунку прочитати вже збільшений відсоток роялті. Реферальну виплату й роялті нараховували, а від’ємний залишок продавця мовчки відкидали. Цей шлях експлуатували у mainnet. Klever-Go 1.7.19 відхиляє транзакцію до будь-якої виплати. |
| CVE-2026-54755 CVSS 9.6 | Два завеликі відсотки розподілених роялті могли переповнити 32-бітну суму й пройти перевірку. Подальші виплати могли зарахувати значно більше KLV, ніж було у фонді роялті. Klever-Go 1.7.19 обмежує значення та відхиляє надмірні виплати. Експлуатацію в реальних атаках не підтверджено. |
У бюлетені CVE-2026-54754 зазначено, що зловмисник міг створити колекцію та маркетплейс, виставити NFT із коректною сумою відрахувань, після розміщення підвищити актуальне роялті, а потім купити актив з іншого контрольованого облікового запису. Під час розрахунку система повністю виплачувала реферальну частку та роялті, але відкидала від’ємну частку продавця, створюючи різницю у вигляді придатних до використання KLV.[2]
Звіт Klever визначає вікно спостережуваної експлуатації від 4 червня 10:38 UTC до 5 червня 11:30 UTC. У ньому операції пов’язують із 283 транзакціями, чотирма NFT-колекціями та двома маркетплейсами й повідомляють про штучне створення 486 357 300,26 KLV до екстреного реагування.[1] Це оцінка інциденту від постачальника; її не слід плутати зі звичайним протокольним карбуванням або доказом того, що кожен власник KLV втратив кошти.
Друга вразливість обходила ліміт роялті
CVE-2026-54755 не залежить від помилки часу перевірки в маркетплейсі. Klever-Go декодувала кожен відсоток розподілу як беззнакове 32-бітне значення, додавала їх у ще один 32-бітний лічильник і перевіряла лише результат після переповнення. Тому два дуже великі значення могли перетворити суму на число нижче за ліміт 100%.
Коли переказ, купівля на маркетплейсі або первинна пропозиція токена пізніше розподіляли фонд роялті, кожен контрольований зловмисником одержувач міг отримати виплату за величезним збереженим відсотком. Код сприймав від’ємний залишок як успішну відсутність дії замість відхилення транзакції. Бюлетень демонструє цей шлях на локальному вузлі, але не стверджує, що його застосовували у mainnet.[3]
Що робити операторам вузлів і власникам KLV
- Використовуйте Klever-Go 1.7.19 або новішу версію. В офіційному описі релізу сказано, що кожен вузол має використовувати мережеву епоху активації
fixMarketBuyOverflow. У mainnet зміну активували в епосі 5741 5 червня о 19:00 UTC. Неправильна епоха може спричинити розходження вузла з консенсусом.[4] - Перевірте вікно червневого інциденту. Валідаторам, біржам і командам моніторингу слід зберегти докази з маркетплейсу та мостів за 4–5 червня. Шукайте повторні самоторгівлі, контроль покупця, продавця, реферальної та роялті-адрес однією стороною, суми виплат більші за початкову ставку й колекції або ринки, створені незадовго до активності.
- Зіставте депозити й баланси. Біржам і сервісам, які обробляли KLV під час інциденту, варто порівняти входи транзакцій, квитанції розрахунків, активність мостів і зараховані клієнтські баланси. Звичайна панель пропозиції токена може не показати значення, безпосередньо записане на баланс.
- Не змінюйте й не розкривайте seed-фразу лише через ці CVE. Це помилки протокольного обліку, а не доказ крадіжки seed-фраз або приватних ключів Klever. Перевіряйте стан сервісів за офіційними повідомленнями. Якщо баланс гаманця чи депозит на біржі виглядає неправильно, збережіть ідентифікатори транзакцій і зверніться до відповідного сервісу, не передаючи seed-фразу.
Поширені запитання
Чи зламали Klever Wallet?
Оприлюднені помилки містяться в обліку маркетплейсу та роялті Klever-Go. Джерела не підтверджують викрадення seed-фраз або приватних ключів гаманців. Практичні ризики — створення незабезпечених токенів, економічні наслідки та неправильні баланси навколо інциденту.
Чи продовжують експлуатувати CVE-2026-54754?
Klever повідомляє, що червневий інцидент усунуто, а Klever-Go 1.7.19 містить протокольні виправлення. Нові бюлетені надають технічні подробиці, але не заявляють про поточну кампанію. Дії потребують насамперед вузли, які залишилися на версії нижче за виправлену.
Джерела
- Klever. «Security Incident Report — Updated». Форум Klever, 6 червня 2026 року; переглянуто 28 серпня 2026 року. https://forum.klever.org/t/security-incident-report-updated/4450
- Проєкт Klever-Go. «Marketplace settlement mints KLV when referral and royalty percentages exceed the bid (CVE-2026-54754)». GitHub Security Advisory GHSA-p7gw-2pcp-5pf8, 28 серпня 2026 року. https://github.com/klever-io/klever-go/security/advisories/GHSA-p7gw-2pcp-5pf8
- Проєкт Klever-Go. «Integer overflow in split-royalty validation enables unbounded KLV minting (CVE-2026-54755)». GitHub Security Advisory GHSA-cgc5-v3f2-8m2v, 28 серпня 2026 року. https://github.com/klever-io/klever-go/security/advisories/GHSA-cgc5-v3f2-8m2v
- Проєкт Klever-Go. «v1.7.19 — Marketplace & SFT Mint Security Release». GitHub, 22 червня 2026 року. https://github.com/klever-io/klever-go/releases/tag/v1.7.19
