PHP *

В нашей небольшой веб-студии решили попробовать передать AI-агентам часть рутинной работы с сайтами. Работаем мы в основном с MODX 2 и 3, поэтому мне поручили подобрать подходящий MCP-компонент. Задача выглядела несложной: посмотреть существующие решения, сравнить возможности и выбрать, что лучше подойдет.

Сначала я так и собирался сделать. Но потом полез в исходники и наткнулся на одну интересную вещь. В одном из компонентов был совершенно обычный PHP-цикл, который обновлял дополнительные поля страницы. Я решил проверить, что произойдет, если при сохранении возникнет ошибка. Первое поле записалось, второе нет, а обработчик завершил работу как ни в чем не бывало.

Вернулся к коду. Оказалось, результат setTVValue() просто никто не проверяет. Если агент получит сообщение об успешном выполнении команды, он будет считать, что все готово. Хотя на сайте могла сохраниться только половина изменений.

Есть в инфобезе сценарий, который повторяется с завидным постоянством. Инцидент вроде бы закрыли, отчитались, выдохнули — а через пару недель выясняется, что атакующий никуда не уходил. Он просто переждал. Именно так и произошло здесь, и именно поэтому эта история стоит того, чтобы её разобрать не по верхам, а по-настоящему.

Два сайта — appeal и new портал на 1С-Битрикс — несли один и тот же веб-шелл WebShellOrb (WSO). В первый раз инцидент обнаружили по логам Nginx, а вот дальше началось самое неприятное. Через некоторое время злоумышленник снова был внутри. Инцидент растянулся почти на три месяца, и повторная компрометация случилась уже после того, как были приняты меры.

И вот тут очень легко ошибиться в выводах. Соблазнительно сказать: «ну, значит, меры сделали плохо». Но это было бы неправдой. Дальше — почему меры не сработали и что оказалось «под капотом».

Во второй половине октября две критические уязвимости в PHP и GitLab заставили компании по всему миру срочно обновлять серверы, а часть государственных и коммерческих сайтов на время ушла в офлайн. Обе позволяют выполнить код на сервере без авторизации, и обе затрагивают версии, выпущенные больше десяти лет назад.

Почему так произошло и что делать прямо сейчас — рассказываем в статье.

Страница со списком из 100 постов на проде тормозит, а в профайлере — сотня одинаковых лёгких запросов. Это N+1: разбираем, как Eloquent создаёт его через ленивую загрузку, как лечить через with() и withCount() и как запретить на уровне фреймворка через preventLazyLoading().

А что если… нужен старый софт, но при этом хост Linux свежий?

Как вариант, можно взять, да хоть на примере питона, нужный официальный образ в докере. Да и пользоваться.

Казалось бы, проблема решена. Но есть нюанс (с). Добро пожаловать под кат.

Когда в Laravel нужно обработать большую таблицу, обычно советуют «не делать all(), использовать chunk()». Совет верный, но неполный: у chunk() есть ловушка, из-за которой фоновая задача тихо обрабатывает только часть строк. Ниже замеры пяти способов обхода таблицы на 100 000 строк, разбор потери строк и правила выбора метода.

Про N+1 в Laravel обычно пишут три строки про with() и расходятся. Я собрал небольшой стенд на Laravel 13 и SQLite, воспроизвёл проблему, посчитал запросы для каждого способа лечения и проверил, что «не ловится» режимом запрета ленивой загрузки. Отдельно разобрал места, где eager loading не помогает или сам создаёт нагрузку. Все числа в статье получены на этом стенде на искусственных данных.

Я работаю в авиации, езжу на вахты, у меня ипотека и семья — и по вечерам после смены пишу платформу для тренировок в CS2. Внутри: Go-парсер, который разбирает демку на 350 МБ за 4 секунды, ИИ-разбор, где факты считает код, а модель только объясняет, тактическая доска на Reverb и пачка граблей Laravel, которые стоили мне вечеров.

Вы опубликовали статью. Счётчик показывает пару тысяч просмотров. Но кто-нибудь её на самом деле прочитал? Обычная аналитика на этот вопрос не отвечает: человек, закрывший вкладку через три секунды, и человек, дочитавший до последней строки, для счётчика одинаковы — «1».

Хуже того, ответа не даёт и «средняя глубина прокрутки», которая есть почти в каждом сервисе веб-аналитики. О том, почему она врёт и как я решал обе задачи в бесплатном плагине AnGo Scroll Analytics для WordPress, — эта статья. Внутри: процентили вместо среднего, трекер на чистом JavaScript, отправка данных через sendBeacon, upsert с GREATEST() и принцип «клиент враждебен».

21 октября вышли патчи против PHP2Shell — двух критических уязвимостей в PHP с удаленным выполнением кода без авторизации. Как обновиться, уже написали многие. Мы разбираем, что сделать после обновления, чтобы утечка через уязвимость не обошлась компании в штраф до 15 млн рублей: какие доказательства сохранить, когда звать юриста и почему отсчет 24 часов на уведомление Роскомнадзора может начаться раньше, чем вы думаете.

У нас есть production S3-хранилище, которое годами переживало разные поколения сервисов, интеграций и команд. В какой-то момент в нем накопилось больше 65 ТБ данных и десятки миллионов объектов, а стоимость хранения превысила 150 тыс. рублей в месяц.

В статье я расскажу, как мы восстановили карту хранилища, организовали миграцию без остановки сервиса и сократили объем данных примерно с 65 до 45 ТБ.

У нас небольшой сайт на WordPress в финансовой нише, SEO делаем своими руками. Позиции раньше снимал платный сервис, частотность я смотрел в браузерном Вордстате, по одной фразе. В октябре перевёл и то и другое на Search API Яндекс Облака. Получилась горстка PHP-скриптов, которые запускаются через wp eval-file на том же сервере, где живёт сайт.

Дальше будет схема, упрощённый код и грабли. Код обезличен: ни ключей, ни путей, ни идентификаторов облака. Поля API у Яндекса меняются, так что перед копированием сверьтесь с документацией.

Мы делаем «Сбор - спортивные школы» — платформу для детских футбольных школ: расписание, посещаемость, взносы и матч-день в одном приложении для тренера, родителя и директора. На сервере Laravel 12, Livewire 3 и PostgreSQL, мобильное приложение написано на Flutter. Предметная область выглядит простой — календарь и список детей, — но почти каждая задача упирается в людей: родителей у ребёнка двое, детей у родителя трое, а тренер стоит на поле с телефоном в одной руке и мячом в другой. Ниже — пять болей, которые мы услышали от тренеров и родителей, решения, которые из них выросли, и куски настоящего кода.

На этой неделе нашли дыру в PHP — языке, на котором работает больше половины сайтов. Через неё чужой человек может запустить на сервере свою программу, и для этого ему не нужен ни пароль, ни доступ к сайту. 21 октября вышли исправления. Прошло четыре дня — а что с рунетом-то? Мы посмотрели на 10 000 самых заметных сайтов и попробовали понять, сколько из них уже обновились.

Короткий ответ: понять не получается. И это само по себе интересно.

Вечером 21 октября 2026 года мой телефон разорвался от звонков. В рабочем чате, где обычно обсуждают котов и сроки сдачи макетов, висел одинокий, но очень жирный алерт от моего сканера безопасности. Который гласил, что нам всем конец.

Две критические уязвимости в PHP, раскрытые утром этого злополучного дня. Точных деталей в паблике еще небыло. Говорилось, что вендор уже выкатил фикс в 8.5.12, а все, что ниже — официально в красной зоне. Такая информация была на момент осознания масштаба проблемы.

У меня на поддержке около сотни сайтов. Разброс по серверам — от убитого shared-хостинга, где админ спит еще с нулевых, до пары десятков VPS. Версии PHP — от гордого 8.3 на свежих проектах до музейных экспонатов.

Первая мысль была рациональной: «Завтра с утра спокойно пропишем обновление в CI/CD, прогоняем тесты, выкатываем». Вторая мысль, более честная, пришла через секунду: «если дыры опубликовали сегодня, эксплойты появятся в паблике завтра к обеду». Спать я в ту ночь лег в 04:30.

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) и какие временные меры допустимы, если обновиться сразу нельзя.