Конец поддержки осенью 2026: PHP 8.2, PostgreSQL 14, Python 3.10

Осень 2026 года — плотный сезон окончания поддержки. 1 октября исправления безопасности перестал получать Python 3.10, 12 ноября то же случится с PostgreSQL 14, 31 декабря — с PHP 8.2. После этих дат найденные уязвимости в старых версиях больше не исправляются. Собрали даты из официальных источников и сделали проверку: введите свои версии и узнайте, сколько дней осталось.

Что заканчивается и когда

Отдельно напомним: PHP 8.1 и старше не получают обновлений от разработчиков PHP с конца 2025 года, Node.js 20 — с 30 апреля 2026 года, PostgreSQL 13 — с 13 ноября 2025 года.

Почему это важно именно сейчас

21 октября 2026 года разработчики PHP выпустили срочные обновления 8.5.12, 8.4.27, 8.3.36 и 8.2.35 — они закрывают две критические уязвимости, о которых мы подробно писали в материале про PHP2Shell. По данным OpenNET, для PHP 8.1 и более старых веток официальных исправлений нет. Это наглядный пример: пока версия поддерживается, уязвимость закрывается обновлением за один день. После окончания поддержки — только переездом.

С PostgreSQL похожая логика. 12 ноября выйдет последний выпуск 14-й ветки. Если после этого найдут уязвимость, исправления для 14 не будет.

Кого касается

• сайтов на WordPress и 1С-Битрикс, где хостинг до сих пор держит PHP 8.2;
• CRM, личных кабинетов и интернет-магазинов на PostgreSQL 14;
• ботов, парсеров и интеграций на Python 3.10;
• серверов на Node.js 20 и 22.

Что делать

1. Узнайте реальные версии на боевом сервере: `php -v`, `psql --version` или `SELECT version();`, `python3 --version`, `node -v`. Версия в документации проекта и на сервере часто различается.
2. Введите их в проверку ниже — она покажет статус и число дней до конца поддержки.
3. Для PHP 8.2 запланируйте переход на 8.4 или 8.5 до конца декабря. Проверьте совместимость плагинов и модулей на тестовой копии сайта.
4. Для PostgreSQL 14 готовьте переход на 17 или 18: обновление мажорной версии делается через `pg_upgrade` или выгрузку и загрузку, нужна резервная копия и окно работ.
5. Для Python 3.10 — переход на 3.13 или 3.14, с явным указанием кодировок при работе с файлами.
6. Если сразу обновиться нельзя, уточните у хостинга или поставщика дистрибутива: некоторые выпускают свои исправления для старых версий дольше официального срока.

Кому можно не спешить

• Проектам на PHP 8.3, 8.4 и 8.5: исправления безопасности для них выходят до конца 2027, 2028 и 2029 года соответственно.
• Проектам на PostgreSQL 15–18: ближайший срок — у 15-й ветки, 11 ноября 2027 года.
• Проектам на Node.js 24 и 26: поддержка до апреля 2028 и апреля 2029 года.
• Проектам на Python 3.12–3.14: исправления выходят до октября 2028–2030 года.

Им достаточно ставить минорные обновления по мере выхода.

Если обновиться быстро нельзя

Бывает, что сайт держится на старом модуле или плагине, который не работает на новой версии, а переписать его быстро не получается. В этом случае важно не делать вид, что проблемы нет, а снизить риск:

• закройте админку и служебные разделы по IP или дополнительной авторизации;
• уберите с сервера неиспользуемые скрипты, тестовые копии и старые бэкапы в публичных папках;
• поставьте веб-фильтр (WAF) на уровне хостинга или CDN;
• включите мониторинг изменений файлов и регулярные резервные копии с хранением вне сервера;
• уточните у хостинга, выпускает ли он собственные исправления для старой ветки и до какого срока.

Это даёт время, но не заменяет обновление. Срок такой отсрочки стоит записать и согласовать, а не продлевать бесконечно.

Как спланировать обновления до Нового года

Логичный порядок — от самого близкого срока и самого опасного компонента. PostgreSQL 14 — первым: до 12 ноября меньше трёх недель, и переход мажорной версии требует окна работ. Затем PHP 8.2: у сайтов на CMS много плагинов, и их совместимость проверяется дольше всего. Python 3.10 уже вне поддержки — если он отвечает за интеграцию с платёжными или персональными данными, его стоит поднять параллельно.

Хорошая практика — делать обновления на тестовой копии, с резервной копией и планом отката. И фиксировать версии в документации проекта, чтобы следующий раз не начинать с вопроса «а что у нас стоит».

Наше мнение

Мы считаем, что календарь обновлений — такая же обязательная часть поддержки сайта, как резервные копии. Проблема обычно не в сложности обновления, а в том, что о сроке вспоминают после инцидента. Что мы советуем клиентам: раз в полгода сверять версии всех компонентов с официальными графиками и закладывать обновления в план работ заранее. Подробнее о подготовке PHP-проектов — в статье об устаревшем PHP на хостинге.