FirstVDS Хостинг

Статус на момент публикации (3.07.2026). Все серверы локации «Амстердам» работают в штатном режиме. Дата-центр функционирует на внешнем (резервном) чиллере; работы по восстановлению основной системы охлаждения продолжаются. Мы держим ситуацию под усиленным контролем. Пока основная система охлаждения не восстановлена и не подтверждён резерв, мы считаем ситуацию незакрытой.

Это подробный разбор того, что произошло с локацией «Амстердам» в мае–июле 2026 года, почему это случилось, что мы сделали не так и что делаем дальше. Мы понимаем, что подвели вас, и приносим извинения. Ниже — по существу

Коротко о главном

• В мае–июле 2026 года в дата-центре нашей локации «Амстердам» (Qupra DC2) произошла серия отказов системы охлаждения. Оборудование уходило в аппаратную защиту от перегрева, из-за чего серверы были недоступны.
• Первопричина — отказы системы охлаждения на стороне дата-центра. Аномальная жара стала триггером, но не единственной причиной: цепочка инженерных и эксплуатационных отказов на площадке превратила единичный сбой в каскад (подробно — ниже).
• Данные клиентов сохранены. Аварии касались доступности, а не целостности данных.
• Компенсация и бонусы для пострадавших клиентов локации «Амстердам»: возврат за фактический простой на баланс (тикет в техподдержку, по SLA) плюс бонусы-промокоды на продление — QUPRA100 (100% на 14 дней) и следом QUPRA15 (15% на 3 месяца). Для уже ушедших клиентов — отдельный порядок. Подробнее — в разделе «Компенсации и бонусы».
• Мы не рассматриваем гарантии или доработки со стороны Qupra — только переезд локации на новый дата-центр.
• Повышение цен, о котором вы получили уведомление, — не связано с инцидентом: это совпадение по времени, и мы это учли (см. раздел «О ценах»).

Что произошло
В дата-центре Qupra DC2 (Амстердам), где размещена наша локация «Амстердам», несколько раз выходила из строя система охлаждения. Когда охлаждение останавливается, оборудование в стойках быстро перегревается, и включается защита. Часть её срабатывает автоматически, на уровне железа: процессоры снижают частоты (троттлинг), а при достижении критической температуры сервер аппаратно выключается сам. Часть — управляемо, по нашему решению: чтобы не ронять машины жёстко и сохранить ваши данные, мы штатно и контролируемо выключаем серверы (graceful shutdown), а дата-центр при необходимости обесточивает перегретые стойки со своей стороны. Результат в любом случае один: сервер временно недоступен.

Каждый такой отказ приводил к многочасовому простою локации. Самая длительная авария в конце июня — начале июля растянулась почти на двое суток.

Хронология
Ниже — все известные нам эпизоды недоступности локации «Амстердам», связанные с охлаждением. Время указано по МСК.

• 27.05.2026, 12:33 → 19:42 (≈5 часов). Отказ системы охлаждения: вышел из строя основной чиллер на крыше. Вечером дата-центр привёз и установил резервный чиллер.
• 26.06.2026, 16:51 → 21:55 (≈5 часов). Снова отказ охлаждения. Инцидент пришёлся на ночь выходного дня. Мы не опубликовали о нём информацию своевременно — это была ошибка (см. раздел «Что мы сделали неправильно»).
• 29.06.2026, 13:10 → 16:58 (≈4 часа). Очередной отказ охлаждения.
• 29.06 (поздний вечер) → 01.07.2026, 22:24 — самая длительная авария (≈44 часа). Отказавший чиллер запустить не удалось. Дата-центр организовал доставку и подключение внешнего чиллера, но подключение затянулось из-за отсутствия на площадке нужных силовых кабелей — их привезли только 1 июля. Внешний чиллер подключили около 14:00, серверы начали подниматься примерно с 15:30, восстановление шло поэтапно.

Суммарная недоступность локации за май–июль составила порядка 58 часов. Мы не считаем это приемлемым и не спорим с вашими собственными подсчётами простоя — они верны.

Почему это произошло
Триггером отказов стала аномальная жара в Западной Европе летом 2026 года: система охлаждения площадки не удержала тепловую нагрузку при высокой наружной температуре. Но жара — не единственная причина. За затяжным простоем конца июня стоит цепочка инженерных и эксплуатационных отказов на самой площадке.

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

• До конца мая охлаждение обеспечивал основной чиллер на крыше здания. 27 мая он вышел из строя.
• Дата-центр привёз резервный чиллер, разместил его за зданием и запитал от внешнего дизель-генератора, подключив к системе охлаждения. Нам сообщили, что основной (крышный) чиллер также восстановлен.
• В конце июня внешний дизель-генератор, питавший резервный чиллер, был убран с площадки — и резервный чиллер обесточился.
• Дата-центр переключился на основной чиллер, но тот, вопреки сообщению о восстановлении, к вечеру отказал окончательно — запустить его не удалось даже с привлечённым сервисным инженером.
• Оперативно найти замену дизель-генератору не получилось. Для подключения резервного чиллера напрямую к электрощиту площадки пришлось заказывать силовые кабели (около 60 метров), доставка заняла порядка суток. На это время охлаждение держали на фрикулинге, без компрессора.
• После доставки кабелей резервный чиллер подключили штатно, и охлаждение вышло на рабочий режим. На сегодня локацию охлаждает один исправный чиллер; второй (на крыше) остаётся в восстановлении.

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

Наша ответственность
Мы не будем прятаться за формулировкой «виноват дата-центр». За питание и охлаждение физически отвечает площадка, а не хостинг-провайдер, — но выбор площадки это наша ответственность. Мы разместили вашу инфраструктуру в Qupra DC2, мы на ней оставались, и перед вами за результат отвечаем мы. Именно поэтому наше решение — уходить с площадки, а не ждать её доработок (см. «Что мы меняем»).

Мы переехали в Qupra DC2 в конце 2025 года, когда прежняя площадка (euNetworks) закрывалась и просила арендаторов освободить помещение. Новый дата-центр оказался не готов держать нашу нагрузку. Это в том числе наш урок по выбору и аудиту площадки.

О слухах: это НЕ история с изъятием серверов
Этим летом в Амстердаме случилось несколько разных инцидентов у разных операторов, и в сети их смешивают. Уточним прямо: наш инцидент — технический, связан только с охлаждением. Он не имеет отношения к истории с принудительным обесточиванием и изъятием серверов у другого оператора в другом дата-центре, которая обсуждалась в те же недели. Ваши серверы никто не изымал и не опечатывал, доступ к ним не блокировался по чьему-либо требованию.

Что с вашими данными
Данные клиентов локации «Амстердам» сохранены. Аварии касались доступности: серверы уходили в защиту и обесточивались контролируемо именно для того, чтобы сохранить оборудование и данные. Потери данных по причине инцидента с охлаждением не зафиксировано. Если у вас есть основания подозревать проблему с целостностью данных на конкретной услуге — напишите тикет, разберём индивидуально и в приоритете.

Что мы сделали неправильно
Отдельно и без смягчений — о наших собственных ошибках.

Мы не остановили приём заказов в проблемной локации. Во время аварии заказ новых серверов в локации «Амстердам» оставался доступен. Из-за этого часть клиентов оформили серверы, которые невозможно было развернуть сразу, пока инфраструктура была недоступна. Это наша ошибка. Все такие серверы были развёрнуты после восстановления работы кластера.

Мы своевременно не сообщили об инциденте 26 июня. Авария пришлась на ночь выходного дня, и мы не опубликовали информацию ни в тот день, ни на следующий. Молчание — худшее, что можно сделать в такой ситуации: оно оставляет вас без информации и разрушает доверие сильнее самого сбоя. Так делать нельзя, и мы это исправляем.

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

Компенсации и бонусы
Разделяем две вещи: компенсацию за фактический простой и бонус сверх неё. Оба доступны клиентам локации «Амстердам», чьи затронутые услуги были активны в период инцидента.

Компенсация за простой (по SLA)
Возврат средств за фактическое время недоступности — на баланс, по SLA. Чтобы её получить, напишите тикет в техподдержку: мы рассчитаем простой по вашей услуге и вернём его стоимость на баланс.

Бонусы (промокоды)
Сверх компенсации — два промокода на продление серверов локации NL (все тарифы). Тикет для них не нужен, они применяются вами самостоятельно в личном кабинете. Действуют только для услуг, заказанных до 1 июля 2026; скидка распространяется и на сам сервер, и на дополнительные услуги.

Промокоды применяются последовательно, именно в таком порядке:

• QUPRA100 — скидка 100% на 14 дней. Активировать с 3 июля по 3 августа. После активации сервер будет работать две недели бесплатно.
• QUPRA15 — скидка 15% на 3 месяца. Активировать с 18 июля по 31 августа, после того как отработают 14 дней по QUPRA100.

Важно: сначала QUPRA100, затем QUPRA15. Если активировать 15% раньше, он перебьёт скидку 100%. Все действующие скидки отображаются в личном кабинете в разделе «Скидки». Пошаговая инструкция — здесь.

Если вы уже отказались от услуги из-за инцидента

• Компенсация — в общем порядке: напишите тикет в техподдержку, мы вернём стоимость простоя на баланс (с последующим выводом на вашу карту или счёт).
• Бонус — в ручном режиме: напишите тикет в отдел продаж и опишите ситуацию. Мы вручную назначим скидку на новую услугу с аналогичными условиями (100% на 14 дней, далее 15% на 3 месяца).

Стоимость новых услуг не должна превышать стоимость ваших услуг, пострадавших в результате инцидента.

Почему мы не компенсируем упущенную выгоду
Отдельно и честно — о том, что многие ждут, но чего мы сделать не можем.

Мы понимаем, что для многих из вас простой — это не «минус несколько часов аренды», а остановленные заказы, недоступные кассы, сорванные процессы и потерянные клиенты. Это реальный ущерб, и мы его не обесцениваем.

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

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

О ценах
Понимаем, как это выглядит со стороны: сервис падал — а вы получили уведомление о повышении цен. Это совпадение по времени: плановое изменение тарифов готовилось заранее и не связано с инцидентом. Тем не менее момент вышел болезненным, и та же скидка 15% на продление затронутых услуг (см. «Компенсации и бонусы») смягчает для вас это повышение.

Что мы меняем
Площадка. Принято решение уходить из Qupra DC2. Сейчас мы выбираем новый дата-центр. Основной кандидат, которого мы оцениваем, — площадка в Амстердаме уровня Tier 3 с сертификацией управления непрерывностью бизнеса (ISO 22301) и точкой присутствия AMS-IX; параллельно рассматриваем ещё несколько вариантов. Решение принимаем на этой неделе. Конкретную площадку, график переезда и порядок переноса объявим отдельным анонсом. Сам переезд спланируем так, чтобы исключить или свести простой к минимуму и заранее предупредить вас по каждой затронутой услуге. Текущие IP-адреса на услугах будут сохранены.

Текущее состояние. До восстановления основной системы охлаждения и подтверждения резерва локация остаётся под усиленным мониторингом. Сейчас она работает на внешнем чиллере.

Коммуникация. Мы работаем по принципу, который в этом инциденте показал себя как единственно

• правильный, — говорить честно и по делу:
• регулярные апдейты по расписанию во время аварии, с указанием времени следующего обновления;
• дежурный специалист на связи во время инцидента;
• никакой цензуры в чатах — мы не удаляем критику, не баним пользователей за неудобные вопросы, модераторы следят только за порядком.

Продажи. Внедряем механизм остановки приёма заказов в проблемной локации на время аварии, чтобы ситуация с «оплатил — не развернулся сразу» не повторилась.

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

Вчера (2 июля) один из серверов виртуализации в ЦОД Алматы перестал отвечать, так как произошёл аппаратный отказ процессора AMD EPYC 9655.

Почему не сразу удалось выявить причину проблемы, как это связано с параллельными событиями в локации, как было выполнено восстановление — в нашем разборе.

Инцидент
Необходимо отметить, что сетевые события, происходившие в тот же период, не были прямой причиной аварии сервера. Ни плановые работы на сети оператора, объявленные до инцидента с сервером, ни внеплановые работы на канале, начавшиеся позднее, не были связаны с аппаратным отказом узла виртуализации. Эти события совпали по времени с восстановительными работами и повлияли на сроки миграции виртуальных машин, но не являлись причиной отказа сервера.

Особенность инцидента заключалась в том, что неисправность процессора не проявлялась при загрузке rescue-окружения с флешки. Сервер проходил базовую загрузку и позволял выполнять первичную диагностику, однако после запуска полноценной операционной системы и появления нагрузки от процессов виртуализации KVM происходило зависание ОС. Сервер переставал штатно отвечать на управление, и для продолжения работ требовалась принудительная перезагрузка.

Ситуация дополнительно осложнялась тем, что каждая перезагрузка занимала значительное время: серверная платформа проходила длительную самодиагностику, в основном связанную с большим объемом оперативной памяти. Один цикл зависания и последующей перезагрузки приводил примерно к 10 минутам потери времени.

Инцидент также был осложнен повреждением загрузочной инфраструктуры на RAID1-массиве. Позднее, уже в ходе восстановительных работ, миграция виртуальных машин была дополнительно задержана из-за независимого сетевого события: магистральный оператор RETN начал работы на канале без предварительного уведомления FirstVDS вследствие человеческой ошибки.

Несмотря на сочетание нескольких факторов, виртуальные машины были перенесены на соседние узлы без потери клиентских данных.

Влияние на сервис
В период инцидента виртуальные машины, размещенные на аварийном узле, были недоступны из-за зависаний сервера под нагрузкой.

Для предотвращения повторного зависания операционной системы все виртуальные машины на узле были остановлены. Дополнительно инженер принудительно завершал процессы, которые автоматически запускались и могли снова создать нагрузку на деградировавшие процессорные ядра.

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

Потери клиентских данных не зафиксировано.

Первопричина
Первопричиной инцидента стал аппаратный отказ процессора AMD EPYC 9655.

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

После запуска основной операционной системы и появления нагрузки от KVM происходило зависание ОС. Это указывало на нестабильность вычислительной части платформы, а не на простой отказ загрузки или единичную проблему дисковой подсистемы.

Почему первоначально возникла версия о проблеме с дисками
На первом этапе была выдвинута гипотеза о неисправности дисковой подсистемы. Для проверки этой версии диски аварийного узла были перенесены в другой сервер.

На сервере-доноре система не загрузилась. Из-за этого первоначально был сделан вывод, что проблема может быть связана именно с дисками. После этого накопители были возвращены обратно в исходный сервер.

Позднее было установлено, что причина незагрузки на доноре была не в отказе самих накопителей. Проблема заключалась в повреждении загрузочной логики: загрузочный раздел на RAID1-массиве был поврежден, а GRUB2 находился в неработоспособном состоянии.

Инженер полностью восстановил загрузку: заново настроил GRUB2 и вручную создал EFI-записи в NVRAM материнской платы. После этого узел начал загружать основную операционную систему, однако под нагрузкой виртуализации снова воспроизводилось зависание ОС.

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

Дополнительное диагностическое наблюдение
Во время диагностики был выполнен обратный тест: диски от другого сервера были установлены в неисправную платформу.

Операционная система с этих дисков загрузилась и работала без зависаний. На первый взгляд это могло противоречить версии об отказе процессора. Однако позднее причина стала понятна: сервер с этими дисками был фактически пустым и не создавал существенной нагрузки на процессорные ядра. На нем не работали клиентские виртуальные машины и процессы KVM с реальной нагрузкой.

Поэтому в таком режиме деградация процессора не проявлялась.

Рассмотренные варианты восстановления
Рассматривались два основных сценария восстановления.

• Повторно перенести диски в исправную серверную платформу и продолжить восстановление на доноре.
• Стабилизировать аварийный сервер в ограниченной конфигурации и выполнить миграцию виртуальных машин с него на соседние узлы.

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

Отдельно рассматривался вариант физического демонтажа неисправного процессора. Однако он также не являлся оптимальным: вместе с процессором сервер потерял бы доступ к части оперативной памяти и части NVMe-накопителей, так как они подключены через соответствующие PCI Express-линии. Это могло дополнительно осложнить восстановление и снизить вероятность корректного доступа ко всей конфигурации узла.

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

Стабилизация узла
После восстановления GRUB2 и EFI-записей сервер начал загружать основную операционную систему, но зависал при появлении нагрузки от виртуализации.

Для снижения нагрузки все виртуальные машины были остановлены. Также инженер принудительно завершал процессы, которые автоматически запускались и могли снова привести к зависанию ОС.

После серии восстановительных действий инженеру удалось стабилизировать работу операционной системы. Сбойные ядра процессора были исключены из использования, и сервер был запущен в ограниченной конфигурации на 16 работоспособных ядрах.

Этого состояния оказалось достаточно для безопасной миграции виртуальных машин на соседние узлы кластера.

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

Параллельно с восстановительными работами на сервере магистральный оператор RETN начал плановые работы без предварительного уведомления FirstVDS. По информации оператора, причиной отсутствия уведомления стала человеческая ошибка.


После восстановления интернет-связности миграция была продолжена.

Итог восстановления
После восстановления сети все виртуальные машины и данные были перенесены на соседние узлы кластера.

Потери клиентских данных не произошло.

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

Выводы
Инцидент был вызван нестандартным аппаратным отказом процессора AMD EPYC 9655. Отказ не проявлялся в минимальном rescue-окружении и становился заметен только после запуска полноценной операционной системы под нагрузкой виртуализации.

Диагностику осложнили следующие факторы:

• Повреждение загрузочного раздела RAID1 и неработоспособность GRUB2.
• Необходимость вручную восстанавливать GRUB2 и EFI-записи в NVRAM материнской платы.
• Длительная самодиагностика серверной платформы после каждого зависания и перезагрузки.
• Неочевидный характер отказа процессора, который проявлялся только под нагрузкой KVM.
• Независимое сетевое событие, вызванное незаявленными работами оператора RETN.

Какие меры мы уже предприняли и что ещё планируем сделать:

• Вся хронология событий и симптомы проблемы внесены в нашу внутреннюю базу знаний, чтобы в случае возникновения аналогичной ситуации время на устранение значительно сократилось.
• В ближайшее время мы закончим организацию второго канала с магистральным провайдером Транстелеком Казахстан, чтобы не зависеть только от RETN.
• Возместим время простоя вашего VPS в локации Казахстан за 2 июля. Для этого, пожалуйста, напишите запрос в техподдержку.

Лето — время, когда хочется выдохнуть, закрыть ноутбук и оказаться на берегу тёплого моря с коктейлем в руке. Но реальность оказывается куда прозаичнее. В самый разгар мечтаний погружает в стремительный круговорот задач, дедлайнов и нерешённых проблем, которые уносят всё дальше и дальше от долгожданного отдыха…


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

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

В общем, листайте и выдыхайте!

Статьи и инструкции
Установка и настройка Portainer
Если у вас несколько Docker-хостов, может возникнуть вопрос, как управлять ими централизованно. Ответ — Portainer, веб-платформа для организации контейнерной инфраструктуры через единый GUI и REST API. Подключается к средам на базе Docker, Docker Swarm и Kubernetes и позволяет администрировать их из одного интерфейса. В статье на примере Ubuntu 24.04 пошагово показываем, как поднять и запустить её вручную
firstvds.ru/technology/ustanovka-i-nastroyka-portainer
Как установить и запустить vLLM: от базовой проверки до тяжёлых моделей
vLLM — сервер для запуска ИИ-моделей с открытым API. С его помощью можно поднять локальный эндпоинт для больших языковых моделей и подключить к нему свои приложения, чат-ботов или агентов. В статье рассказываем про два варианта установки vLLM — uv и Docker, а также разбираем основные параметры запуска.
firstvds.ru/technology/kak-ustanovit-i-zapustit-vllm

Habr: самое интересное за июнь
Ловите подборку из нашего блога на Хабре. Гвоздь программы — статья о том, как мы взяли L40S и vGPU на 16 ГБ и прогнали через бенчмарки в реальных задачах. Далее — пара рабочих гайдов: как ускорить сайт через оптимизацию изображений и как организовать личный CI/CD. Бонусом — необычная история о математике и плагиате.

• Тестируем выделенный L40S и vGPU на 16 ГБ по производительности (llama.cpp, ComfyUI)
• Оптимизация под Pagespeed: работа с изображениями как с наиболее частой и весомой проблемой сайтов
• Личный CI/CD за один вечер: настраиваем GitLab Runner на собственном VPS
• Человек, укравший бесконечность: подлинная история Георга Кантора

Ищем авторов для блога на Хабр.

Подготовьте статью на одну из специальных тем или отправьте материал на тему месяца. И если ваша статья подойдёт для блога, вы получите повышенный гонорар.
Тема июля: Алгоритмы.
firstvds.ru/avtoram

Новости июня
Запустили новую услугу — «Мониторинг сайтов»

Теперь следить за доступностью сайта, сервера, домена и SSL-сертификата можно в одной панели. Сервис работает 24/7, отслеживает четыре ключевых параметра и при появлении проблем сразу отправляет уведомления на email, в телеграм, VK и другие каналы. Это помогает быстрее замечать сбои, не тратить время на ручные проверки и снижать риск простоев.
firstvds.ru/services/site-monitoring

Кешбэк до 10% по выходным в течение всего лета

Летние выходные стали ещё приятнее. Каждую пятницу, субботу и воскресенье за пополнение баланса (на рекомендуемую сумму и выше) можно получить кешбэк до 10%. Посмотреть рекомендуемую сумму можно через форму пополнения баланса на сайте или в Личном кабинете.
Процент кешбэка выше, если оплачивать услуги через СБП. Акция продлится до 30 августа.

Добавили новые рецепты для автоустановки на сервере

В июне мы добавили три новых рецепта для быстрого развёртывания популярных сервисов на VDS. При заказе сервера просто выбираете нужный рецепт и получаете VDS с уже предустановленным ПО. Все рецепты — бесплатные.
OpenClaw и Hermes Agent — self-hosted платформы для ИИ-агентов. Обе позволяют общаться с ассистентом через веб-интерфейс или в телеграме. Встроенные инструменты включают поиск в интернете и работу с файлами. OpenClaw интегрируется с Gmail, GitHub и другими сервисами, а также даёт доступ к агенту через API. Hermes Agent умеет подключаться к терминалу сервера и планировщику задач cron, что удобно для автоматических фоновых сценариев.
n8n — open-source платформа для автоматизации без кода. Поможет создать сценарии из готовых блоков в визуальном редакторе: от сбора данных по расписанию до отправки уведомлений и резервного копирования.

Доступна регистрация домена на родном языке

Теперь зарегистрировать сайт или почту можно на родном языке — без транслита и искажений. В зону.РФ добавлены буквы абазинского, татарского, чеченского, якутского и ещё 13 языков. А также 26 новых кириллических символов. Меньше барьеров, больше родного языка в интернете.
firstvds.ru/services/domain_names
Важно: С 1 сентября вступят в силу требования ФЗ № 569: владельцам доменов придётся проходить обязательную идентификацию через Госуслуги. Оформляйте домен на реальные данные, чтобы избежать проблем в дальнейшем.

Июньские изменения: что важно знать

Жизнь не стоит на месте, и июнь 2026-го — очередное тому подтверждение. Собрали самое важное в одном месте, чтобы вы были в курсе изменений и могли заранее к ним подготовиться.
О частичной недоступности ресурсов по HTTPS
С 1 июля повысятся цены на VDS и объектное хранилище S3
Новые правила работы с SSL-сертификатами

Новости из мира технологий и безопасности
Кажется, июнь решил проверить нас на прочность. И принёс не только новости о том, что нужно принимать новые правила игры, но и целый ворох критических уязвимостей. Держите подборки о главных угрозах месяца и помните — главное, не сдаваться и вовремя устанавливать обновления:

Один HTTP-запрос открывает доступ к любому аккаунту в phpBB
В свободном движке для форумов phpBB нашли уязвимость обхода аутентификации. Одним HTTP-запросом атакующий подключается к сессии любого пользователя форума, включая администратора. Проблема проявляется в конфигурации по умолчанию — никаких специальных условий или знания внутреннего устройства платформы не требуется. По данным исследователей, ошибка прожила в кодовой базе около десяти лет.
Метод эксплуатации уже воссоздали с помощью ИИ на основе патча. Запрос идёт к обработчику login_link с методом аутентификации auth_provider=apache, а логин подставляется через Basic Auth. После этого PHP выставляет переменную окружения PHP_AUTH_USER, и phpBB достаёт из неё логин без проверки пароля.
Уязвимость затрагивает все версии веток 3.x и 4.x вплоть до phpBB 3.3.16 и 4.0.0-a2. Перехват сессии обычного пользователя даёт доступ к приватной переписке и возможность писать от его имени. С сессией модератора или администратора добавляются удаление чужих сообщений, просмотр IP-адресов и email, чтение приватной переписки. Но даже админская сессия не открывает саму панель администрирования: вход в неё защищён отдельной проверкой пароля, поэтому до хоста и удалённого выполнения кода баг не доводит. Искать жертв несложно — список участников на форумах phpBB по умолчанию открыт всем.
Уязвимость обнаружили в начале июня специалисты компании Aikido и через программу bug bounty на HackerOne передали данные разработчикам. Те отреагировали быстро: уже 6 июня вышел патч в составе версии 3.3.17. Крупные форумы исследователи предупредили напрямую.
Что делать: обновиться до версии 3.3.17. Для ветки 4.x стабильного исправления пока нет, поэтому пользователям рекомендуют перейти на актуальную версию. После обновления некоторые форумы могут столкнуться с проблемами в работе OAuth-аутентификации — это связано с переносом обработчика OAuth-переадресации.
www.opennet.ru/opennews/art.shtml?num=65667
xakep.ru/2026/06/16/phpbb-auth-bypass/

В AUR захватили 1577 пакетов и раздавали из них вредонос
AUR (Arch User Repository) массово скомпрометировали — через этот репозиторий в Arch Linux распространяют приложения от сторонних разработчиков. Атакующие получили контроль примерно над 1577 пакетами и внедрили в них код для кражи паролей и ключей доступа. Среди затронутых оказался ALVR — пакет, популярный у любителей компьютерных игр.
Схема простая. Атакующие брали на себя заброшенные пакеты со статусом orphaned: указывали имя прежнего мейнтейнера, но другой email, добавляли один коммит и публиковали обновление. Коммит добавлял npm в зависимости PKGBUILD и вставлял в post_install-блок скрипта install.sh установку нескольких NPM-пакетов. Среди них — один-два легитимных и пакет atomic-lockfile или js-digest со скрытым вредоносным ПО. Установку прописывали во все скомпрометированные проекты, даже туда, где JavaScript и NPM не используются.
После активации вредонос закреплялся в системе как сервис systemd со случайным именем и маскировался под поток ядра. С правами root он создавал сервис на системном уровне (/etc/systemd/system) и дополнительно поднимал rootkit уровня ядра; с правами пользователя — запускал его от имени пользователя (~/.config/systemd/user). Дальше он сканировал систему и отправлял на внешний сервер ключи и учётные данные VPN, Docker, Podman и SSH, конфиденциальные данные из браузера, историю команд shell, ключи криптокошельков и токены доступа к Slack, Microsoft Teams, Discord, GitHub, NPM и Vault.
Масштаб рос на глазах: загрузку вредоносного js-digest успели внедрить в 879 пакетов, общее число захваченных оценивают в 1577. Первой волны не хватило — позже подставили код ещё в 54 пакета, на этот раз через зависимость bun и обфусцированную строку с установкой через bun add. Разработчики Arch Linux принимают меры, поэтому до окончательного решения возможны проблемы с регистрацией новых учётных записей в AUR, отправкой обновлений и созданием пакетов.
www.opennet.ru/opennews/art.shtml?num=65670

Дыра в JCE для Joomla открывает прямой путь к веб-шеллу
В JCE (Joomla Content Editor) — одном из старейших и популярнейших расширений Joomla — устранили критическую уязвимость CVE-2026-48907. Она позволяла импортировать профиль без аутентификации: атакующий заливал профиль, который отключал проверку MIME-типов и разрешал загрузку PHP-скриптов на сервер. Уязвимость успели взять на вооружение — зафиксированы реальные атаки, в которых злоумышленники ставили веб-шелл и получали удалённый доступ к системе. Затрагивает все версии JCE — от Joomla 3 до Joomla 6.
Что делать: обновиться до выпуска 2.9.99.5, следом за которым вышло обновление 2.9.99.6 с усилением защиты. После обновления стоит убедиться, что система не скомпрометирована и в ней не остался бэкдор:

• проверить подставной профиль (как правило, у него бессмысленное автоматически сгенерированное имя): Компоненты → Редактор JCE → Профили редактора;
• убедиться, что в параметре Разрешённые расширения файлов нет разрешения на загрузку PHP-файлов;
• просмотреть логи на предмет запросов к URL импорта профилей: index.php?option=com_jce&task=profiles.import;
• проверить сайт на сторонние .htaccess и файлы с именами, типичными для WordPress, а не Joomla, — например, wp-config.php и wp-cron.php.

www.opennet.ru/opennews/art.shtml?num=65715

Один восклицательный знак в ядре Linux открывает путь к root
Исследователи Exodus Intelligence разобрали уязвимость CVE-2026-23111 в подсистеме nf_tables. Это механизм пакетной фильтрации в ядре Linux: он управляет правилами брандмауэра и сменил iptables, ip6tables, arptables и ebtables. Виной всему один лишний восклицательный знак в коде — из-за него возникла ошибка use-after-free. Она позволяет непривилегированному пользователю или процессу поднять права до root.
Уязвимость ломает процесс удаления вердиктов — определений, которые решают, подходит ли пакет под правило. В нём участвуют элементы catchall: они работают как подстановочный знак, когда совпадений с другими элементами набора нет. Когда карта вердиктов удаляется из памяти, catchall-элементы деактивируются, а счётчик ссылок цепочки уменьшается. Если при удалении возникает ошибка, операция отменяется, а счётчик возвращается обратно. CVE-2026-23111 позволяет вмешаться в этот процесс: эксплойт уменьшает счётчик произвольное число раз, а затем удаляет и освобождает цепочку, хотя часть объектов всё ещё на неё ссылается. Так и появляется обращение к уже освобождённой памяти.
Если верить Exodus Intelligence, эксплойт многократно срабатывает на этой уязвимости и приводит к утечке базового адреса ядра, затем адресов кучи и перехвату потока управления. На неактивной системе авторы добились стабильности выше 99 %. Уязвимость воспроизводится на Debian и Ubuntu.
Уязвимость закрыли в ядре ещё в феврале. В апреле эксплойт продемонстрировала компания FuzzingLabs, а затем собственный рабочий эксплойт опубликовала и Exodus Intelligence — он тоже работал на Debian и Ubuntu.
Такие баги особенно опасны в связке: вместе с отдельным эксплойтом они позволяют обходить встроенную защиту операционной системы.
Что делать: Исправление вышло ещё в феврале — установите обновление ядра.
3dnews.ru/1143264/v-yadre-linux-nashli-seryoznuyu-uyazvimost-sozdannuyu-vsego-odnim-lishnim-simvolom-v-kode/

Гонка в процессорах ARM выпускает гостя за пределы виртуальной машины
Компания ARM раскрыла уязвимость CVE-2025-10263 в своих процессорах. Она позволяет писать в ресурсы, принадлежащие более высокому уровню исключений (Exception Level), и так повышать привилегии в системе. В связке с гипервизором Xen последствия еще более серьёзные: гостевая система может писать в память гипервизора.
В основе — рассинхронизация при операции TLBI (TLB Invalidation), которая очищает запись в кэше трансляции адресов (TLB). Инструкция DSB (Data Synchronization Barrier) подтверждает выполнение TLBI. Но на одном процессорном ядре она может отработать раньше, чем запись с другого станет видна всей системе. Из-за этого запись успевает пройти уже после того, как доступ был закрыт через TLBI.
Из-за этой рассинхронизации можно обойти сразу несколько барьеров защиты памяти: ограничения на уровне хоста (Stage 1) и виртуальной машины (Stage 2), а также защиту целостности памяти GPT (Granule Protection Table). На практике это выглядит так. Гипервизор командой TLBI закрывает виртуальной машине доступ к памяти. Система подтверждает, что доступ прекращён, — но гостевая ВМ всё равно продолжает туда писать.
Проблема проявляется только на многоядерных процессорах Arm: C1-Ultra, C1-Premium, Neoverse V3 и V3AE, Neoverse V2, Neoverse V1, Neoverse N2, Neoverse N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 и X1C, Cortex-A710, Cortex-A78, A78AE и A78C, Cortex-A77, Cortex-A76 и A76AE, а также NVIDIA Olympus.
Что делать:

• Для гипервизора Xen исправление уже выпущено — установите его.
• Для ядра Linux патч предложен, но в штатные обновления пока не вошёл — следите за апдейтами своего дистрибутива.

www.opennet.ru/opennews/art.shtml?num=65660

Червь mini-shai-hulud в 32 NPM-пакетах Red Hat
Злоумышленники скомпрометировали сборку релизов на GitHub Actions в репозиториях Red Hat (аккаунт RedHatInsights на GitHub). В результате в каталог NPM попали 64 вредоносные версии 32 пакетов для платформы Red Hat Cloud Services.
В код встроили новый вариант червя mini-shai-hulud. Об аналогичной атаке мы уже писали: тогда червь прошёл через пакеты TanStack и зацепил GitHub и OpenAI.
Новый вредонос ищет токены и учётные данные в окружении. Червь размещается в файле index.js и активируется через preinstall-обработчик при установке поражённого пакета. После запуска он ищет в системе токены к NPM (~/.npmrc), PyPI, CircleCI, AWS, GCP, Docker, Azure, HashiCorp и Kubernetes, а также закрытые ключи SSH, и отправляет найденное злоумышленникам. Если червь находит токен к NPM, он сам публикует новые вредоносные релизы для пакетов из текущего окружения — и так заражает дерево зависимостей.
Доступ к GitHub Actions злоумышленники получили через скомпрометированную учётную запись сотрудника Red Hat. Это позволило отправлять коммиты в репозитории javascript-clients, frontend-components и platform-frontend-ai-toolkit напрямую, в обход рецензирования. Через коммиты подставлялся файл ci.yaml, который при сборке запускал с помощью bun скрипт _index.js. Скрипт использовал полномочие id-token: write, чтобы запросить у GitHub токен OIDC (OpenID Connect), а затем применял его для аутентификации в NPM по механизму trusted publishing.
Кого затронуло: всех, кто устанавливал поражённые версии пакетов @redhat-cloud-services/*. Полный список из 32 пакетов с заражёнными версиями — тут.
Как защититься:

• Проверить, не установлены ли перечисленные версии. Если установлены — считать все токены и учётные данные на этой машине скомпрометированными и сразу их перевыпустить.
• Закрепить конкретные версии зависимостей и переходить на чистую установку из локфайла (npm ci).
• По возможности отключить выполнение установочных скриптов сторонних пакетов (npm install --ignore-scripts).

www.opennet.ru/opennews/art.shtml?num=65599

Захват WordPress-сайтов через плагин WP Maps Pro
В популярном плагине WP Maps Pro для WordPress нашли критическую уязвимость, которую злоумышленники уже эксплуатируют в реальных атаках. Баг позволяет без аутентификации создать на сайте учётную запись администратора и получить полный контроль над ресурсом.
Уязвимость получила идентификатор CVE-2026-8732 и оценку 9,8 балла по шкале CVSS. Под ударом — все версии WP Maps Pro до 6.1.0 включительно. Сам плагин коммерческий, его используют, чтобы встраивать на сайты карты Google Maps и OpenStreetMap, а также создавать локаторы магазинов и каталоги точек продаж.
Проблему обнаружил ИБ-исследователь Дэвид Браун (David Brown). По его словам, корень бага — в функции временного доступа для техподдержки, через которую специалисты разработчика подключаются к сайту клиента для диагностики. Реализация оказалась небезопасной: AJAX-эндпоинт был доступен неавторизованным пользователям и защищался только nonce-токеном, который через JavaScript публиковался на всех страницах сайта. В итоге проверка не давала реального контроля доступа.
Для эксплуатации хватало одного запроса с параметром check_temp=false. После этого плагин создавал нового пользователя с жёстко заданной ролью администратора, генерировал для него magic-ссылку и возвращал её в ответе. При переходе по ссылке WordPress авторизовал пользователя автоматически — ни пароль, ни дополнительные проверки не требовались. Получив права администратора, атакующий мог ставить вредоносные плагины, размещать веб-шеллы, внедрять бэкдоры, красть данные пользователей или полностью перехватить управление сайтом.
Кого затронуло: сайты на WordPress с установленным WP Maps Pro версии 6.1.0 и ниже. Атаки уже идут: в Wordfence сообщили, что за сутки заблокировали около 2858 попыток эксплуатации, а специалисты Defiant за тот же период зафиксировали более 3600 атак.
Как защититься: обновить WP Maps Pro до версии 6.1.1 или новее — патч вышел 20 мая 2026 года и ограничил доступ к проблемному эндпоинту только авторизованными администраторами. Учитывая, что эксплуатация уязвимости уже началась, откладывать обновление не стоит.
xakep.ru/2026/06/04/wp-maps-pro/

HTTP/2 Bomb: атака, которая исчерпывает память сервера
Раскрыта информация об уязвимости HTTP/2 Bomb, которая затрагивает разные реализации протокола HTTP/2 и позволяет добиться отказа в обслуживании, исчерпав всю доступную процессу память. Проблему подтвердили в конфигурации по умолчанию у nginx, Apache httpd (CVE-2026-49975), Microsoft IIS, Envoy (CVE-2026-47774) и Cloudflare Pingora.
Метод напоминает zip-бомбу, только применённую к сжатию заголовков в HTTP/2. Запрос может содержать тысячи сжатых заголовков (например, Cookie) без полезных данных. Каждый такой заголовок в запросе — это однобайтовая ссылка в индексе HPACK, но на сервере под него выделяется память под весь заголовок целиком. Отсюда и многократное усиление: на каждый байт в индексе сервер тратит куда больше.
Кого затронуло: перечисленные HTTP-серверы в конфигурации по умолчанию. Сервер Angie уязвимости не подвержен — защиту от этой атаки в него перенесли из freenginx ещё в версии 1.8.0 в 2024 году. Позднее наличие проблемы подтвердили и в HTTP-сервере h2o.
Как защититься:

• nginx — обновиться до 1.29.8: туда из freenginx перенесли директиву max_headers, которая по умолчанию допускает не более 1000 заголовков.
• Envoy — обновиться до 1.35.11 или 1.36.7 с лимитами mutable_max_request_headers_kb и max_headers_count.
• Cloudflare Pingora — обновиться до 0.8.1, куда добавили ограничения, блокирующие атаку.
• Apache httpd — исправление готово в модуле mod_http2 2.0.41, но в релизы Apache httpd оно ещё не вошло. До выхода релиза обновление сервера дыру не закроет — остаётся обновить mod_http2 вручную или использовать обходной путь (ниже).
• Microsoft IIS — исправления пока нет.
• h2o — исправление доступно в виде патча.
• В качестве обходного пути можно отключить HTTP/2 и выставить ограничение на объём памяти для рабочих процессов.