Hacker News Digest

За последнюю неделю сразу несколько критических уязвимостей в программном обеспечении затронули тысячи крупных сайтов и вызвали панику. Главная из них — «PHP2Shell» (CVE-2026-109618 и CVE-2026-109619), две ошибки удалённого выполнения кода в PHP. Их независимо нашли команды из калифорнийской Calif (в рамках программы OpenAI «Patch the Planet») и израильско-американской Wiz (часть Google Cloud), причём обе использовали передовые ИИ-модели — GPT-5.6 Sol и Gemini 4 Argon — для поиска уязвимостей и создания эксплойтов. Одна из ошибок ещё в 2024 году всплыла при аудите PHP Foundation, финансируемом Sovereign Tech Agency, но её проигнорировали: никто не понимал, как превратить теоретическую проблему в реальный эксплойт.

Именно в этом ИИ особенно силён: получив даже смутное описание уязвимости, модель быстро строит рабочий эксплойт. Теперь любой анонс патча безопасности фактически означает, что полный эксплойт уже может распространяться — публично или приватно. PHP2Shell, по оценкам, затрагивает до 70% интернета: от Wikimedia Foundation и DeviantArt до значительной части госсайтов Великобритании, банковских систем Японии и сайта шоу The Traitors на BBC. Уязвимости находят и раньше, но обычно они не заставляют половину интернета останавливать серверы.

Обсуждение подтверждает, что LLM ускоряют поиск уязвимостей и создание эксплойтов, сокращая время между обнаружением багов и их эксплуатацией. Мнения о будущем разделились: часть участников (например, @thomascgalvin) считает это «новым кибернормалом», другие (@ozim) видят в этом переходный период, который завершится снижением числа уязвимостей за счет AI-проверки кода. Также возник спор о качестве кода: @wasabinator полагает, что LLM-генерация снизит безопасность, а @ChrisMarshallNY отмечает, что нейросети уже помогают находить баги в «идеальном» коде. Для защиты рекомендуют упрощать архитектуру, минимизировать поверхность атаки, ускорять выпуск патчей и внедрять автоматические инструменты (Dependabot, LLM-сканеры). Отдельно критикуются задержки в раскрытии уязвимостей (@shevy-java) — предлагается публиковать детали сразу. При этом проблемой остается медленное обновление ПО пользователями.

Исследователи Wiz обнаружили в ядре PHP критические уязвимости, позволяющие без аутентификации выполнять код на сервере и читать память процесса — там могут лежать пароли, токены, API-ключи и сертификаты других запросов. Проблемы затрагивают почти все версии PHP за последнее десятилетие, начиная с 5.4, а сам язык лежит в основе WordPress, Drupal, Joomla и MediaWiki, на котором работает «Википедия». Уязвимости получили общий рейтинг CVSS 9.2 и не зависят от кода приложения поверх PHP.

Корень проблем — архитектурные решения более чем десятилетней давности. Эксплуатация требовала исключительно сложной цепочки шагов и подстройки под раскладку памяти каждой цели, что было на грани человеческих возможностей. Пограничные ИИ-модели существенно снизили этот барьер: с их помощью рабочие эксплойты для разных приложений удавалось собирать за часы. В ходе работы подтвердили удалённое выполнение кода на Drupal и WordPress, а 21 октября 2026 года вышли патчи. Авторы сравнивают находку с Heartbleed и Log4Shell и предупреждают: сложность перестаёт быть надёжной защитой, но те же инструменты дают защитникам шанс находить и закрывать давние дыры.

Обсуждение дополняет статью деталями о раскрытии уязвимости, роли ИИ и влиянии на инфраструктуру, включая отключение государственных сайтов. Уязвимость оценивается как критическая (на уровне Log4Shell и EternalBlue), так как затрагивает ядро PHP и популярные CMS (WordPress, Drupal, Joomla). Технически проблема в том, что фатальные ошибки (преимущественно OOM) оставляют поврежденное состояние памяти, которое может быть переиспользовано следующим запросом в рамках одного воркера PHP-FPM. При этом @WJW отмечает, что Wiz и Calif не детально описали механизм перехода от Use-After-Free к полноценному RCE. Пользователи спорят о независимости открытия: @fwlr предполагает, что OpenAI могла воспроизвести баг из обучающих данных после работы Calif, а @ToValueFunfetti считает LLM недостаточно эффективными для обучения по одиночным примерам. В то же время @asbv-1qq советует использовать ИИ для аудита legacy-систем, так как он эффективно находит баги в коде старше 20 лет. Отмечена проблема «ответственного раскрытия»: между отчетом Wiz (24 августа) и подтверждением PHP Foundation (21 сентября) прошел месяц, а ранее произошли утечки в соцсетях. Для временного смягчения утечки памяти (memory disclosure) предлагается снизить параметр pm.max_requests для более частого перезапуска воркеров, однако это не поможет против type confusion в OPcache.

Нарушения эмбарго не было, так как OP не был проинформирован о его наличии. Эмбарго служит для координации раскрытия, а не для обеспечения секретности; если информация попала в цепочку без него, нарушение не засчитывается. При отсутствии данных об эмбарго не стоит раскрывать детали — лучше сообщить о проблеме ответственным лицам. Контактные лица должны передавать точную информацию, чтобы избежать недоразумений. Эффективность эмбарго сейчас оспаривается: некоторые считают его бесполезным, другие — важным. При этом AI ускоряет обнаружение и распространение уязвимостей, снижая эффективность таких ограничений.

Вокруг новой уязвимости в PHP раздули панику, но лёгкого эксплойта для неё не существует. Баг реальный и важный, однако он далеко не так прост в использовании, как Log4Shell, Heartbleed или декодирование YAML в Ruby on Rails. На GitHub уже тысячи «PoC», но ни один не работает против чистой установки PHP — автор призывает поднять сервер в Docker и запустить скрипт руками, а не через языковую модель: эксплойты просто не срабатывают.

Причина в том, что почти все поддельные «доказательства» опираются на локальное включение файлов (LFI) — по сути, требуют, чтобы сервер уже выполнял eval(read(файл_от_пользователя)). Это абсурдное предварительное условие: если для атаки нужна существующая уязвимость, позволяющая прочитать /etc/passwd, то баг не тянет на критический. Прошло уже больше десяти часов, на него смотрят полмира и сотни тысяч «сверхразумов», но рабочего эксплойта нет — в отличие от Log4Shell, где ботнеты появлялись мгновенно, ещё до эры ИИ.

Корень проблемы — слепая вера в LLM: люди, не понимающие цепочек use-after-free, уверены, что «Клод всё знает и сделает эксплойт». В итоге модель выдаёт младшему брату отключённый геймпад — на экране написано «эксплойт», есть убедительные логи, но сама модель заранее добавила серверу серьёзную уязвимость. Отсюда и странная одинаковость ошибок: ИИ стал главным «принимающим решения», порождая причудливые «точки Шеллинга» в решениях. Паника подогревалась заявлением члена команды PHP о «катастрофе», всеобщим недоверием к безопасности PHP, видео с аниме-девочкой и ощущением, что LLM нависают над интернетом. Но это не момент Log4J.

Вопреки заявлениям об отсутствии простых эксплойтов, специалисты Trail of Bits за несколько часов создали два рабочих варианта, протестировав их на чистой установке MediaWiki. PHP-Security подтвердил наличие use-after-free и краха воркера, продемонстрировав RCE через PHP-FPM и mod_php. При этом большинство публичных PoC требуют доработки и часто зависят от LFI. В сообществе возник спор: одни считают уязвимость одной из самых серьезных за последние годы из-за широкого охвата, другие сомневаются в этом из-за сложности реализации. Многие отмечают разрыв между технической реальностью и медийным ажиотажем, указывая, что паника раздута за счет AI-рекомендаций, а не детального анализа.

Вышли PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 с исправлениями двух критических уязвимостей, позволяющих неаутентифицированному атакующему выполнять код на сервере. Первая (CVE-2026-109618) — повреждение памяти при достижении memory_limit в неудачный момент: на Apache с mod_php запрос срабатывает ещё до кода приложения, и полный удалённый запуск кода подтверждён на настройках по умолчанию; на PHP-FPM — через код приложения. Вторая (CVE-2026-109619) — устаревшее состояние: фатальная ошибка оставляла внутренние указатели на память прошлого запроса, что давало use-after-free и запуск кода в реальном приложении на Apache с mod_php. Обе уязвимости лежат в управлении памятью и обработке ошибок — в частях, которые затрагивает почти каждый запрос, поэтому исправление грозило потерей совместимости, падением производительности или поломкой сторонних расширений.

Первый за годы внешний аудит 2024 года профинансировало Sovereign Tech Agency, организовал OSTIF, провёл Quarkslab. При исправлении его находок разработчик и заметил первые признаки проблемы с нехваткой памяти; в 2024-м эксплойт лишь теоретизировали. Команда безопасности перебирала конкурирующие подходы, решения принимались консенсусом, и работа месяцами то замирала, то возобновлялась — авторы прямо называют задержку структурным провалом из-за процесса принятия решений и нехватки ресурсов. Теперь решения принимаются большинством голосов, а компромиссы поощряются.

Главный дефицит — опытные инженеры, знающие всю кодовую базу PHP. Фонд PHP просит финансирования у компаний на PHP, хостингов, облаков и дистрибутивов, а также государств: пример — поддержка немецкого агентства, оплатившего аудит.

Обсуждение дополняет статью сведениями о роли AI (Anthropic, OpenAI, Qwen и др.) в автоматизации атак на основе новых CVE. Пользователи критикуют управление безопасностью в PHP: модель принятия решений на основе консенсуса привела к задержкам в исправлении проблем после аудита 2024 года. В ходе спора @jooops1 и @redox99 назвали PHP фундаментально небезопасным из-за использования C и призвали перейти на memory-safe языки (например, Rust), тогда как другие обсуждали лишь конкретные ошибки. @jongjong отметил, что малый объем кода (LOC) и минимум зависимостей ускоряют анализ и закрытие брешей. Также осуждена компания Chainguard за одностороннее нарушение эмбарго и публикацию исправленных образов до официального релиза. Из практических советов: @dofm рекомендует блокировать multipart-загрузки в Nginx как временную меру защиты от данной RCE. Отдельно отмечены задержки в обновлении зеркал Ubuntu у провайдера Hetzner, из-за чего пользователям пришлось применять патчи вручную.

Инициатива Patch the Planet позволила выявить критическую уязвимость в PHP — языке, на котором работает значительная часть сайтов и веб-приложений. Модель GPT‑5.6 Sol нашла изъян, а компания Wiz независимо обнаружила и сообщила об обеих уязвимостях. Исправления подготовили сопровождающие PHP при участии OpenAI, Wiz, Cloudflare и других партнёров, а также при содействии государственных киберведомств. По оценке авторов, это одна из самых значимых проблем безопасности за последнее время: она показывает, что ИИ способен находить уязвимости интернет-масштаба, но те же возможности помогают злоумышленникам быстро создавать эксплойты. Ключевой факт: передовые модели нашли эти дыры раньше атакующих, открыв «окно защитника» для подготовки исправлений до раскрытия.

Для организаций, использующих PHP, приоритет — установить обновления; для этого опубликован чекер версий PHP в виде навыка Codex. OpenAI обязалась выделить 1 млрд долларов на субсидируемый доступ Daybreak для организаций с ограниченными ресурсами, защищающих критически важные сервисы. Компания предупреждает, что подобных находок будет резко больше в ближайшие месяцы, и предлагает сообществу обсудить рамки реагирования: сроки раскрытия, экстренное патчирование, ранние уведомления и «безопасные по умолчанию» пакеты.

Участники обсуждения опровергают «магию» ИИ, считая инициативу OpenAI маркетинговым ходом для создания имиджа «спасителя» кибербезопасности. @nr378 утверждает, что успех зависел от глубоких знаний исследователя Calif о кодовой базе, тогда как @senordevnyc отмечает, что OpenAI лишь указали на использование модели. @OlivOnTech и @aprilnya критикуют «навык» проверки версии PHP, считая бесполезным запуск `php -V`, а @post-it добавляет, что команда `php --version` не всегда показывает версию реально запущенного интерпретатора. @lifeisloving отмечает деградацию навыков молодых инженеров: некоторые Senior-разработчики не знают базовых команд ОС (например, grep) из-за зависимости от LLM. В споре об этике open source @12837615 называет обучение моделей на открытом коде «кражей», а @fritzo и @orangedog считают, что код был отдан добровольно. Вместо раздачи токенов ИИ @12837615 предлагает инвестировать в QA open source проектов для обеспечения 100% покрытия тестами, использования ASAN и фаззеров. @ptmkenny и @sevenzero заметили, что официальные патчи коснулись только поддерживаемых версий (от 8.2), в то время как устаревшие ветки 7.x и 5.6 патчатся сторонними энтузиастами (например, Mr Sury).

Вышел PHP 8.2.35 — экстренный выпуск безопасности, закрывающий две критические уязвимости (CVE-2026-109618 и CVE-2026-109619), допускающие удалённое выполнение кода без аутентификации. Разработчики подчёркивают: полноценных способов обойти проблему нет, единственное надёжное решение — немедленное обновление. Все пользователи ветки 8.2 должны установить новую версию как можно скорее.

Отдельно напоминают: поддержка PHP 8.2 завершается 31 декабря 2026 года, после этой даты исправлений безопасности больше не будет — стоит заранее планировать переход на поддерживаемую версию. Исходники и сборки для Windows доступны на странице загрузок, полный список изменений — в ChangeLog.

Выпуск PHP 8.2.35 сопровождается обсуждением проблем с обновлением: официальные Docker-образы и пакеты Ubuntu LTS задерживаются, а крупные хостинг-провайдеры (например, WP-Engine) продолжают использовать уязвимые версии. В отличие от Ubuntu, Debian оперативно предоставил патчи для всех поддерживаемых веток. Уязвимость была раскрыта скоординированно Wiz, Calif и OpenAI. CISA выпустила официальное предупреждение о критичности проблемы. Подтвержденных атак пока нет, но обсуждаются потенциальные новые уязвимости, в том числе в PHP 8.5.12. Также возникли вопросы к эффективности предложенных ограничений памяти, так как они не блокируют multipart-запросы. Сообщество реагирует созданием альтернатив: Sury (ondrej) выпустил backport-пакеты, появились патч-Dockerfile для EOL-версий и CLI-утилита для аудита репозиториев. В качестве превентивных мер некоторые администраторы отключают сайты или используют Cloudflare. Дополнительно отмечены перебои в работе PECL, приводящие к ошибкам 504 при сборке расширений в Docker.

Команда безопасности PHP предупредила о предстоящем внеплановом выпуске, закрывающем две критические уязвимости — обе получили оценку CVSS v4.0 9.2, то есть максимально высокий уровень опасности. Релиз намечен на среду, 21 октября 2026 года, в 14:00 по UTC. Разработчики призывают всех пользователей PHP готовиться заранее, чтобы обновиться сразу после публикации патчей.

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

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

Уязвимости уже эксплуатируются, эксплойты опубликованы в Twitter, и многие крупные PHP-сайты могут быть скомпрометированы. Архитектурные особенности PHP-приложений (общий доступ к базе, загрузка файлов) увеличивают масштаб рисков. Администраторы отключают сайты или переводят их в режим обслуживания, следя за тем, чтобы серверы не запустились автоматически после перезагрузки. В качестве временных мер рекомендуют отключить session.upload_progress и запретить multipart-запросы через конфигурацию веб-сервера. Cloudflare и другие CDN внедряют правила WAF для блокировки векторов атаки. Ведется спор о сроках выпуска патча: одни считают, что ранний релиз уменьшит ущерб, другие — что он упростит создание эксплойтов и ускорит атаки.

Социальная сеть для разработчиков под названием /dev/null строится вокруг коммитов вместо постов: вход только через GitHub, а сообщения — это простой текст до 4000 символов. Лента работает без алгоритмов, строго по времени публикации, а профили полностью повторяют данные GitHub и редактируются там же. Первые коммиты проходят ручную модерацию, после чего автоматический модератор проверяет и одобряет их сам.

Тон площадки — шутливый и «свой»: в трендах шутки про Laravel, команды вроде php artisan make:friends и composer require followers, а также жалобы на внезапную нагрузку («нужно масштабировать сервер», «они деплоят прямо с телефона, помогите»). Упоминаются разработчики Нуну Мадуру и Николя Грекас, а число пользователей предлагают оценивать по счётчику подписок одного из участников. Есть и опрос о кроссплатформенной разработке с вариантами React Native, Flutter, SuperNative (NativePHP) и Kotlin Multiplatform. Всё остальное, по ироничному девизу проекта, уходит в /dev/null.

Сообщество разработчиков скептически относится к /dev/null. Обязательный вход через GitHub считается ограничением аудитории и связью с Microsoft, противоречащей идее независимой соцсети. Модерация постов (ручная проверка первых коммитов, затем автоматическая) вызывает опасения по поводу задержек и цензуры. Заявленные новшества воспринимаются как переупаковка существующих решений вроде Mastodon и Solid, без значимых отличий от других соцсетей для разработчиков. Технические проблемы: непонятный выбор домена (dev-null.sh), простои, отсутствие ясности о стеке технологий. Предложения: добавить публичный просмотр ленты и подробную информацию о платформе до регистрации, улучшить онбординг и визуальные метафоры (git‐аналогии, подсказки). Отмечается плюс: открытый исходный код и быстрый отклик сообщества — более 200 pull‐request'ов за 48 часов. Спор о будущем: некоторые видят в /dev/null потенциал для децентрализованного обмена файлами (сравнение с Solid), другие считают его обычным хостингом с альтернативами вроде tilde.town.

Уязвимость в WordPress позволяет неавторизованному атакующему выполнить произвольный код через путь обхода в функции get_page_template(). При определённых условиях атакующий может заставить систему включать локальный .php-файл за пределами активной темы, что при наличии уязвимого файла вроде pearcmd.php и включённой директивы register_argc_argv приводит к удалённому выполнению кода (RCE).

Для эксплуатации необходимо, чтобы активная тема (родительская или дочерняя) содержала каталог верхнего уровня, имя которого начинается с page- (например, page-templates). Это затрагивает темы Twenty Twelve, Twenty Fourteen и популярные сторонние темы вроде Neve, Hestia и Sydney. Кроме того, на сервере должен существовать читаемый веб-сервером .php-файл — например, pearcmd.php из PEAR, который при register_argc_argv=On позволяет достичь RCE. Уязвимы официальный Docker-образ PHP и стандартная конфигурация cPanel при использовании PHP ниже версии 8.5.

Проблема исправлена в WordPress 7.1.2, а также бэкендпортирована во все поддерживаемые ветки, начиная с версии 4.7. Уязвимость обнаружена и ответственно раскрыта Робертом Ressl.

WordPress остаётся одной из самых атакуемых платформ из-за популярности и унаследованной архитектурной хрупкости, а не только из-за отдельных уязвимостей. Многие переходят на статические генераторы (Hugo, Astro) ради безопасности и простоты, чтобы избежать постоянных обновлений, плагинов и сложности управления. Уязвимость, связанная с pearcmd.php и register_argc_argv, требует специфических условий, но они часто встречаются на старых установках, особенно на общих хостингах. Directory traversal в WordPress известен давно — предупреждали ещё 9 лет назад в официальной документации, что указывает на системное игнорирование безопасности в экосистеме. Несмотря на критику, WordPress используется на ключевых сайтах (например, whitehouse.gov), что подчёркивает его устойчивость в бизнес-среде. Для старых установок можно временно отключить register_argc_argv в php.ini, чтобы нейтрализовать условную RCE-уязвимость. Если не обновляете WordPress, необходимы строгие WAF-правила, особенно при использовании сторонних плагинов. Многие пользователи, перешедшие на статические сайты, используют PHP только для простых задач (выбор языка, устройства), что повышает безопасность и скорость. Споры: CVSS-баллы для уязвимости могут быть преувеличены из-за специфических условий и ограниченного охвата установок. Успех WordPress объясняется не качеством кода, а ранним доступом и простотой для непрограммистов — аналогично Bitcoin в криптовалютах. Плагины — основной вектор атак из-за непрозрачности, отсутствия аудита и устаревания. Даже обновлённые ядра остаются уязвимыми из-за плагинов. Автоматизированные скрипты сканируют wp-* пути — стандартная практика, подтверждаемая логами nginx (бомбы, 403-ответы). Разработчики отмечают: документация неполная, функции не типизированы, код — спагетти, что делает разработку плагинов ненадёжной. WordPress сравнивают с жеваной жвачкой на улице: работает, но использование — компромисс между удобством и постоянным риском. С ростом AI-инструментов, сканирующих весь код, количество выявленных уязвимостей в популярных системах может резко вырасти, так как AI обнаруживает то, что люди игнорируют.

Двенадцать лет назад я написал 174-строчный PHP-полифил для функции http_build_url() как временное решение при переходе CMS AOL с PHP 5.2 на 5.3, когда расширение pecl_http было удалено. Опубликовав его на Packagist, не ожидал широкого распространения — но за годы он набрал почти 20 миллионов установок, включая более 400 тысяч в месяц, и стал частью зависимостей таких проектов, как WPML (используется на 1,5 млн сайтов WordPress), idna-convert и дистрибутивов Debian и Ubuntu.

В процессе использования выявились серьёзные баги, например, удаление всех букв «а» из пути при добавлении слеша в URL из-за некорректного обходного решения с добавлением и удалением символа. Несмотря на предложения новых мейнтейнеров и форков, я решил объявить пакет устаревшим: современные альтернативы вроде URI-библиотеки PHP League и встроенного стандартосоответствующего API в PHP 8.5 превосходят его по надёжности и безопасности. Поддержка устаревшего кода рискует создать уязвимости, особенно при передаче мейнтейнерства непроверенным лицам. Пакет останется доступным, но без исправлений — включая упомянутый баг — чтобы не вводить непредвиденных изменений в зависимости миллионов сайтов. Это был добросовестный временный патч, но время двигаться дальше. P.S. Сам AOL CMS так и не мигрировал с него — использовал до закрытия платформы около 2020 года.

Баг с удалением всех букв 'a' из пути при наличии завершающего слеша в URL известен и обсуждается. Автор признаёт необходимость депреката из‐за багов и наличия альтернативных решений в сообществе. Layer8 отмечает, что без багов пакет остался бы без изменений из‐за широкого распространения. Dolmen предлагает использовать ИИ для генерации исправлений, снижая нагрузку на поддерживающих. Swiftcoder описывает баг: при завершающем слеше в URL удаляются все 'a' из пути. TimWolla сообщает, что пакет помечен как «abandoned» на Packagist без предложенной замены. Jamietanna отмечает, что депрекат будет виден в инструментах и статическом анализе, помогая разработчикам. Edg5000 указывает, что баг остался незамеченным, возможно, нарушив работу множества сайтов. Dspillett уточняет, что баг проявляется только при наличии завершающего слеша. Hk__2 приводит GitHub‐issue, подтверждающий поведение: при соединении пути к URL с завершающим слешем удаляются все 'a'. Staplung цитирует закон Хайрума, подразумевая, что баг может использоваться для удаления 'a'. KellyCriterion выражает обеспокоенность рисками безопасности от устаревших расширений и фиксов.

Борьба с «инновационными токенами» — ключ к устойчивому росту. Каждый проект получает всего три шанса на радикальные технологические эксперименты; их расходование на эксперименты вроде NodeJS, MongoDB или новейших сервисов обнаружения приводит к риску провала. Вместо этого выбирайте «скучные», но проверенные решения — MySQL, Postgres, PHP, Python, Memcached. Их известные слабые места позволяют заранее спланировать отказоустойчивость, в отличие от новых технологий, где неизвестные неизвестные часто оказываются катастрофическими.

Оптимизация должна быть глобальной: фокус на долгосрочной стабильности, а не на блеске. В Etsy, используя «скучный стек», команда масштабировала активности в 20 раз без вмешательства, пока не отвлеклась на новые решения. Это подтверждает, что сознательный отказ от избыточной инновации ускоряет успех, а не замедляет его.

Тред критикует концепцию «инновационных токенов» как излишне упрощённую, подчёркивая, что выбор технологий должен основываться на конкретных потребностях проекта, а не на новизне. @NickNaraghi считает её полезной для принятия решений, но @insanitybit, @threethirtytwo и @euthymiclabs возражают: новизна не заменяет надёжность и стабильность. @gaigalas предлагает компромисс — 80% «скучных», 20% инновационных технологий, чтобы избежать конфликтов.

Архив представляет собой единственное собрание публичных PoC‑эксплойтов и обзоров уязвимостей, которые на момент публикации ещё не получили официального CVE. Автор разместил их в открытом доступе, призывая сообщество самостоятельно сообщать о найденных уязвимостях и забирать кредит за присвоенный номер, если он будет выдан. При этом он подчёркивает, что такие материалы предназначены лишь для привлечения людей в область кибербезопасности, а не для реального злоупотребления. Он также шутит, что можно «взять лулз», сообщая о уязвимостях и получая CVE, но настоятельно просит не злоупотреблять этим ресурсом.

Автор заявляет, что такие материалы следует использовать только в образовательных и исследовательских целях, а не для создания атак или распространения вредоносного кода. Он считает, что открытый набор PoC‑ов — самый эффективный способ заинтересовать начинающих специалистов, заставить их практиковаться с реальными примерами и ускорить развитие компетенций в области уязвимостей. При этом он подчёркивает, что злоупотребление архивом может привести к блокировке доступа к ресурсам, потере репутации и юридическим последствиям. Таким образом, репозиторий служит не столько как хранилище эксплойтов, сколько как стимул для ответственного исследования, способствующий формированию более безопасного программного обеспечения.

• Большинство упомянутых уязвимостей – лишь типичные баги или уже исправленные CVE, а термин «0‑day» здесь сильно размыт.
• Некоторые находки действительно интересные (например, уязвимости в c‑ares, nginx, PHP), но их эксплуатация часто требует предварительных условий.
• Большая часть репозитория содержит PoC‑ы, сгенерированные LLM, и их публичное распространение служит скорее образовательной цели, чем реальной угрозой.
• Автор предупреждает о недобросовестном использовании материалов и подчёркивает, что многие «эксплойты» – лишь учебные примеры, а не готовые атаки.

Perl не мёртв, его популярность находится на уровне периода dotcom пузыря, согласно отчёту CPAN 2023. Новичков среди пользователей Perl становится всё меньше с 2011 года, хотя общее использование языка остаётся стабильным. Raku (бывший Perl 6) не стал причиной упадка, так как Perl продолжал расти даже во время разработки Raku.

Основные гипотезы упадка Perl связаны с изменением поколений программистов и развитием инструментов разработки. Программисты, выросшие на Unix-системах, естественно воспринимали Perl как продолжение shell, C, awk и sed. Новое поколение, воспитанное на Microsoft, Visual Basic и Java, предпочло Python. Кроме того, появление мощных менеджеров пакетов сделало доступными множество альтернатив, в то время как раньше Perl был одним из немногих доступных инструментов.

• Perl умер не из-за Raku, а из-за отсутствия единого пути развития, отсутствия стандарта кодстайла и культуры «один-разовых» скриптов.
• Python и PHP выиграли, потому что они были «дружелюбнее» для новичков и имели лучшую документацию.
• CPAN стал менее удобным, чем PyPI и npm, что сделало Perl менее привлекательным.
• Отсутствие единого фреймворка для веб-разработки и отсутствие стандарта ООП в Perl 5.
• Не было единого сообщества, которое могло бы продвигать Perl, в то время как Python и JavaScript имели Google и Facebook.

Инженеры часто иррационально подходят к выбору языков программирования, принимая решения на основе идентичности, эмоций и эго, а не технических преимуществ. Автор делится историей о компании Takkle, где опытный CTO инициировал переход с PHP на Perl, что привело к девятимесячной задержке, увеличению расходов с $200K до $500K в месяц и, в конечном итоге, к банкротству компании. Несмотря на то, что PHP был «достаточно хорош» для Facebook, подобного решения не приняли.

В течение своей карьеры автор наблюдал повторяющуюся эту модель в Google, MongoDB и других компаниях. Он описывает случай, когда VP Engineering представил руководству обоснование выбора Rust, хотя Go объективно соответствовал заявленным критериям лучше. Оказалось, что другие языки даже не рассматривались — решение было основано на хайпе. Автор подчеркивает, что при обсуждении языков программирования всегда происходит два диалога: видимый технический и невидимый, связанный с идентичностью инженера.

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

Эндрю Шмеляун создал систему, позволяющую незнакомцам отправлять ему сообщения через чековый принтер. Он вдохновился другом, у которого на сайте была похожая функция, но хотел сделать её более физической. Эндрю использовал старый термопринтер Epson TM-T88IV, купленный на eBay за $50, который работает за счёт нагрева специальной бумаги, покрытой термочувствительным веществом. Поскольку принтер не распознаётся его Mac Mini, он подключил его к Raspberry Pi 4.

Для реализации проекта Эндрю выбрал PHP с фреймворком Laravel, создав сайт с простой формой без JavaScript. Система сохраняет сообщения в базу данных на случай, если принтер выйдет из строя или закончится бумага. Принтер имеет ограниченный набор символов (только стандартный алфавит, цифры и базовые знаки клавиатуры), поэтому сообщения проходят валидацию на предмет специальных символов. Ширина текстового поля соответствует ширине печати (42 символа).

• Пользователи делятся опытом с дешёвыми китайскими термопринтерами, драйверы и библиотеки для них, а также вспоминают проект Little Printer и другие попытки сделать «интернет-подключённые» термопринтеры.
• Обсуждаются вопросы безопасности при работе с термобумагой, влияние BPA и аналогичных пластификаторов, а также трудности с поставками безопасной бумаги.
• Участники делятся личным опытом: кто-то использует принтер как «интернет-факс», кто-то печатает стикеры из чека, кто-то пытается повторить Little Printer.
• Поднимается вопрос о том, что такие проекты могут быть использованы для печати зинов и других офлайн-контента.
• Также обсуждается, что при должном подходе можно было бы сделать такие проекты более доступными и устойчивыми к спаму и злоупотреблениям.

MAML — это минималистичный формат для данных, который сохраняет читаемость для человека и при этом остаётся простым для машинной обработки. Он сочетает лучшее из JSON, дополняя его комментариями, многострочными строками и необязательными запятыми и кавычками.

MAML уже реализован в нескольких языках, включая JavaScript, Python, Rust, C и PHP. Эти реализации находятся на разных стадиях разработки: от готовых к использованию до находящихся в активной разработке.

Проект полностью открыт, с кодом на GitHub, и распространяется по лицензии MIT, что позволяет свободно использовать, модифицировать и распространять его.

• Обсуждение вновь подтвердило, что вместо улучшения JSON/YAML/TOML появляется всё больше новых конфиг-языков, но никто не решает их проблемы с синтаксисом, датами, комментариями и т.д.
• Участники обсуждения отмечают, что большинство этих новых языков не решают фундаментальные проблемы, такие как отсутствие типов данных, дат и комментариев в JSON.
• Некоторые комментаторы подчеркивают, что вместо того, чтобы изобретать новые языки, лучше бы улучшить существующие инструменты, такие как JSON5 или TOML.
• Другие участники поднимают вопрос, что если бы разработчики потратили усилия на улучшение существующих инструментов, вместо создания новых, это было бы более продуктивно.

Репозиторий Evidlo/xsl-website
Публичный пример генерации сайта средствами XSLT: XML-документ преобразуется в полноценную HTML-страницу без серверной логики.

Ключевые файлы

• index.xml – исходные данные
• index.xsl – таблица стилей
• README.md – краткое руководство

Запуск

1. Откройте index.xml в браузере или
2. Примените XSLT-процессор: xsltproc index.xsl index.xml > index.html

Репозиторий демонстрирует, как обойтись без движков шаблонов, используя лишь стандартные XML-технологии.

• Обсуждение началось с демонстрации, как SGML/XML-entity можно использовать для «без-JS» сборки страниц, но напомнили, что браузеры никогда не реализовали полноценный SGML-парсер.
• Участники сравнили XSLT и CSS: CSS может вставлять контент, но лишь декоративно, тогда как XSLT позволяет полноценные преобразования, однако Google просит удалить XSLT из стандарта и уже прячет его за флагом в Chrome.
• Всплыли воспоминания о 2000-х, когда XML/XSLT активно применялись для документации, e-learning и CMS (Symphony), но сложность и отсутствие поддержки со стороны браузеров постепенно вытеснили технологию.
• Предложили альтернативы: серверная трансформация (PHP, CI/CD) или полный отказ в пользу современных сборщиков и SSR-фреймворков.