XRP Ledger виправив 2 критичні помилки в xrpld 3.4.1

XRP Ledger виправив 2 критичні помилки в xrpld 3.4.1, і одна з них могла дозволити випускати XRP без забезпечення. Друга загрожувала узгодженості мережі. Це важливо для власників XRP, валідаторів і тих, хто стежить за безпекою мережі.

Команда XRPL опублікувала звіт про дві вразливості в програмному забезпеченні xrpld. Обидві закрили у версії 3.4.1, яку випустили 25 вересня. Першу проблему знайшли 22 вересня 2026 року через програму винагород за пошук помилок. Другу помітили під час повторної перевірки результатів Sherlock Attackathon.

Чому ця помилка була такою небезпечною?

Перша вразливість стосувалася переповнення цілого числа в платіжному механізмі. Якщо коротко, система могла помилитися в підрахунку сотень ордерів. У такому разі зловмисник міг створити XRP фактично з нічого. Для мережі з фіксованою емісією це дуже серйозно.

Команда каже, що проблема могла існувати з 2015 року. Саме тоді з’явився поточний механізм платежів. У xrpld 3.4.1 додали перевірку переповнення під час підрахунку сум і посилили контроль балансу. Це знижує ризик повторення такої помилки в майбутньому.

За даними звіту про вразливість XRPL, проблему спершу оцінили як Major, а після відтворення RippleX підняла її до Critical. Дослідників, які допомогли з розкриттям, назвали публічно: Cayden Liao та Veria AI. Це рідкісний випадок, коли технічна помилка отримує настільки точний і швидкий розбір. І саме це врятувало час.

Що сталося з пакетними транзакціями?

Друга помилка була іншого типу. Вона стосувалася механізму Batch, який дозволяє об’єднати до 8 транзакцій в один пакет. Сервер не перевіряв, чи кожна внутрішня транзакція має обов’язкове поле RawTransaction. Через це різні версії xrpld могли по-різному оцінювати одну й ту саму операцію.

Тут ризик був не в емісії, а в стабільності. У гіршому сценарії це могло створити розбіжності між серверами та зупинити підтвердження нових реєстрів. Команда закрила проблему через оновлення fixBatchV1_2, яке активували в основній мережі 9 жовтня. До цього BatchV1_1 ще не був увімкнений, тому на Mainnet помилку не встигли використати.

У день релізу понад 80% валідаторів default UNL уже працювали на xrpld 3.4.1. Для мережі це важливо. Коли версії розходяться, ризик плутанини зростає дуже швидко.

Реакція мережі та ринку

XRPL не показав ознак масового збою. Команда повідомила, що доказів експлуатації overflow-вразливості в публічних мережах не знайшли. А проблема з пакетними транзакціями не зачепила основну мережу, бо відповідне оновлення протоколу ще не було активоване. Це важливий момент. Помилку виявили до того, як вона встигла перейти в реальний інцидент.

Для ринку така новина зазвичай означає не паніку, а перевірку довіри. За даними ринкового трекера, станом на 10 жовтня 2026 XRP торгувався близько $1.40, капіталізація сягала $88.55 млрд, а в обігу було близько 63 млрд XRP. Це не дрібна мережа, тому навіть одна вразливість тут має великий резонанс.

• Оновлення xrpld 3.4.1 закрило 2 окремі помилки.

• Одна з них могла вплинути на емісію XRP.

• Друга могла зламати узгодженість між версіями серверів.

• Першу проблему знайшли 22 вересня 2026 року.

• Оновлення fixBatchV1_2 активували 9 жовтня.

• Понад 80% валідаторів default UNL уже були на 3.4.1 у день релізу.

Що це означає для інвесторів?

Для власників XRP головний висновок простий. Мережа вчасно закрила дві технічні дірки. Це не прибирає всі ризики, але показує, що команда реагує швидко. І це важливо саме зараз, коли довіра до інфраструктури часто рухає ціну не менше, ніж новини про партнерства.

Є й ширший контекст. У 2025 році XRPL уже переживав зупинку приблизно на 64 хвилини на висоті близько 93,927,174. Тому будь-яка нова проблема з валідністю одразу викликає пильну увагу. На тлі цього швидке оновлення до 3.4.1 і масовий перехід валідаторів виглядають як спроба не дати дрібному багу перетворитися на мережеву кризу.

Ще один нюанс для українських користувачів. Якщо XRP використовується як швидкий переказний актив, то безпека мережі має значення не менше за курс. Коли протокол закриває такі дірки, це зменшує технічний ризик для тих, хто зберігає монету або переказує її між гаманцями. Охочі швидко продати Bitcoin на Monobank також стежать за такими новинами, бо технічні проблеми мереж часто впливають на рішення в моменті.

Часті запитання

Чи могла вразливість у XRP Ledger справді створити нові XRP?

Так, саме про це йшлося в першій помилці. За описом команди, переповнення в механізмі платежів могло дозволити випуск XRP без забезпечення. У xrpld 3.4.1 цю логіку закрили додатковими перевірками.

Чи зупиняла ця помилка мережу XRP Ledger?

Ні, доказів експлуатації в публічних мережах не знайшли. Друга вразливість теж не вплинула на Mainnet, бо потрібне оновлення протоколу ще не було активоване. Але ризик для узгодженості мережі був реальний.

Що вже зробили валідатори та розробники?

Команда випустила xrpld 3.4.1, а понад 80% валідаторів default UNL уже працювали на ньому в день релізу. Пізніше активували fixBatchV1_2 на ledger 107,540,481, а BatchV1_1 увімкнули на ledger 107,540,993. Це допомогло швидко вирівняти стан мережі.

XRP Ledger цього разу встиг виправити проблему до великого збою. І це найважливіша новина для всіх, хто стежить за XRP не лише як за монетою, а як за робочою мережею.

Даний матеріал не є фінансовою рекомендацією. Торгівля криптовалютами пов'язана з ризиками. Частину тексту підготовлено з використанням штучного інтелекту на основі відкритих джерел та перевірено редакцією.