21 октября были раскрыты две критические уязвимости PHP — CVE-2026-109618 и CVE-2026-109619, обе с CVSS 9.2. Их эксплуатация позволяет выполнять код без аутентификации с правами веб-сервера.
Уязвимым можно считать PHP с версии 5.4. Что интересно, уязвимости были найдены с помощью нейросетей (Gemini 4 Argon + GPT-5.6 Sol), а размер патча составляет больше 10 тысяч строк кода.
21 октября разработчики PHP выпустили исправления для двух критических уязвимостей — CVE-2026-109618 и CVE-2026-109619, известных как PHP2Shell. Обе затрагивают сам интерпретатор PHP и при определенных условиях позволяют выполнить код на сервере без авторизации. Для атаки необязательно находить ошибку в WordPress, Laravel или другом приложении, так как проблема находится уровнем ниже.
О механике этих уязвимостей уже достаточно написано. Мы сосредоточимся на обновлении работающего сервера: что проверить до установки патча, как обновить PHP через ispmanager или пакетный менеджер Linux и убедиться, что исправленная версия действительно обслуживает сайт.
21 октября 2026 года мир PHP вздрогнул от анонса двух критических RCE-уязвимостей (CVSS 9.2), получивших общее имя PHP2Shell (CVE-2026-109618 и CVE-2026-109619). Опасность этих брешей в том, что они срабатывают на уровне ядра интерпретатора еще до того, как управление дойдет до первой строчки вашего index.php. Достаточно, чтобы сервер просто принимал HTTP-запросы.
Разработчики PHP оперативно выпустили патчи для поддерживаемых веток (8.2.35, 8.3.36, 8.4.27, 8.5.12) и заявили: «Единственный 100% способ защиты - обновление, а сценарий наивысшего риска - это Apache с mod_php».
Звучит отлично, если у вас свежий проект. А что делать, если в продакшене крутится суровый высоконагруженный энтерпрайз-легаси на PHP 5.6 в связке с Apache 2.4 (mpm_prefork + mod_php), переписать который за ночь невозможно, а официальных патчей для ветки 5.6 не выйдет никогда?
Под катом - практический разбор того, как устроены обе уязвимости, почему именно mod_php оказался под главным ударом и как я выстроил эшелонированную оборону на уровне Varnish → Apache → PHP → Docker cgroups, не сломав легаси-монолит и проверив каждый рубеж боем (с разбором подводных камней HTTP keep-alive).
Выгрузка сделок из Битрикс24 годами работает без проблем, а потом начинает тормозить и возвращать HTTP 429. Увеличение пауз между запросами не помогает, хотя остальные методы REST API продолжают отвечать как обычно. Разбираемся, как устроен лимит OPERATION_TIME_LIMIT, куда уходит серверное время и как ускорить выгрузку в сотни раз.
21 октября PHP выпустил внеплановые релизы 8.5.12, 8.4.27, 8.3.36 и 8.2.35: они закрывают две критические уязвимости (CVSS 4.0 — 9.2), допускающие выполнение кода без аутентификации. Разбираем, кого это касается, как проверить, какая версия PHP реально обслуживает веб, как обновиться (пакеты, Docker) и какие временные меры допустимы, если обновиться сразу нельзя.
21 октября PHP выпустил экстренные версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Они закрывают две критические RCE без авторизации (CVSS 9.2), одна из которых срабатывает ещё до кода вашего приложения. Разбираем бюллетени, даём скрипт для проверки всех PHP на сервере и временные меры для тех, кто не может обновиться сегодня. Для PHP 7.x и 8.0/8.1 исправлений не будет.
В первой статье я не хотел прогонять ссылки через чужой редирект, который умрет вместе с триалом. Теперь редирект у меня свой: что я пообещал в оферте, как устроен r.php без CMS, почему ссылка иногда висит в статусе «проверяется», при чем тут Роскомнадзор и как считать статистику переходов, не храня IP.
Почти в каждом проекте рано или поздно появляется запрос «чтобы без перезагрузки». И рядом с PHP вырастает второй кусок: фронтенд со сборщиком, node_modules, API между двумя частями, валидация в двух местах, а состояние то на сервере, то в браузере. Меня это достало, и я создал rig. Это PHP-фреймворк, где интерфейс откликается сразу, а приложение остаётся обычным PHP-проектом. Расскажу, как он устроен, что уже работает и где его лучше не использовать.
Если уже программируете и присматриваетесь к PHP, с чего начать? Вопрос о выборе языка часто превращается в спор о том, какой из них лучше. Мне стало интересно, что стоит за рекомендациями. Какие задачи человек решает на этом языке и почему продолжает его выбирать? Об этом я спросила backend-разработчика в крупной промышленной компании – Антона Елохина. Он поделился личным опытом, довольно прямыми оценками фреймворков и своим маршрутом знакомства с языком PHP – получился небольшой авторский обзор с полезными ссылками и примером приложения от Антона.
В этой статье речь пойдёт о том, как разработать и запустить собственный аудиосервис на площадке Bitcord Open Network. Напомню, что Bitcord по сути, это небольшая открытая социальная платформа, выполненная в виде приложения для смартфонов и работающая на базе клиент-серверной архитектуры. Здесь можно общаться с друзьями и коллегами, создавать публичные и частные каналы и даже запускать сторонние сервисы.
Приложение Bitcord занимает очень мало места. Размер его установочного пакета составляет чуть более 3 мегабайт (3.2 Мб. актуальный релиз). Оно не перегружено сложной графикой и не использует тяжёлые библиотеки или SDK. К примеру, реализованная в мессенджере видеосвязь, построенная по технологии WebRTC (P2P), задействует встроенные компоненты самой операционной системы, что позволяет сократить размер приложения на десятки мегабайт.
В PHP-экосистеме не так часто происходят заметные изменения в области машинного обучения. Пока основное внимание разработчиков сосредоточено на Python, PyTorch и больших языковых моделях, инструменты для ML на PHP продолжают развиваться, хотя и остаются нишевым направлением.
Поэтому выход Rubix ML 3.x – важное событие для PHP-разработчиков, которые хотят использовать машинное обучение в своих проектах. Это не просто очередная версия библиотеки: обновление затронуло производительность, обучение нейросетей, обработку данных и возможности параллельных вычислений.
Кроме того, у проекта появился официальный сайт с обзором возможностей библиотеки, документацией и примерами. Он помогает увидеть Rubix ML не как набор отдельных алгоритмов, а как полноценный инструментарий для всего цикла машинного обучения – от подготовки данных до применения обученной модели в production.
Разберём, что изменилось и почему это интересно разработчикам, которые работают с PHP каждый день.
Клиент написал: сайты лежат, похоже на DDoS. На сервере около 5 500 сайтов WordPress, nginx, PHP-FPM 8.4, MariaDB, 125 ГБ памяти, Debian 13. Я нашёл сканер, закрыл его в nginx, сайты поднялись. Через два дня клиент написал снова: всё падает каждые пять минут.
Причина оказалась не снаружи. Каждый новый воркер PHP-FPM с первого же запроса весил около 600 МБ, и OOM-killer по очереди убивал базу и nginx. Воркеры раздувал баг в OPcache, который срабатывает на каждом сбросе кеша под нагрузкой. Сбрасывал кеш Yoast SEO при обновлении. Причём не массовое обновление по всем сайтам, а догоняющее, на 467 сайтах, где плановое когда-то не прошло. Всё решил порядок двух команд.
13 октября 2026 года вышла Joomla 6.2. Традиционно мы обозреваем часть самых заметных нововведений релиза. В нём доработали редактор материалов, добавили авторизацию почты через OAuth 2.0, поле Joomla Form enum и обозначение обновлений безопасности расширений, language fallback...
Летом я сделал сайт, который собирает публичные Telegram‑каналы российских стримеров в одну ленту. Идея была простая: я подписан на десяток таких каналов и устал листать их по очереди, чтобы узнать, будет ли сегодня стрим.
Через три месяца у проекта 260 коммитов, 450 каналов, больше 60 тысяч постов в базе, около 4 тысяч страниц в поиске Яндекса и доход от рекламы — 1–2 рубля в день. Это честная ретроспектива: что сработало, на какие грабли я наступил и что показали данные про то, зачем люди на самом деле приходят на такой сайт. Спойлер: не за тем, для чего я его делал.
В 1969 году психиатр Элизабет Кюблер-Росс выпустила книгу «О смерти и умирании». В ней она описала, как человек переживает неизбежное: отрицание, гнев, торг, депрессия, принятие. Писала она о неизлечимо больных пациентах, но модель оказалась настолько универсальной, что её теперь примеряют на что угодно: от расставания до повышения ставки по ипотеке.
Сама Кюблер-Росс оговаривалась, что стадии не обязаны идти строго по порядку: их можно проскочить, к ним можно вернуться, на них можно застрять. Особенно застрять.
WordPress хоронят не первый год. Сначала казалось, что его вытеснят конструкторы сайтов, затем современные JavaScript-фреймворки, headless-подход и облачные платформы. Теперь к этому списку добавились нейросети: они уже умеют не только писать отдельные фрагменты кода, но и работать с проектом целиком – запускать WP-CLI, подключать плагины, готовить тесты и помогать с деплоем.
Что это меняет для WordPress в 2026 году? Стоит ли новому разработчику изучать его с нуля, если ИИ-агенты и вайб-кодинг берут на себя всё больше рутины? Где WordPress по-прежнему удобен, а где логичнее выбрать Laravel? И насколько сегодня нужны Elementor, Gutenberg, ACF и WooCommerce, если часть задач уже можно поставить обычной фразой?
Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Сокиркой – разработчиком, который пришел во фриланс еще школьником, начинал с баннера за пять долларов, затем работал с Joomla и WordPress, продавал шаблоны на маркетплейсах, сотрудничал с американскими студиями и сейчас активно экспериментирует с вайб-кодингом и ИИ-инструментами. У Александра также есть YouTube-канал: «Быть Программистом», где он публикует материалы о разработке и своем опыте.
В разговоре мы не ограничились WordPress. Обсудили Laravel, Copilot, Claude, Codex и Qwen, фриланс и зависимость от платформ, Elementor и Gutenberg, ACF и таксономии, Docker и CI/CD, WooCommerce и выгорание. Отдельно поговорили о том, что имеет смысл учить разработчику сегодня, где ИИ действительно экономит время, а где без понимания архитектуры и кода всё равно не обойтись.
Где в записи сессии оказываются чужие персональные данные, даже если пользователь ничего не вводил, почему маскировать их нужно ещё в браузере и какой режим маскирования безопаснее по умолчанию.
Привет! Я Паша, участвую в разработке сервиса записи сессий Broux. В этой статье я расскажу, как мы добиваемся соответствия продукта российским законам с точки зрения персональных данных, что в нашей нише не так уж просто. И я не юрист: юридическая часть ниже описывает, как мы это поняли. Проверяйте со своим юристом.
Первый вопрос, который задают про запись сессий: «а вы видите, что я ввожу в поле?». Честный ответ: технически скрипт записи видит всё, что видит браузер. Вопрос только в том, что он отправит на сервер.
Ниже о том, где обычно утекает лишнее, как с этим работать и при чём здесь 152-ФЗ.
В репозитории проекта лежит 146 YAML-файлов с контентом: персонажи, сюжеты, настройки моделей. На каждом деплое они импортируются в базу — прямо там же, где выполняются миграции схемы.
Механизм работает второй год и меня полностью устраивал. Потом я сел писать о нём статью, полез перечитывать собственный код импортёра и нашёл сценарий, при котором опечатка в одном файле удаляет сущность из базы. Не архивирует — удаляет, и деплой при этом остаётся зелёным.
Внутри: две ступени сравнения через хэш файла, версии контента, медиа вне репозитория, разбор самой ошибки по трём безобидным кускам кода и ещё пара находок — счётчики, которые всегда равны нулю, и экспортёры, прописанные в конфиге, но не существующие в коде.
Небольшая веб-студия в Тбилиси, множество встреч с клиентами и два года разработки сайтов — с 2016 по 2018 год.
Консьюмер очереди на PHP, который раньше раз в пять-шесть часов падал по OOMKilled. Сообщения при этом не терялись: Kubernetes поднимал под, и консьюмер дочитывал очередь, так что снаружи проблема была почти незаметна. Но регулярное падение по памяти — не норма, и мы решили докопаться до причины...
