Платформа розсилок Substack повідомила про витік даних користувачів, у межах якого були скомпрометовані адреси електронної пошти, номери телефонів та службові метадані акаунтів. Атака, за даними компанії, відбулася ще в жовтні 2025 року, але сліди інциденту виявили лише на початку лютого. Тим часом на хакерському форумі BreachForums уже з’явився дамп із 697 313 записами, що нібито належать Substack.
Масштаб витоку даних Substack та офіційна позиція компанії
Генеральний директор Substack Кріс Бест у листі постраждалим користувачам заявив, що неавторизована сторона отримала доступ до «обмеженого набору даних». За офіційною версією, паролі, реквізити банківських карток та інша фінансова інформація не були зачеплені, випадків прямої компрометації облікових записів не зафіксовано. Компанія також повідомила, що виявлену уразливість вже усунули, а додатковий аудит безпеки триває.
Однак опублікований на BreachForums масив із 697 313 записами викликає запитання щодо реальних масштабів інциденту. Автор дампу стверджує, що дані були зібрані шляхом скрапінгу (автоматизованого масового збору інформації з веб‑ресурсів) і зазначає, що «метод був шумним», тобто супроводжувався великою кількістю однотипних запитів, які теоретично мали б бути помітними у системах моніторингу безпеки.
Які дані потрапили до зловмисників і чому це небезпечно
Substack підтвердила витік трьох основних категорій даних: e‑mail‑адрес користувачів, номерів телефонів, прив’язаних до акаунтів, а також службових метаданих. Метадані — це технічна інформація про акаунт і його активність: дата створення, налаштування підписок, параметри взаємодії з платформою тощо. Хоча такі відомості не дають безпосереднього доступу до облікового запису, вони істотно підвищують точність профілювання користувача.
Комбінація e‑mail + телефон + метадані має високу цінність для кіберзлочинців. Вона дозволяє будувати реалістичні сценарії фішингових атак і соціальної інженерії, адаптовані під конкретного адресата: згадувати у листі конкретного автора розсилки, тип контенту або частоту взаємодії з платформою. Такий таргетований підхід істотно підвищує ймовірність того, що користувач перейде за шкідливим посиланням або розкриє конфіденційні дані.
Скрапінг і уразливості API: як технічно міг статися витік
Офіційно Substack не розкриває подробиць експлуатації уразливості. Пост на BreachForums вказує на використання скрапінгу, який у нормі працює лише з публічно доступною інформацією. Проте помилки в логіці API, недоліки авторизації чи некоректні налаштування прав доступу можуть призвести до того, що через автоматизовані запити вдається отримати дані, які не повинні бути видимими ані публічно, ані без додаткової автентифікації.
Згадка про «шумний» метод збору вказує на великий обсяг однотипних запитів за короткий час. У зрілих системах безпеки подібну активність мають виявляти системи виявлення аномалій, журнали доступу та поведінкова аналітика. Інцидент Substack ще раз підкреслює критичну важливість регулярного тестування безпеки API, включно з penetration‑тестами та перевіркою контролю доступу на рівні кожної окремої операції.
Ризики для користувачів: фішинг, smishing та соціальна інженерія
Попри те, що паролі не потрапили у відкритий доступ, наслідки витоку для користувачів можуть бути відчутними. Типова практика показує, що подібні масиви даних використовують для масових фішингових розсилок від імені платформи або окремих авторів newsletter‑ів, а також для smishing‑атак (фішинг через SMS і месенджери). Мета таких кампаній — виманити одноразові коди, логіни й паролі, дані банківських карток або змусити жертву відкрити шкідливе посилання.
Згідно з галузевими звітами, зокрема Verizon Data Breach Investigations Report, значна частина успішних інцидентів безпеки починається з фішингу та людських помилок, а не зі складних технічних експлойтів. У контексті витоку Substack це означає, що навіть «обмежений» за типом даних інцидент може стати відправною точкою для нової хвилі атак на користувачів платформи та інші сервіси, прив’язані до тих самих контактів.
Попередні інциденти Substack та уроки для сервісів розсилок
Це не перший раз, коли безпека даних Substack опиняється у фокусі уваги. У 2020 році компанія вже стикалася з витоком адрес e‑mail через помилку в налаштуванні розсилки: частина адрес потрапила в поле «Кому» замість «Скринька прихованої копії» (BCC), що дозволило отримувачам бачити поштові адреси інших підписників. Тоді йшлося про людський фактор та процесні недоліки, однак і нинішній інцидент демонструє, що для платформ масових розсилок критично важливі як технічний захист, так і коректна обробка персональних даних.
Рекомендації з кібербезпеки для користувачів Substack та онлайн‑сервісів
Користувачам Substack варто вважати свої контактні дані потенційно скомпрометованими та посилити базову кібергігієну. Йдеться про уважне ставлення до листів і SMS, навіть якщо вони виглядають як офіційні повідомлення Substack, банків чи популярних сервісів; перевірку адреси сайту через ручний ввід у браузері, а не перехід за посиланням з листа; обов’язкове увімкнення двохфакторної автентифікації (2FA) та використання унікальних складних паролів, бажано через менеджер паролів.
Онлайн‑сервісам інцидент із витоком даних Substack слугує нагадуванням про необхідність безперервного тестування безпеки API, впровадження систем аналізу аномальної активності, детального журналювання запитів і прозорих процедур сповіщення користувачів про інциденти. Регулярні аудити, навчання персоналу та чіткі процеси реагування на інциденти стають ключовими елементами стратегії захисту персональних даних.
Історія з витоком даних Substack показує, що навіть без компрометації паролів і платіжної інформації контактні дані та метадані акаунтів можуть перетворитися на потужний інструмент у руках зловмисників. Щоб мінімізувати ризики, варто проактивно підвищувати рівень своєї кіберграмотності, регулярно переглядати налаштування безпеки, не ігнорувати попередження про підозрілу активність і з обережністю ставитися до будь‑яких запитів, пов’язаних з особистими даними.
