POC-AIOWPM-CVE-2026-19949 — Воспроизводимый proof-of-concept на основе Docker для CVE-2026-19949 — SQL-инъекции второго порядка в All-in-One WP Migration <= 7.109, которая раскрывает ai1wm_secret_key через анонимный REST и приводит к удалённому выполнению кода. | Kitploit

Проблема в *negative lookbehind* `(?<!\\)`: **он проверяет только один байт**
перед каждой кандидатной закрывающей кавычкой, а не подсчитывает весь *run*
обратных слешей. В дампе MySQL данные, заканчивающиеся на `\`, записываются как
`...\\'` — закрывающая кавычка, перед которой стоит **чётное** число обратных
слешей (реальная строка, заканчивающаяся обратным слешем) — но regex считает её
экранированной и **перехватывает следующий литерал**. Затем callback выполняет
`unescape_mysql → replace_serialized_values → escape_mysql` над
перехваченным значением, и этот цикл заново выдаёт несбалансированную
последовательность кавычек/обратных слешей, которая **переворачивает границу
строки MySQL** в результирующем операторе, превращая данные атакующего в
исполняемый SQL.

## 2. Корневая причина: regex, переворачивающий строку

С установленным trackback (см. §4), строка в `database.sql` выглядит так:```sql
INSERT INTO `…_comments` VALUES (2,4,'Jack Blogs\\\\','','/*payload*/…','172.18.0.1',…);

Начиная с этого момента, всё, что следует дальше в строке, повторно токенизируется с изменённой чётностью (данные, которые были строкой, становятся кодом и наоборот). Исправленный regex версии 7.110 обрабатывает ту же строку и возвращает её **идентичной**.

Вы можете увидеть это побайтово, ничего не эксплуатируя, с помощью `make demo-flip` (`exploit/04_demo_flip.php`), который выполняет НАСТОЯЩИЙ код плагина 7.109 и 7.110 на одной и той же строке дампа.

## 3. Патч (7.109 → 7.110)```diff
- $input = preg_replace_callback( "/'(.*?)(?<!\\\\)'/S", array( $this, 'replace_table_values_callback' ), $input );
+ $input = preg_replace_callback( "/'((?:[^'\\\\]++|\\\\.)*+)'/sS", array( $this, 'replace_table_values_callback' ), $input );

Внедрение (без аутентификации) — атакующий отправляет trackback'и на публичную запись с открытыми пингами (wp-trackback.php?p=<id>). Blog name (→ comment_author) заканчивается на \, а URL (→ comment_author_url) несёт payload. WordPress сохраняет их, не трогая обратный слеш. В опубликованном варианте первый trackback действует как бомба замедленного действия: он принудительно обрывает проход импорта (лимит 10 с), чтобы payload выполнился в последующем проходе, когда импортёр уже восстановил ai1wm_secret_key сайта в wp_options (экспортёр исключает её из дампа; импортёр перезаписывает её между проходами).
Срабатывание (действие администратора) — администратор экспортирует и восстанавливает сайт. Во время импорта уязвимый regex переписывает строку trackback'а: граница строки переворачивается, и payload превращается в исполняемый SQL.
Фильтрация — payload копирует ai1wm_secret_key в одобренный комментарий типа comment, видимый в REST API комментариев без аутентификации.
RCE — admin-ajax.php?action=ai1wm_import также зарегистрирован для анонимных пользователей (wp_ajax_nopriv_ai1wm_import), и его единственный барьер — ai1wm_verify_secret_key(). С отфильтрованным ключом атакующий проводит цепочку импорта со своим .wpress, который включает mu-plugin; шаг Ai1wm_Import_Mu_Plugins (приоритет 270 в цепочке) извлекает его в wp-content/mu-plugins/ → выполнение кода при следующей загрузке.

Blog name заканчивается на \ → lookbehind в один байт уязвимого regex'а перехватывает следующий литерал, и цикл unescape→escape переворачивает границу строки.
После переворота URL атакующего остаётся как голый SQL-код в INSERT-выражении (слитый comment_author и строка , поглощают смещение; начальная запятая в URL восстанавливает структурный разделитель, который был поглощён).
URL предоставляет 12 оставшихся выражений кортежа с hex-литералами и /**/ в качестве разделителей:
- кавычка данных попадает в дамп как \' и в зоне кода оставила бы осиротевший обратный слеш (ошибка 1064) → отсюда hex (0x616931776d… = "ai1wm_secret_key");
- sanitize_url удаляет пробелы (и добавляет http:// ко всему, что не начинается с /) → отсюда старт /*pwn*/ и /**/;
- сопоставление столбцов: 5-й (comment_author_url) = подзапрос, который читает ключ → ключ оказывается в публичном поле; 11-й = 0x31 ('1', одобренный комментарий); 13-й = 0x636f6d6d656e74 ('comment', видимый в анонимной REST);
- ) закрывает кортеж ровно с 15 значениями, а # (MySQL-комментарий без пробела, который sanitize_url сохраняет) нейтрализует остаток исходного выражения.
Подзапрос ссылается на SERVMASK_PREFIX_options: импортёр переписывает префиксы SERVMASK→реальные до прохода regex'а, поэтому payload работает на сайтах с любым префиксом таблиц (проверено). Единственные специфичные для цели данные — её URL, переносимый в excerpt для срабатывания фильтра strpos импортёра (он переписывает только строки, которые его содержат).

Шаг цепочки	Статус	Где
Воспроизводимая уязвимая установка (WP 7.1 + плагин 7.109)	✅	`make lab`
Внедрение без аутентификации через trackback (байт-точно, авто-одобрено)	✅	`make plant`
Экспорт администратора; дамп содержит внедрённую строку	✅	`make export`
Корневая причина: regex 7.109 переворачивает границу строки (в отличие от 7.110, где она цела)	✅	`make demo-flip`
Восстановление администратора: переворот переписывает SQL и повреждает/теряет строку в 7.109	✅	`make restore`
Фильтрация ключа (собственный производный payload) → реальная утечка через REST без аутентификации	✅	`make leak`
RCE: неаутентифицированный импорт с ключом → выполненный mu-plugin	✅	`make rce-auto`
Отрицательный контроль: в 7.110 строка выживает нетронутой, без утечки	✅	`make control-7110`
Матрица WP 7.1 / 7.0.4 / 6.9.4 / 6.8.3: полная цепочка ✓ во всех	✅	`research/test-wp-versions.sh`
Полная удалённая цепочка (только HTTP, применимо к реальному домену)	✅	`python3 cli/poc.py explotar …`

docker-compose.yml WordPress (php8.2-apache) + MySQL 8; PLUGIN_VERSION y WP_VERSION configurables (7.109 por defecto, 7.110 control) docker/wordpress/Dockerfile imagen del sitio víctima: wp-cli + plugin de WordPress.org setup/init.sh core install, activa el plugin, crea la entrada con pings abiertos, comentarios sin moderación exploit/ ← fases numeradas de la PoC 01_plant_trackback.sh Fase 1 — trackback malicioso (no autenticado) 02_export.sh Fase 2a — export del admin (vía aiowpm_client) 03_restore.sh Fase 2b — restauración del admin + ANTES/DESPUÉS de la fila 04_demo_flip.php Causa raíz byte a byte: regex 7.109 vs 7.110 05_build_wpress.py Construye el .wpress malicioso (package.json + mu-plugin) 06_rce_unauth.py Fase 3 — import no autenticada con la clave → RCE 07_leak_key.sh Fase 3a — lee la clave filtrada de la REST anónima aiowpm_client.py Cliente del protocolo AJAX del plugin (export/import por prioridades, como su JavaScript) wpress.py Lector/escritor del formato .wpress (bloques de 4377 B) mu_plugin.php Mu-plugin BENIGNO (marcadores de evidencia, sin shell) investigacion/ Arneses y fuzzers con los que se DERIVÓ el payload: harness.php (pipeline real del plugin + MySQL de prueba), afinar/test/fuzzers, NOTAS.md del análisis cli/poc.py CLI de demostración: lab / scan / verificar / explotar web/index.html Landing bilingüe del CVE (estilo base de datos de vulnerabilidades; sin dependencias externas) research/ test-wp-versions.sh Matriz de compatibilidad por versión de WordPress poc-publica/ANALISIS.md Refutación forense de las «PoC públicas» falsas Makefile Objetivos: lab, plant, export, restore, demo-flip, leak, rce-auto, full-demo, control-7110, demo-cli… README.md / README.en.md Esta documentación (ES/EN) .gitignore Fuera: informes con claves, .wpress generados, zips y fuentes del plugin (terceros), PoC falsas descargadas

Artefactos que se generan al ejecutar y **no se comparten** (ver `.gitignore`):
`informes/` (contienen claves filtradas), `exploit/malicious.wpress`,
`plugin-src/` (fuentes 7.109/7.110 extraídas para diff), `research/*.zip`
(zips originales de WordPress.org), `research/database.sql`,
`research/backup-legit.wpress` y los ficheros de las PoC falsas analizadas.

## 9. Requisitos y arranque rápido

Requisitos: Docker (con el plugin compose), make, python3 con `requests`, curl.```bash
make full-demo      # laboratorio completo de cero: lab → plant → export →
                    # restore → flip → leak → rce (todo lo anterior de una vez)

Доступ к сайту жертвы: <http://localhost:8080> — admin / `admin-password-123`
(публичная запись ID 4 с пингами и открытыми комментариями).

## 10. Пошаговые фазы (цели make)```bash
make lab             # levantar/inicializar el laboratorio (plugin 7.109)
make plant           # Fase 1 — plantar el trackback (anónimo)
make export          # Fase 2a — exportar como admin
make restore         # Fase 2b — restaurar como admin (muestra ANTES/DESPUÉS)
make demo-flip       # causa raíz: 7.109 vs 7.110 sobre la misma línea
make leak            # Fase 3a — leer la clave filtrada de la REST (anónimo)
make rce KEY=XXXX    # Fase 3 — RCE pasando la clave a mano
make rce-auto        # Fase 3 — RCE encadenado con la clave filtrada
make control-7110    # control negativo con el plugin parcheado
make lab-7109        # volver al laboratorio vulnerable tras el control
make demo-cli        # demo completa vía CLI (+ informe y control negativo)
make scan-cli URL=https://www.ejemplo.com   # detección no invasiva
make landing         # servir la landing del CVE en http://localhost:8090
make status | logs   # estado de contenedores / log de WordPress
make down | clean    # parar / parar y borrar volúmenes y artefactos

- `lab` поднимает лабораторию, выполняет всю цепочку и контрольный
  негативный тест с 7.110, и пишет отчёт (`--sin-control` для пропуска).
- `scan` на 100 % пассивен: читает публичный `readme.txt` плагина, проверяет
  `wp-trackback.php` и REST комментариев. Возвращает вердикт.
- `verificar` повторно проверяет, появился ли ключ уже в анонимной REST (например,
  спустя часы после внедрения, когда админ сделал свой backup+restore).
- `explotar` ИНВАЗИВЕН и требует `--acepto-responsabilidad` + интерактивное
  подтверждение домена: внедряет trackback, имитирует админа
  (export → скачивание backup → повторная загрузка и restore; **только HTTP**, с
  учётными данными, которые ТЫ предоставляешь для СВОЕГО сайта), читает утёкший ключ и, с
  `--rce`, оставляет безвредный маркер через анонимный импорт. Без учётных данных
  админа: внедряет и остаётся в ожидании (`--esperar` для ожидания утечки;
  `--post-id` для выбора записи; `--no-interactivo` для скриптов).

## 12. Landing CVE

Статическая двуязычная страница (ES/EN, переключатель в шапке, предпочтение
запоминается), объясняющая CVE и payload в эстетике базы данных
уязвимостей: сводка, цепочка, **интерактивная разборка payload
сегмент за сегментом**, матрицы проверки и смягчения.```bash
make landing          # sirve http://localhost:8090

CVE	CVE-2026-19949
Плагин	All-in-One WP Migration and Backup (ServMask), ≤ 7.109
Патч	7.110 (20 августа 2026)
CVSS	8.8 (Высокий) — AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Условие	Администратор экспортирует и восстанавливает сайт (рутинное действие с этим плагином)
Исследователь	Jack Taylor (программа вознаграждений Wordfence)

POC-AIOWPM-CVE-2026-19949

Популярное

Содержание

1. Обзор уязвимости

4. Полная цепочка атаки

5. Производный payload (собственная разработка)

6. Что воспроизводит и проверяет этот репозиторий

7. Совместимость версий (проверена)

8. Структура репозитория```

11. CLI демонстрации

13. Обнаружение и смягчение

14. Примечания к исследованию

15. Ссылки

16. Правовое уведомление

WordPress	plant	export	restore	leak	RCE
7.1.0	✓	✓	✓	✓	✓
7.0.4	✓	✓	✓	✓	✓
6.9.4	✓	✓	✓	✓	✓
6.8.3	✓	✓	✓	✓	✓