Журнал безпеки.

Посилено захист від DDoS-атак

Сайт і панель партнера стали стійкішими до перевантаження запитами.

Виправлено обробку неіснуючих сторінок

Звіт Tsabita показав, що частина неіснуючих адрес сайту повертала помилку сервера замість сторінки «не знайдено». Службових даних у відповідях не було. Помилку виправлено, такі адреси тепер відповідають коректно. Дякуємо за звіт.

Закрито вразливість ядра Linux CVE-2026-98432

У ядрі Linux виявлено вразливість CVE-2026-98432 в обробці вхідних TCP-з'єднань. Вона стосується серверів на Linux незалежно від того, який сервіс на них працює.

Ядра серверів платформи та робочих VPN-серверів партнерів на підтримуваних версіях системи оновлено до версії з виправленням.

Вирівняли обмеження публічної форми підтримки

Звіт Parth Narula показав, що у разі зміни адреси електронної пошти публічна форма підтримки приймала додаткові звернення. Ми вирівняли обмеження форми, і тепер зміна адреси не дає зайвих звернень. Дякуємо за відповідальне повідомлення.

Обмежено доступ до інтерфейсу служби підтримки

Зовнішній дослідник звернув увагу на те, що інтерфейс служби підтримки був доступний з інтернету. Інтерфейс вимагав автентифікації; ознак несанкціонованого доступу чи розкриття даних користувачів не виявлено.

Ми виключили службу підтримки з публічної поверхні: доступ дозволено лише з довірених адрес і через внутрішній канал. Налаштування інтерфейсу приведено у відповідність до робочого домену, обмеження перевірено із зовнішньої мережі.

Адресу повернення обмежено сторінками панелі

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

Тепер адреса повернення вибирається із закритого списку внутрішніх сторінок. Будь-яке інше значення веде на головну сторінку панелі. Виправлення покрито автоматичними негативними тестами.

Увімкнено примусове застосування DMARC

Дослідник безпеки виявив, що DMARC-політика createyourvpn.com працювала лише в режимі моніторингу й не вимагала відхиляти листи, які не пройшли перевірку. Ми ввімкнули p=reject для основного домену та sp=reject для його піддоменів, які не надсилають пошту. Транзакційні листи й надалі ізольовані на окремих піддоменах надсилання зі своїми політиками SPF, DKIM і DMARC.

Увімкнено MTA-STS і TLS-звіти

Дослідник безпеки виявив, що для вхідної пошти createyourvpn.com не були налаштовані MTA-STS і TLS-звіти. Ми опублікували політику MTA-STS та ввімкнули TLS-звіти. Спочатку політика працює в режимі testing, поки ми перевіряємо сторонній маршрут пересилання; примусове застосування ввімкнемо після чистих звітів.

Додано контроль сесій акаунта

Дослідник безпеки виявив, що копія токена партнерської сесії могла залишатися активною після виходу, якщо її було оновлено окремо. Ми перевели сесії на єдиний серверний ідентифікатор: тепер вихід відкликає всю поточну сесію, а дія «Вийти на всіх пристроях» завершує всі активні сесії.

У кабінеті з'явився розділ «Сесії акаунта». У ньому видно поточні входи з пристроєм, IP-адресою, часом входу та останньою активністю, а також історію успішних і невдалих спроб входу за 90 днів. Будь-яку сесію можна завершити окремо або завершити всі одразу.

Enabled DNSSEC

A researcher found that DNSSEC was not enabled for createyourvpn.com. We signed the DNS zone, published the DS record in .com, and verified the chain of trust.

Посилили захист публічної форми підтримки

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

Керування сесіями та надсилання кодів входу

За звітами зовнішнього дослідника ми переглянули дві суміжні ділянки: життєвий цикл партнерської сесії та шлях листа з кодом входу. Доступу до акаунтів, даних партнерів чи трафіку користувачів жодна зі знахідок не давала.

Security-заголовки на сторінках вітрин

Вітрини партнерів не віддавали security-заголовків, які панель і API віддавали давно, — зокрема того, що забороняє чужим сайтам показувати сторінку у фреймі. Прочитати так дані акаунта чи сесію було неможливо. Тепер повний набір іде з кожною відповіддю вітрини, а твердження SR-15 називає кожен фронтенд, який ми розміщуємо.

Користувач може сам скинути своє посилання на підписку

Посилання на підписку — це секрет: той, хто його має, отримує такий самий доступ, як і власник. Користувач може скинути його сам в особистому кабінеті — попереднє посилання перестає працювати, а доступи за ним видаються заново. Закрите так посилання лишається закритим, зокрема й після відновлення даних із резервної копії.

Адреси користувачів вітрин більше не зберігаються

Людина вводить свій email, щоб увійти до вітрини партнера, але в нас ця адреса не осідає: лист із кодом іде, і адреса одразу видаляється. Обліковий запис упізнається за необоротним відбитком, з якого адресу не відновити, а ім'я запису її не містить.

Обмежено доступ до панелі керування інфраструктурою

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

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

Видалено невикористовуваний спосіб авторизації партнерського API

API підтримував додатковий cookie-шлях авторизації, який не потрібен поточній server-side архітектурі. Підтвердженої міжсайтової атаки в production не виявлено, проте зайвий шлях збільшував поверхню майбутніх помилок. API переведено на один явно визначений спосіб авторизації й покрито негативними тестами.

Гарантовано очищення керуючого ключа після видалення сервера

Очищення зашифрованого керуючого ключа виконувалося після фонових мережевих операцій і могло не повторитися в разі їхнього збою. Ми відокремили очищення ключа від мережевого каскаду й додали гарантоване повторення. Сценарії недоступного сервера та переривання процесу покрито тестами.

Розділено криптографічні ключі платформи за призначенням

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

Скорочено публічну поверхню production API

Інтерактивна технічна документація API була доступна без автентифікації. Це не давало доступу до захищених даних, але полегшувало вивчення внутрішньої структури API. У production документацію тепер вимкнено, а для розробки вона лишається доступною в ізольованому середовищі.

Додано захист від небезпечної cross-origin конфігурації

Поточна production-конфігурація не дозволяла довільні origins, проте код допускав небезпечне поєднання параметрів у разі помилки оператора. Тепер така конфігурація відхиляється під час запуску і покрита автоматичним тестом.

Внутрішня перевірка перед запуском програми

15 липня 2026 року ми розпочали внутрішню перевірку безпеки CreateYourVPN. Виправлення, які ми завершили та перевірили повторно, опубліковано нижче; решта з'являтимуться в міру розгортання та підтвердження.