Пятого октября 2026 года Atlassian опубликовала бюллетень безопасности и заплатки сразу для восьми продуктов линейки Data Center — Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible и Fisheye. Уязвимость CVE-2026-21589, оценка 9,3 из 10: чтение файлов приложения без всякой авторизации.
Шестого октября исследователи watchTowr опубликовали технический разбор — как именно работает обход. Через два часа серверы-приманки компании Previdian зафиксировали первые попытки эксплуатации: пятнадцать обращений с трёх адресов в Японии и США. Следом появился шаблон для сканера Nuclei — и массовая автоматическая проверка всего интернета на эту дыру стала делом одной команды в терминале.
Два часа — это и есть тема статьи. Не «в Atlassian нашли уязвимость», а сколько времени есть у владельца сайта между появлением заплатки и началом атак — и что из этого следует при выборе движка.
Это не история про Atlassian
Можно возразить, что Jira и Confluence — корпоративные системы, а у обычного сайта всё спокойнее. Вот то же самое на WordPress, который стоит у каждого второго.
22 сентября 2026 года вышел WordPress 7.1.2 и закрыл CVE-2026-87902 — 9,2 из 10, неавторизованный обход каталогов, который в определённой конфигурации доводится до выполнения кода. Затронуты все версии начиная с 4.7.0, то есть практически все живые сайты.
Что было дальше, Patchstack разобрала по своему трафику:
- 22 сентября, 11:49 UTC — первая попытка проверить уязвимость. В день выхода заплатки.
- 22 сентября, 15:34 UTC — первая попытка записать файл на диск.
- 23 сентября — атака разошлась на несколько сотен адресов, а объём трафика превысил вечер первого дня более чем в десять раз.
Инструменты даже не скрывались: в журналах остались user-agent'ы cve-2026-87902-poc/1.0 и nuclei-cve-2026-87902/1.0. Сайты перебирал не человек, а чей-то скрипт, запущенный по списку.
Почему заплатка работает против владельца
Механика в обоих случаях одна и та же и от системы не зависит.
Публикация исправления — это одновременно публикация информации о том, где была ошибка. Открытый проект выкладывает исходный код правки, закрытый — бюллетень с перечнем затронутых версий. Любого из этого достаточно, чтобы понять, куда смотреть. Дальше остаётся вопрос техники, и на него уходят часы, а не недели.
И тут вступает асимметрия, которая делает ситуацию неравной. Атакующему нужно написать проверку один раз. Один шаблон Nuclei применяется ко всему интернету, стоимость одной попытки — доли копейки. Владельцу нужно обновить свой сайт руками, по одному. Масштаб, который при этом покрывается: watchTowr приводит поиск, по которому одних только экземпляров Confluence в интернете чуть меньше семисот тысяч, а общий счёт затронутых установок относит к шести- и семизначному порядку. Это оценка по поисковику, и она завышена — один экземпляр может отдаваться по нескольким адресам, — но порядок величины показывает верно.
Сколько времени есть на самом деле
Единичные случаи впечатляют, но считать по ним нельзя. Многолетние измерения делает Mandiant (сейчас часть Google): компания считает среднее время от выхода заплатки до первой зафиксированной эксплуатации.
| Период | Среднее время до эксплуатации |
|---|---|
| 2018–2019 | 63 дня |
| 2020 — начало 2021 | 44 дня |
| 2021–2022 | 32 дня |
| 2023 | 5 дней |
| 2025 (оценка) | −7 дней |
Последняя строка не опечатка. Минус семь означает, что в среднем эксплуатация начиналась раньше, чем выходила заплатка.
А теперь оговорки, без которых этой таблицей пользоваться нельзя:
- Это средние значения, а не медианы, хотя цитируют их обычно как медианы.
- Пятёрка за 2023 год получена после удаления пятнадцати выбросов. На тех же данных без этой обработки среднее — 47 дней. Два числа из одного набора, и оба опубликованы в одном отчёте.
- Оценка «минус семь» за 2025 год помечена самим отчётом как оценочная, подробной методики в публичной части нет.
- Время отсчитывается от выхода заплатки, а не от публичного раскрытия. Это разные точки отсчёта, и путать их нельзя.
Второе независимое измерение — у VulnCheck, по тем уязвимостям, про которые известно, что их эксплуатируют. Доля тех, эксплуатацию которых зафиксировали не позже дня публикации записи CVE:
| Период | Эксплуатация не позже дня публикации |
|---|---|
| 2024 год | 23,6% |
| 2025 год | 29,0% (254 из 884) |
| первая половина 2026 года | 23,4% |
И здесь надо сказать то, что не укладывается в красивую линию: в 2026 году эта доля снизилась. Тезис «каждый год всё быстрее» свежими данными не подтверждается. Что действительно ускорилось — срок, за который уязвимость попадает в каталог заведомо эксплуатируемых: медиана упала с 120 дней до 80.
И отдельно — самый цитируемый эпизод в этой теме. 4 марта 2024 года Cloudflare зафиксировала попытки эксплуатации уязвимости в JetBrains TeamCity через 22 минуты после публикации демонстрационного кода. Его приводят как общую цифру, хотя это один замер, а не распределение, — сама Cloudflare так его и подаёт.
И сколько времени тратит владелец
Вторая половина сравнения — скорость защищающейся стороны. Её меряет Verizon в ежегодном отчёте о расследованиях утечек; последний охватывает период с ноября 2024 по октябрь 2025 года.
- 43 дня — медианное время полного устранения уязвимости. Годом раньше было 32: стало не быстрее, а медленнее.
- 26% — доля уязвимостей из каталога заведомо эксплуатируемых, которые закрыли полностью. Годом раньше — 38%.
- 35% уязвимых экземпляров остаются открытыми на 28-й день.
У Edgescan средний срок устранения критичных уязвимостей в приложениях и API — 54,8 дня.
Складываем: у атакующего часы, у владельца недели. И это данные по организациям, у которых есть служба информационной безопасности и регламенты. У сайта кафе нет ни того, ни другого.
Публичный код — это ещё не атака
Из всего сказанного легко сделать неверный вывод: каждая новая запись CVE означает, что вас уже ломают. Цифры говорят другое.
По данным VulnCheck, за 2025 год публичный код эксплойта существовал для 10 480 уязвимостей из 40 085 — это 26%. А эксплуатацию в природе наблюдали примерно у 422, то есть у одного процента. Разница в двадцать с лишним раз.
И второе: больше трети уязвимостей, которые реально эксплуатируют, старше года, а по замерам GreyNoise за 2024 год 40% были старше четырёх лет. Главная опасность — не свежая дыра, про которую пишут все, а старая, которую не закрыли и забыли.
Вывод из этого спокойный. Паниковать по каждой публикации не нужно. Нужно, чтобы очередь на обновление вообще существовала и разбиралась, — потому что она не кончается никогда.
Сколько раз за год пришлось бы обновляться
Это наш собственный подсчёт по тем системам, которые мы разбирали в этой серии. Период — с 1 января по 10 октября 2026 года, 283 дня, то есть не полный год. За одно срочное обновление считается одно событие: выход исправлений безопасности, даже если он разошёлся сразу по нескольким ветвям и нескольким номерам версий.
| Система | Срочных обновлений | Закрыто уязвимостей |
|---|---|---|
| Tilda и конструкторы | 0 | — |
| 1С-Битрикс | 2 | 2 |
| OpenCart | 2 | 5 |
| Laravel | 3 | 3 |
| Joomla | 6 | 66 |
| Django | 8 | 32 |
| WordPress | 8 | 44 |
| Astro | 9 | 27 |
Расширения в таблицу не входят и считаются отдельно, потому что у них свои вендоры и своё расписание. В экосистеме Laravel за период вышло ещё одно предупреждение у Livewire и пятнадцать у Filament. У 1С-Битрикс модули Маркетплейса попадают в банк данных угроз наравне с ядром. У WordPress это отдельный поток: 5231 запись CVE с упоминанием WordPress за девять с половиной месяцев, из них 358 критических и 1376 высокого уровня — подавляющее большинство относится к плагинам. У конструктора расширений в этом смысле нет вовсе: обновлять владельцу нечего.
Теперь то, без чего эту таблицу нельзя читать. Эти числа не ранжируют системы по безопасности. Причин три.
- Больше находят там, где больше ищут. WordPress — самая исследуемая система в мире: на нём целиком работают несколько компаний, есть премии за находки, есть постоянный поток отчётов. Пять тысяч записей за девять месяцев — это показатель внимания не меньше, чем показатель качества кода.
- Маленькое число иногда означает обратное. У OpenCart за период вышло два релиза, оба 11 августа, и после них две известные уязвимости актуальной версии к 10 октября так и остались незакрытыми. Это не «спокойнее», это «чинить некому».
- Бюллетень — не всегда срочное обновление для вас. Из 27 предупреждений Astro большинство касается серверного режима и адаптеров. Если вы собираете статический сайт без сервера, к вам почти ничего из этого не относится.
А самое интересное в этих данных — не числа, а два факта.
10 и 11 марта WordPress выпустил три релиза за два дня. Первый вызвал у части сайтов белый экран, а в следующем выяснилось, что исправления безопасности применились не полностью. Обновиться вовремя оказалось недостаточно — надо было обновиться трижды и всё это время следить за новостями проекта.
17 июля в WordPress включили принудительные автоматические обновления. Это решение самого проекта, и оно честное признание: окно между заплаткой и атакой стало короче, чем время реакции человека. Ждать, пока владелец сайта прочитает бюллетень, в проекте решили больше не пытаться.
Где управляемая платформа честно выигрывает
В этой истории есть сторона, которой не нужно было делать ничего. Пользователи облачной версии Atlassian: вендор закрыл уязвимость у себя, признаков эксплуатации в облаке не нашёл, от клиентов не потребовалось никаких действий. У владельца сайта на Tilda в нашей таблице стоит ноль, и это правда — обновлять ему нечего, доступа к коду и серверу у него нет.
Поэтому вывод, который стоит сказать прямо: если нет человека, который в течение суток прочитает бюллетень и поставит обновление, конструктор или облако надёжнее самостоятельного сайта на CMS. Это не компромисс, а правильный выбор для такой ситуации. Худший вариант из всех — своя копия WordPress, которую никто не обновляет.
Цена у этого выбора тоже есть, и она не в деньгах, она в зависимости. Сторонний вендор может решить прекратить работу в стране, его может заблокировать РКН и вы никак не можете на это повлиять. Все, что у вас "в облаке" по факту вам не принадлежит и вами не управляется. Что же касается безопасности - у Tilda есть страница безопасности и программа вознаграждений за найденные уязвимости — это больше, чем публикуют многие. Но публичной истории инцидентов у неё нет. Ноль обновлений для владельца не означает ноль риска: он означает, что риск стал непрозрачным и вам неподконтрольным. Вы узнаете о проблеме, если о ней решат рассказать.
Что это значит для сайта без зависимостей
Теперь про наш подход — и сразу о том, чего он не делает.
Он не обнуляет обслуживание. Под нашим сайтом всё равно есть операционная система, веб-сервер и PHP, и у них свои уязвимости. В мае 2026 вышла серьёзная уязвимость nginx — CVE-2026-42945, 9,2 из 10, с публичным эксплойтом; 1С-Битрикс тогда выпустил для своей виртуальной машины отдельную сборку веб-сервера и советовал обновиться «в ближайшие часы». Эту очередь не обходит никто, кто держит собственный сервер, включая нас.
Что он меняет — длину очереди. У нас в ней операционная система, веб-сервер и PHP. У сайта на CMS — то же самое плюс ядро движка, плюс тема, плюс каждое расширение, и каждое со своим расписанием и своим вендором.
И главное — атака на такой сайт не масштабируется. У кода, написанного для одного сайта, нет записи в CVE, нет шаблона Nuclei и нет списка затронутых версий. Ошибку в нём надо искать руками и именно у нас. Это не значит, что ошибок нет; это значит, что между нашей ошибкой и массовым сканированием интернета нет готового моста.
И честная цена. За нами не стоит вендор: если ошибка в нашем коде, бюллетень никто не выпустит и заплатку не пришлёт — чинить нам, и срок зависит от того, на связи ли мы. Для сайта-визитки, каталога или сайта заведения это приемлемо. Для системы, в которой лежат деньги или персональные данные тысяч людей, нужен поставщик с обязательствами по срокам — как у Django, который мы разбирали отдельно.
Что можно проверить у себя сегодня
Пятнадцать минут, разработчик не нужен.
- Выпишите состав. Движок и его версия, расширения с версиями, версия PHP, веб-сервер, операционная система. Если такого списка нет, то и обновлять нечего: непонятно, что у вас стоит.
- Найдите, где поставщик публикует бюллетени, и подпишитесь. У WordPress это раздел безопасности в блоге проекта, у Django — рассылка и блог, у Atlassian Data Center — страница бюллетеней. Узнавать о таком из новостей уже поздно.
- Ответьте на вопрос, кто ставит обновление и за какое время. Вы, хостинг или подрядчик. Если ответ «я когда-нибудь», то это ответ «никогда».
- Включите автообновления там, где они есть. Для небольшого сайта риск сломаться на обновлении обычно меньше риска остаться на уязвимой версии.
- Уберите админку из открытого интернета — ограничением по адресам, через VPN или паролем на уровне веб-сервера. Это отсекает большую часть автоматических атак сразу, независимо от версии движка.
- Если у вас WordPress — проверьте, что стоит версия от 6 октября: 7.1.3, 7.0.7, 6.9.10 или 6.8.11. И посмотрите журналы за 22–23 сентября.
- Если у вас свой Atlassian Data Center — обновитесь сейчас: Jira Software 11.3.12, 10.3.26 или 9.12.40; Jira Service Management 11.3.12, 10.3.26 или 5.12.40; Confluence 10.2.19 или 9.2.26; Bitbucket 10.5.1, 10.2.8 или 9.4.26; Bamboo, Crowd, Crucible и Fisheye — по бюллетеню. И просмотрите журналы на предмет запросов, в путях которых встречается
::или переходы вверх по каталогам.
Коротко
- Два часа прошло между публикацией технического разбора уязвимости Atlassian и первыми попытками эксплуатации на серверах-приманках.
- С WordPress то же самое: сканирование началось в день выхода заплатки, на следующий день трафик вырос более чем в десять раз и шёл с нескольких сотен адресов.
- Публикация заплатки сообщает, где была ошибка. Атакующий пишет проверку один раз на весь интернет, владелец обновляет свой сайт руками.
- Среднее время до эксплуатации у Mandiant — 5 дней за 2023 год (47 без удаления выбросов) и минус 7 дней за 2025-й. Медиана полного устранения со стороны владельца — 43 дня.
- Публичный код эксплойта есть у 26% уязвимостей, эксплуатируют около 1%. Паника по каждому сообщению не нужна, очередь на обновление нужна.
- За девять с половиной месяцев 2026 года: Tilda — 0 срочных обновлений для владельца, Битрикс — 2, OpenCart — 2, Laravel — 3, Joomla — 6, Django — 8, WordPress — 8 плюс поток уязвимостей в плагинах, Astro — 9.
- Эти числа не ранжируют системы по безопасности: больше находят там, где больше ищут, а малое число иногда значит, что чинить некому.
- Если обновлять некому — конструктор надёжнее своей копии CMS. Сайт без зависимостей сокращает очередь до операционной системы, веб-сервера и PHP, но не отменяет её.
Как мы считали
- Период: 1 января — 10 октября 2026 года. Это 283 дня, не полный год, и сравнивать эти числа с чьими-то годовыми нельзя.
- Единица счёта — событие, а не номер версии. Один выход исправлений безопасности считается за одно обновление, даже если он вышел сразу в четырёх ветвях под четырьмя номерами. У WordPress номеров версий за период больше тридцати, а событий «надо срочно обновиться» — восемь.
- Источники по системам: раздел безопасности в блоге WordPress, Security Centre у Joomla, архив security-релизов Django, страницы security advisories на GitHub у Laravel, Livewire, Filament и Astro, страница релизов OpenCart, «Центр информирования о необходимых обновлениях» у 1С-Битрикс.
- Уязвимости в плагинах WordPress — 5231 запись по выгрузке из базы NVD за период по ключевому слову. Это записи с упоминанием WordPress, подавляющее большинство относится к плагинам, но формальной разметки «плагин или тема» в NVD нет, поэтому мы её и не приводим.
- По Битриксу приводим только подтверждённые записи вендора. Банк данных угроз ФСТЭК закрыт для автоматического сбора, поэтому общего числа записей за 2026 год у нас нет, и выдумывать его мы не будем.
- Чего мы не делали: не проверяли, применима ли каждая уязвимость к конкретной конфигурации, не считали уязвимости PHP, веб-серверов и операционных систем и не сканировали чужие сайты.
Источники
- Разбор уязвимости Atlassian и оценка числа затронутых установок — watchTowr Labs, 6 октября 2026 года.
- Два часа до первых попыток, список адресов и шаблон Nuclei — данные Previdian в публикациях BleepingComputer и The Hacker News, 7 октября 2026 года.
- Хронология атак на WordPress после выхода 7.1.2 — разбор Patchstack.
- Среднее время до эксплуатации — Mandiant, Time-to-Exploit Trends: 2023 и M-Trends 2026.
- Доли эксплуатируемых уязвимостей и число записей с публичным эксплойтом — VulnCheck, State of Exploitation 1H 2026.
- Сроки устранения на стороне владельца — Verizon Data Breach Investigations Report 2026 и Edgescan Vulnerability Statistics Report 2026.
- Возраст эксплуатируемых уязвимостей — GreyNoise, Mass Internet Exploitation Report.
- Случай с 22 минутами — отчёт Cloudflare по безопасности приложений, март 2024 года.
- Релизы и бюллетени: WordPress, Joomla, Django, Laravel, Astro, OpenCart, 1С-Битрикс.
- Заявления платформы о безопасности — страница безопасности Tilda.
- Наши прежние разборы: Django, Laravel, OpenCart, Astro, Tilda, зависимость от чужой инфраструктуры.