Коротко про вразливість SP1: вразливі версії, ризики та виправлення
Вада у верифікаторі доказу із нульовим розголошенням може підірвати надійність цілого застосунку, не компрометуючи приватний ключ чи безпосередньо не звільняючи гаманець. Саме це є основною стурбованістю щодо вразливості високого рівня важливості, розкритої в системі доказів SP1 від Succinct. Офіційна безпекова рекомендація на GitHub, опублікована 11 жовтня 2026 року, описує ваду у нативному верифікаторі Rust, яка може дозволити приймати недійсні докази виконання, коли дані доказу містять несумісні розміри тензорів і довжини зберігання. Проблема стосується версій SP1 6.0.0–6.8.0, а виправлення надано у версії 6.8.1.
Succinct впровадив виправленого верифікатора до свого мейннет Prover Network — єдиний відомий вразливий випадок, зазначений у попередженні. Однак розробники, які використовують власні нативні верифікатори на Rust, повинні перевірити свої версії та оновити їх, якщо вони приймають докази від ненадійних сторін. Цей інцидент підкреслює фундаментальну вимогу безпеки для інфраструктури нульових знань: програмне забезпечення верифікації має послідовно відкидати пошкоджені дані доказу. Хоча вразливість створила потенційний шлях для проходження неправильних обчислень через верифікацію, публічні розголошення не підтвердили, що вона призвела до фінансових втрат. Тому розуміння її масштабу, технічної причини та засобів усунення є необхідним для розробників та криптоінвесторів, які оцінюють цей інцидент.
Основні висновки
-
Вразливі версії: власні компоненти Rust-верифікатора SP1 з 6.0.0 по 6.8.0 були вразливі.
-
Фіксований реліз: SP1 6.8.1 додає перевірку довжини тензорів і форми.
-
Основний ризик: Зловмисний доводчик може надіслати доказ неправильного виконання, який може прийняти вразливий перевіряючий.
-
Відомий вплив: мережа Prover мейннет Succinct була єдиною відомою постраждалою розгортанням, коли було розкрито вразливість.
-
Важлива виняток: шляхи верифікації Groth16 і Plonk, що використовують докази з фіксованою формою упаковки, не страждають від цієї конкретної проблеми.
-
Необхідна дія: Оператори, які запускають власний впливовий нативний Rust-верифікатор, повинні оновити його до версії 6.8.1 або сумісної пізнішої виправленої версії.
Що таке вразливість Succinct SP1?
Уразливість, відслідковувана як GitHub Security Advisory GHSA-p7v2-jjv3-8p8f, є проблемою цілісності у нативному Rust-верифікаторі SP1 V6. Офіційна реклама оцінює її як високу та вказує на невідповідність довжин тензорів як на основну проблему. Її виявив Vitalis Salis і повідомив через програму баг-бонусів Immunefi.
SP1 — це віртуальна машина з нульовим знанням (zkVM), розроблена Succinct. Вона дозволяє програмам створювати криптографічні докази того, що їхні обчислення відповідали визначеним правилам. Перевіряючий перевіряє ці докази, не обов’язково повторюючи все обчислення, що робить перевірку доказів корисною для застосунків блокчейну, ролапів та систем, що залежать від перевірного поза ланцюгового виконання. Надійність перевіряючого є критичною, оскільки застосунки можуть використовувати його результат для визначення, чи слід приймати перехід стану або обчислення.
Як працює баг Tensor-Length?
SP1 представляє багатовимірні дані за допомогою структури, що називається тензором, яка містить буфер зберігання та виміри, що описують форму даних. Наприклад, тензор, оголошений з двома рядками та трьома стовпцями, повинен містити шість елементів. Безпечний перевіряючий повинен підтвердити, що фактична кількість збережених елементів відповідає добутку оголошених вимірів.
У вразливих версіях процес десеріалізації недостатньо перевіряв цю залежність. Деякі шляхи перевірки пізніше опиралися на оголошені виміри, не перевіряючи реальну довжину зберігання. Зловмисний доводчик може надати тензорні дані з несумісними розмірами та сховищем, що призведе до того, що різні етапи перевірки оброблятимуть різні частини тих самих даних. Ця несумісність може порушити припущення, необхідні для коректної перевірки, і дозволити прийняти довідку для недійсного виконання.
Тому центральною проблемою було не просто пошкоджені дані, а невдача перевіряючого забезпечити структурну послідовність перед використанням цих даних. Ця різниця має значення, бо система доведення є лише настільки надійною, наскільки надійними є перевірки, виконані на всьому шляху її верифікації.
Піддані версії та системи
Офіційна рекомендація визначає три вразливі пакунки Rust:
sp1_hypercube, sp1_prover та sp1_sdk. Кожен з них страждає від версії 6.0.0 до 6.8.0, при цьому версія 6.8.1 вказана як виправлена. Розробникам слід перевірити свої дерева залежностей та розгорнуті бінарні файли, а не припускати, що оновлення одного верхньорівневого пакунка автоматично оновить усі компоненти.| Компонент або конфігурація | Статус | Рекомендована дія |
| sp1_hypercube 6.0.0–6.8.0 | Постраждавші | Оновіть до версії 6.8.1 або сумісного виправленого релізу |
| sp1_prover 6.0.0–6.8.0 | Постраждавші | Оновіть до версії 6.8.1 або сумісного виправленого релізу |
| sp1_sdk 6.0.0–6.8.0 | Постраждавші | Оновлення та перевірка вирішених залежностей |
| SP1 6.8.1 | Виправлено | Підтвердьте, що розгорнуте середовище використовує виправленний код |
| Перевірка Groth16 та Plonk за допомогою доведень у фіксованій формі | Не страждає від цієї проблеми | Продовжуйте дотримуватися загальних рекомендацій щодо безпеки та залежностей |
Які додатки стоять під найбільшим ризиком?
Ця вразливість впливає на Core та Compressed докази, надіслані безпосередньо на вразливий нативний Rust-верифікатор. Застосунки піддаються ризику, коли вони використовують цей верифікатор для прийняття доказів, наданих недовіреними провайдерами. Точний вплив залежить від режиму доказу та шляху верифікації.
На момент розкриття інформації мережа Prover мейннет Succinct була єдиною відомою вразливою реалізацією. Мережа приймала докази від сторонніх провайдерів, що створило відповідний ризик потенційно шкідливих вхідних доказів. Пізніше Succinct розгорнула виправлену верифікаторну систему. Інші проекти, що використовують SP1, повинні незалежно перевірити свою архітектуру та інформацію про версії, а не припускати, що кожна інтеграція була вразливою або що кожна інтеграція автоматично захищена.
Як вада верифікації SP1 може вплинути на крипто-застосунки
Основний ризик полягає в тому, що застосунок може спиратися на неправильний обчислювальний результат, який вважається дійсним. Якщо результат перевірки доведення керує переходом стану, процесом розрахунків або іншою безпеково-чутливою операцією, неправильне прийняття може вплинути на застосунок, який довіряє цьому результату. Однак реальні наслідки залежать від того, як інтегровано верифікатор, що представляє собою доведення та чи існують додаткові перевірки в інших частинах системи.
Чому це важливо для нульових знань ролапів
Системи з нульовим знанням створені для того, щоб дозволити додаткам ефективно перевіряти обчислення, зберігаючи при цьому сильні гарантії коректності. У архітектурі ролапу перевірка доведень може допомогти встановити, що запропоновані переходи стану задовольняють необхідним правилам. Якщо відповідний верифікатор приймає недійсне доведення, додаток може втратити важливий рівень захисту.
Це не означає, що кожен ролап чи застосунок, що використовує SP1, був скомпрометований. Офіційне повідомлення обмежує впливові шляхи та визначає один відомий вразливий випадок на момент виявлення. Також у ньому прямо зазначено, що шляхи верифікації Groth16 та Plonk, що використовують доведення з фіксованою формою, не були вплинуті цією вразливістю. Розробники повинні оцінити свою конкретну архітектуру верифікації, перш ніж робити висновки щодо вразливості.
Чи було вкрадено гроші користувача?
Громадське попередження встановлює потенційну невідповідність доказів, а не підтверджений вивіз коштів. За останніми звітами від 24 жовтня, розкрита інформація не підтвердила, що нападники використали цю вразливість для завдання фінансових збитків. Відсутність повідомлень про збитки не повинна трактуватися як доказ того, що кожна інтеграція була безпечною, але також важливо не описувати теоретичний шлях експлуатації як підтверджений напад.
Для криптоінвесторів ця різниця має значення. Інциденти безпеки можуть впливати на довіру до інфраструктурних проектів, але реакція цін залежить від тяжкості реальних наслідків, швидкості усунення проблеми, ступеня адаптації та загальних ринкових умов. Недостатньо доказів, щоб зробити висновок, що саме ця вразливість визначить ціну токена PROVE Succinct або інших пов’язаних активів.
Як Succinct виправив вразливість SP1
Succinct усунув недолік у SP1 6.8.1, додавши перевірку на двох етапах. По-перше, процес десеріалізації тепер відхиляє тензори, якщо їхня довжина зберігання відрізняється від добутку їхніх оголошених вимірів. По-друге, впливові нативні шляхи перевірки перевіряють фізичну форму тензора перед тим, як покладатися на оголошені виміри або обробляти збережені елементи. Ці перевірки забезпечують, що етапи перевірки працюють з консистентними даними і повертають помилку для пошкоджених доказів.
Патч було випущено 24 вересня 2026 року, і Succinct розгорнув його на мейннет Prover Network після доступності виправленої версії. Офіційне повідомлення стверджує, що запитувачі, які використовують цю мережу, не повинні змінювати свою інтеграцію для оновлення з боку мережі. Однак організаціям, які працюють з власними нативними Rust-верифікаторами, що приймають докази від недовірених сторін, рекомендується оновитись до версії 6.8.1.
Що розробникам слід робити зараз
Першочергова задача — визначити, чи використовує додаток безпосередньо вразливий нативний шлях перевірки Rust. Розробникам слід перевірити маніфести залежностей та блокувальні файли, підтвердити версії, що використовуються у виробничому середовищі, та оновити відповідні компоненти. Просто зміна оголошення версії недостатня, якщо розгорнутий двійковий файл продовжує використовувати старіший код.
Після оновлення команди повинні запустити свої звичайні регресійні та безпекові тести, перевірити, що некоректні вхідні дані доведення відхиляються, та переконатися, що виробничі розгортання використовують виправлену верифікаційну програму. Вони також повинні перевірити будь-які історичні операції, пов’язані з безпекою, які залежали від уразливого шляху верифікації до впровадження виправлення. Якщо виявлено підозрілі надсилання доведень або непослідовні записи верифікації, ці події вимагають цілеспрямованого розслідування.
Що означає ця вразливість для Succinct та ринку ZK-доказів
Цей інцидент ілюструє, чому безпека інфраструктури нульових знань залежить не лише від базового криптографічного протоколу. Навіть надійна система доведення може бути підірвана помилками реалізації у серіалізації, обробці даних або логіці перевірки. Як тільки zkVM і системи доведення стануть ширше інтегровані в інфраструктуру блокчейну, надійна валідація вхідних даних, незалежні аудити, програми винагород за виявлення помилок та своєчасні оновлення програмного забезпечення залишаються обов’язковими.
Висновок
Вразливість Succinct SP1 підкреслює фундаментальну вимогу до інфраструктури нульових знань: програмне забезпечення перевірки має перевіряти структуру даних доведення перед тим, як довіряти їм. Ця проблема вплинула на нативні компоненти перевірки Rust SP1 V6 у версіях від 6.0.0 до 6.8.0 і могла дозволити приймати недійсні доведення виконання, коли оголошені розміри тензорів не збігалися з фактичною довжиною зберігання. Проблема була оцінена як Висока у офіційному оголошенні на GitHub, а SP1 6.8.1 ввів перевірки, необхідні для вирішення цієї проблеми.
Succinct впровадив виправлення на своєму мейннет Prover Network, який був єдиним відомим вразливим розгортанням на момент розкриття проблеми. Розробники, які використовують власні нативні Rust-верифікатори, повинні все ще перевірити свої версії та оновити їх, якщо це необхідно. Важливо, що офіційне повідомлення не підтверджує, що цей недолік призвів до фінансових втрат, а верифікація Groth16 і Plonk за допомогою доведень із фіксованою формою не була вплинута цією конкретною проблемою. Більш загальний висновок для криптоіндустрії полягає в тому, що потужний криптографічний дизайн повинен супроводжуватися уважною реалізацією, постійною валідацією та дисциплінованим обслуговуванням. Найбільш значущими індикаторами вирішення є підтверджена адаптація патчів, надійна робота та прозорі наступні повідомлення.
ЧАСТІ ПИТАННЯ
Чи має вразливість SP1 номер CVE?
Офіційна безпекова рекомендація GitHub не містить відомих ідентифікаторів CVE для цієї проблеми. Її ідентифікатор відстеження — GHSA-p7v2-jjv3-8p8f.
Хто виявив вразливість SP1?
Офіційна консультація віддає належне Vitalis Salis, який виявив проблему і повідомив про неї через програму баг-бантів Immunefi.
Чи впливає ця вразливість на кожну систему доказу із нульовим розголошенням?
Ні. Попередження стосується конкретних компонентів нативного Rust-верифікатора SP1 V6 та певних шляхів верифікації доведень. Воно не встановлює, що інші системи нульового знання під впливом.
Чи можуть розробники продовжувати використовувати SP1 після оновлення?
Так. Ця вразливість не означає, що SP1 потрібно відкинути. Розробники повинні використовувати виправлену сумісну версію та перевірити, чи їхня конкретна інтеграція відповідає відповідним рекомендаціям безпеки.
Де читачі можуть знайти авторитетні технічні деталі?
Основним джерелом є офіційне безпекове повідомлення SP1 на GitHub, яке містить інформацію про вразливі пакунки, діапазони версій, технічну причину, вплив та засоби усунення.
Відмова від відповідальності: Ця загальна інформація про ринок, можливо, з третіх сторін, комерційних або спонсорованих джерел, надається виключно для довідкових та освітніх цілей і не є фінансовою або інвестиційною порадою, пропозицією, запрошенням або гарантією. Ми відмовляємося від відповідальності за точність, повноту, надійність цієї інформації та будь-які зумовлені нею втрати. Інвестування/торгівля супроводжуються ризиками; минулі результати не гарантують майбутніх. Користувачі повинні проводити дослідження, обережно оцінювати ризики та брати повну відповідальність. Для отримання додаткової інформації будь ласка, ознайомтеся з Умовами використання та Відмовою від відповідальності щодо ризиків KuCoin.
Відмова від відповідальності: Для вашої зручності цю сторінку було перекладено за допомогою технології ШІ. Для отримання найточнішої інформації дивіться оригінальну англійську версію.