Минор PHP закрывает инъекцию в pgsql на Bitrix с PostgreSQL
На Bitrix с PostgreSQL дыра в PHP, не в СУБД: как сверить php -v с порогами security-минора и не принять патч базы за закрытие.
В меню СУБД на BitrixVM «всё нормально», а php -v всё ещё ниже порога security-патча. После волны релизов PHP легко закрыть PostgreSQL и забыть runtime — для этой дыры это неверный рефлекс.
Риск сидит в расширении ext-pgsql, а не в миноре самой СУБД. Закрывает его security-минор PHP в своей ветке: ни major-апгрейд «на следующую восьмёрку», ни патч PostgreSQL сам по себе эту CVE не снимают.
Как это выглядит на парке
Типичная картина после конца июля 2026: образ VM свежий, major PostgreSQL в меню устраивает, а на хостах с PostgreSQL PHP всё ещё ниже 8.2.33 / 8.3.33 / 8.4.24 / 8.5.9. Ждут новый ISO или «закрывают» только СУБД — и считают тему закрытой.
На практике дыра остаётся в PHP runtime. Пока мониторинг версий смотрит только major в меню BitrixVM, расхождение не всплывает, пока его не сверят руками через php -v.
Где именно дыра
PHP Group 30 июля 2026 выпустил security-релизы 8.2.33, 8.3.33, 8.4.24 и 8.5.9. В changelog среди прочего — фикс для PGSQL: SQL-инъекция через breakout escape-строки E'...' (GHSA-7qpv-r5mr-78m4 → CVE-2026-17543).
Затронут пакет PHP ext-pgsql. Уязвимы версии ниже указанных порогов; патч — ровно эти миноры и новее в той же ветке.
Механизм короткий: хелперы экранируют через PQescapeStringConn(), затем результат оборачивают в escape-string constant E'...'. При standard_conforming_strings = on (дефолт PostgreSQL с 9.1) бэкслэш после такого экранирования снова становится управляющим — строка ломается, появляется путь к инъекции.
Затронутые API: pg_insert(), pg_update(), pg_select(), pg_delete() и путь через pg_convert() / php_pgsql_convert(). Upstream-фикс — оборачивать параметры в обычные (non-escaping) строковые константы вместо E'...'.
Оценки severity расходятся по шкалам: GitHub advisory — High; в security-прессах (IONIX / SecurityOnline) фигурирует CVSS 4.0 ≈ 8.1; в разборах также встречается CVSS 3.1 9.8. Это разные шкалы — не сводить к «одной цифре». На момент обзоров подтверждённой эксплуатации in the wild не было; патчи доступны.
Что этим CVE не закрывается
Не всё, что касается PostgreSQL из PHP, попадает под эту дыру. Имеет смысл держать границы явно:
- pg_query_params() с server-side binding $1 — не этот escape-path.
- PDO_PGSQL prepared statements и PDO::quote() — отдельный quoter, не php_pgsql_add_quotes().
- Сырой pg_query() с ручным SQL — не баг хелперов; риск остаётся на стороне кода приложения.
- Патч только PostgreSQL (минор СУБД) не закрывает дыру в PHP runtime.
Для стека Bitrix: PostgreSQL официально на лицензиях «Энтерпрайз для Постгрес»; подключение — класс \Bitrix\Main\DB\PgsqlConnection. В публичных зеркалах исходников соединение идёт через pg_connect, вывод запросов — pg_query. Это факт стека на ext-pgsql, но не доказательство, что ядро Битрикса эксплуатируется через pg_select / pg_insert без аудита call-sites. Утверждать «ядро уязвимо к 17543» нельзя.
Практический риск для парка: PHP ниже патча на хостах с PostgreSQL плюс любой код — кастом, маркет, CLI, интеграции — который кормит затронутые хелперы недоверенным вводом. Плюс обычная гигиена: держать security-минор PHP.
BitrixVM: PHP сам не подтянется
По документации урока BitrixVM «Update PHP, MySQL, PostgreSQL» PHP, MySQL и PostgreSQL не обновляются автоматически при обновлении виртуальной машины. Ручной путь: 1. Manage servers in the pool → 6. Update PHP, MySQL, PostgreSQL.
С BitrixVM 9.0.4 PHP по умолчанию — 8.2; в меню есть major-апгрейд до 8.3 / 8.4 / 8.5; минимум для продуктов — 8.2. Поддержка PostgreSQL — с 9.0.8; major PG в меню — до 15, затем 16. Это major СУБД, не security-минор PHP.
Линейка скачивания VMBitrix 9.0.x (в том числе 9.0.10 от 25.03.2026) с PG 13.x / 15.x / 16.x и PHP 8.x сама по себе не гарантирует PHP ≥ 8.2.33 / 8.3.33 / 8.4.24 / 8.5.9. Helpdesk коробочного Битрикс24 с 01.02.2026 ограничивает поддержку продуктов на PHP < 8.2 и рекомендует 8.3+; обновление PHP на VMBitrix — через то же меню pool.
Как проверить и что сделать
- Сверить по парку: php -v / пакет PHP на каждом хосте с порогами 8.2.33 / 8.3.33 / 8.4.24 / 8.5.9.
- Не путать пункт меню «Upgrade PHP to 8.4» (major) и уже стоящий 8.4.x ниже 8.4.24 — нужен security-минор той же ветки.
- Не ждать новый ISO и не считать патч PostgreSQL закрытием CVE-2026-17543.
- После патча PHP — рестарт php-fpm, проверка сайта и агентов; убедиться, что мониторинг версий смотрит не только major.
Соседний операционный сигнал недели: 3 августа 2026 Pantheon выкатил на платформу те же миноры 8.2.33 / 8.3.33 / 8.4.24 / 8.5.9 именно из‑за CVE-2026-17543 — индустрия догоняет патч после 30 июля.
Частые вопросы
Закрывает ли патч PostgreSQL CVE-2026-17543?
Нет. Дыра в PHP ext-pgsql — в хелперах с обёрткой E'...', а не в миноре СУБД. Нужен security-минор PHP своей ветки: 8.2.33, 8.3.33, 8.4.24 или 8.5.9.
Какие версии PHP считаются закрытыми для этой инъекции?
По advisory уязвимы версии ниже 8.2.33, 8.3.33, 8.4.24 и 8.5.9. Патч — эти релизы и новее в той же ветке. Сверяйте фактический php -v на каждом хосте, а не только major в меню BitrixVM.
Значит ли это, что ядро Битрикса эксплуатируется через pg_insert и pg_select?
Нет без аудита call-sites. Класс PgsqlConnection опирается на ext-pgsql (pg_connect / pg_query), но это не доказательство вызова уязвимых хелперов из ядра. Риск — PHP ниже патча плюс код, который кормит pg_insert / pg_select / pg_update / pg_delete / pg_convert недоверенным вводом.
Достаточно ли major-апгрейда PHP в меню BitrixVM?
Не обязательно. Major (например, «на 8.4») и security-минор внутри ветки — разные операции. Уже стоящий 8.4.x ниже 8.4.24 всё ещё уязвим, пока пакет не подтянут до порога. PHP на BitrixVM при обновлении VM сам не обновляется — путь через меню pool.
Как BX Pulse помогает на этом стеке
BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и помогает вовремя замечать расхождения версий runtime до обращения клиента. Имеет смысл держать под контролем фактический минор PHP на хостах с PostgreSQL, а не только major в меню VM.
