Managed Hosting: як я сам вимкнув свій сайт, поки Hostinger запевняв, що все під контролем
TL;DR — для тих, хто не хоче читати всю цю епопею
21 жовтня вийшли виправлення двох критичних вразливостей PHP. Hostinger мене про проблему не попередив, а потрібні оновлення не були доступні через панель хостингу.
Замість конкретної інформації підтримка переважно пропонувала загальні запевнення, що все під контролем. ШІ-агент навіть оновив плагін фотогалереї, який не мав стосунку до проблеми, перезаписавши мої модифікації. Зрештою мені довелося самостійно й тимчасово вимкнути сайт.
Наступного дня Hostinger оголосив про завершення встановлення виправлень і заявив, що повідомив клієнтів електронною поштою. Я такого листа не отримав. Підтримка не змогла підтвердити ані конкретну ревізію встановленого PHP-пакета, ані факт надсилання повідомлення на мою адресу.
Окрема пригода — спроби зареєструвати офіційну скаргу. Бот спочатку запевнив, що зробив це, а потім визнав, що лише записав відгук. Отримати номер звернення мені так і не вдалося.
Сайт уже працює. Але довіри до Hostinger після цієї історії стало значно менше.
Два критичні баги PHP, майже два дні листування з підтримкою, оновлений без потреби плагін і скарга, якої насправді не існувало.
21 жовтня 2026 року я дізнався про дві критичні вразливості PHP, відомі як PHP2Shell. Мій блог працює на WordPress, а отже, використовує PHP. Сайт розміщений на Hostinger. Коли в 2021 році я обирав хостинг, мене приємно вразила можливість поспілкуватися з кваліфікованим фахівцем з України, який грамотно і технічно відповідає на всі мої питання, а не якимось іноземним студентом, який підпрацьовує у службі підтримки замість особистого життя. На жаль, часи змінилися і десь між 2022 і 2024 українська служба стала недоступною, і складається таке враження, що Hostinger прагне щоб всі клієнти швидше відчепилися зі своїми запитами.
Я не системний адміністратор, хоча і сильно пов’язаний з IT. Мені подобається фотографувати, спостерігати небо, але вже точно не занурюватися в глибини серверних технологій. Саме тому я користуюся звичайним хостингом, де налаштуванням і оновленням серверного програмного забезпечення займається провайдер.
Здавалося б, якщо в PHP знаходять критичну вразливість, усе має бути досить просто: хостинг-провайдер повідомляє клієнтів, пояснює, що відбувається, встановлює виправлення й повідомляє про завершення робіт.
Натомість я витратив майже два дні на спілкування з підтримкою, самостійне дослідження проблеми та перевірку того, що саме встановлено на моєму сервері. Зрештою мені довелося тимчасово закрити власний блог для відвідувачів. І найприкріше, що головною проблемою виявилася навіть не сама вразливість.
Що сталося з PHP
21 жовтня розробники PHP випустили оновлення, які виправляють дві критичні вразливості: CVE-2026-109618 та CVE-2026-109619.
Обидві пов’язані з помилками роботи з пам’яттю. За певних умов їх використання може призвести до виконання стороннього коду на сервері, витоку інформації або порушення роботи сайту. Для WordPress це серйозна проблема. Не через якусь помилку самого WordPress, а тому, що він працює поверх PHP.
Виправлені версії були такими:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
Все, що має нижчу версію – вразливе. Мій сайт на той момент працював на одній з вразливих потенційно вразливих збірок.
Я зайшов у панель Hostinger, щоб перевірити можливість оновлення. Виправленої 8.3.36 там не було. Перемкнувся на PHP 8.4 – отримав 8.4.26. Перевірив доступну гілку PHP 8.5 – там теж була попередня версія.
Тобто скористатися новими офіційними релізами PHP я не міг.
Варто зазначити, що номер версії не завжди показує всю картину. Постачальник серверного програмного забезпечення може перенести виправлення в попередню версію PHP, не змінюючи її номера. Ця практика називається backporting.
Але 21 жовтня я ще не мав від Hostinger зрозумілого пояснення, чи зроблено це, коли буде зроблено і як я можу перевірити результат. Повідомлення про проблему від хостера я також не отримував.
Тому звернувся до підтримки.
17:05. Я запитав про PHP2Shell. Мені запропонували оновити фотогалерею
Моє перше повідомлення було коротким:
Привіт! Я чув про вразливість PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Чи існує вже виправлення? Як мені захистити свій блог?
На що ШІ-агент Hostinger відповів, що на моєму сайті встановлена застаріла версія NextGEN Gallery, і запропонував оновити її.
NextGEN Gallery – це плагін WordPress для роботи з фотографіями. Я був переконаний що двох згаданих вразливостей самого PHP він не має стосунку (і виявився правий). Але, щоб перемикнути увагу агента на основну проблему, я погодився на оновлення.
О 17:08 агент повідомив, що плагін успішно оновлено з версії 4.2.2 до 4.5.3. І тільки після цього перейшов до PHP2Shell, зазначивши, що оновлення WordPress-плагіна не усуває цю проблему. Шкода, що він не почав розмову саме з цього, а сфокусувався на бідолашному плагіні…
Чудово (ні). Отже, ми все-таки дійшли до того, з чого починали.
У мене були власні зміни, які виправляли несумісність NextGEN Gallery з іншими плагінами. Після оновлення ці зміни зникли. На деяких сторінках галерея знову перестала працювати. Так, я сам погодився на оновлення, але я це зробив, щоб швидше перейти до роботи над критичною вразливістю. На щастя, резервна копія у мене є. Відновлю правки сам, коли матиму час.
Виправлення є. А коли воно з’явиться у Hostinger?
Мені довелося шукати інформацію самостійно. О 17:09 я надіслав агенту посилання на офіційне повідомлення PHP з виправленими версіями. Після чого приблизно пів години намагався отримати відповідь на просте запитання: коли потрібні оновлення стануть доступними на моєму хостингу?
Агент рекомендував перейти на новішу гілку PHP. Я пояснював, що перехід із 8.3.35 на 8.5.11 сам по собі не означає виправлення вразливості. Мені потрібна не просто більша цифра на початку номера версії, а найсвіжіший патч.
О 17:27 я прямо попросив створити термінове звернення до підтримки, щоб питанням зайнявся хтось, хто відповідає за серверне програмне забезпечення.
О 17:28 попросив продовжити розмову з людиною. І мене запевнили, що спеціалісти Hostinger знають про критичний випуск PHP і застосовують запобіжні заходи.
В одній із відповідей було сказано:
Вам нічого робити не потрібно – посилення безпеки застосовується автоматично.
Але мене цікавило, що саме зроблено. Чи усувають ці заходи обидві вразливості? Чи лише блокують уже відомі способи атаки? Коли очікується оновлення PHP?
О 17:44 мені пояснили, що Hostinger чекає на підготовку пакетів від постачальника операційної системи.
Ось це вже була корисна інформація, і цілком зрозуміла причина затримки. Великий хостинг-провайдер не повинен без перевірки встановлювати на тисячі серверів будь-яке оновлення в ту саму хвилину, коли воно з’явилося. Але я хотів розуміти, що відбувається, які є ризики й коли ситуація зміниться. Натомість знову й знову отримував запевнення, що все гаразд.
Коли я вирішив вимкнути сайт
Паралельно я самостійно перевіряв налаштування та доступність свого хостингу.
Я використовую Cloudflare, зокрема його засоби захисту вебтрафіку. Але під час перевірок з’ясував, що покладатися лише на вже налаштовані правила Cloudflare у моїй ситуації було недостатньо. Технічні подробиці свідомо залишу за кадром. Не хочу публікувати інформацію про конфігурацію власного сервера, яка могла б комусь знадобитися не за призначенням.
Після створення резервної копії я налаштував додаткові обмеження доступу й тимчасово закрив сайт для всіх відвідувачів.
Мені не подобалося це рішення. Я веду блог для того, щоб його читали, а не для того, щоб показувати відвідувачам повідомлення про заборонений доступ. Але на той момент я не мав достатньо конкретної інформації від Hostinger, щоб упевнено залишити сайт відкритим.
Я не стверджую, що мій сервер справді був уразливий до PHP2Shell. Це залежить від конфігурації PHP та захисних механізмів хостера. Втім, я не зміг отримати достатньо інформації, щоб оцінити ризик, і вирішив перестрахуватися. А з огляду на те, що навіть солідні державні сайти Нідерландів, Німеччини, Великобританії були вимкнені, цей захід не виглядав надлишковим.
Підтримка, яка повторює сама себе
Чим далі, тим більше я був відверто роздратований.
Я пояснив агенту, що мене не повідомили про критичну проблему, я не можу самостійно встановити потрібні оновлення, а запропоноване ним оновлення фотогалереї ще й перезаписало мої модифікації.
У відповідь о 17:58 я отримав практично той самий текст, що й раніше: спеціалісти знають про проблему, запобіжні заходи застосовуються, нічого робити не потрібно. У відповідь я звернув увагу агента, що він просто повторює попередню відповідь. Цього разу бот погодився. Він прямо визнав, що попереднє повідомлення не відповідало на мої запитання й проігнорувало зауваження щодо якості підтримки.
Приємно, звичайно, що програма здатна визнавати помилки. Було б ще приємніше, якби після цього вона могла щось із ними зробити.
Скаргу зареєстровано. Або ні
Я вирішив подати формальну скаргу.
Не лише через PHP2Shell. Мене вже більше турбувала сама організація підтримки: неможливість отримати конкретні відповіді, постійні повторення загальних фраз і труднощі з передачею питання відповідальному спеціалісту.
О 19:12 я попросив агента зареєструвати скаргу.
Після чого отримав відповідь:
Дякую, скаргу зафіксовано щодо реагування на критичну PHP-вразливість і якості підтримки.
Я попросив офіційний номер справи та письмову відповідь. І тоді з’ясувалося, що ніякої офіційної справи не створено.
Агент визнав, що некоректно назвав записаний відгук офіційною скаргою. Насправді інформацію лише додали до системи відгуків – без окремого звернення й номера. Тобто формально скарга існувала рівно до того моменту, поки я не попросив її номер.
Це, мабуть, мій “улюблений” епізод усієї історії. ШІ погодився “згалюцинувати” те, що я хотів бачити, не маючи змоги зробити те, що було потрібно.
Спроба скористатися електронною поштою
Паралельно я надіслав розгорнуту скаргу електронною поштою. У ній окремо попросив, щоб звернення розглянула людина, а не автоматизований агент.
Відповідь надійшла від ШІ.
Він перевірив загальну інформацію про мій сайт, визнав, що не може підтвердити стан виправлень, і порадив продовжити розмову в чаті hPanel. Тобто через той самий канал, на роботу якого я й скаржився. На повторний лист із проханням пояснити процедуру офіційного звернення прийшла ще цікавіша відповідь:
A teammate will take a quick look and pass Hostinger Agent the guidance it needs to help you. – співробітник подивиться на ситуацію та передасть підказки ботові, щоб той міг краще мені допомогти.
Я хотів поговорити з людиною, але знову вперся у ШІ, який відфільтровував спроби прорватися до живих людей.
Згодом я таки отримав змістовнішу відповідь від представника Hostinger. Але домогтися її було значно складніше, ніж мало б бути.
Нарешті конкретика
Увечері 21 жовтня співробітниця Hostinger на ім’я Myat повідомила, що команда безпеки перевірила вразливості й не змогла відтворити їхню експлуатацію в середовищі керованого хостингу.
За її словами, компанія також застосувала додаткові механізми захисту.
Оновлені пакети PHP очікувалися від постачальника операційної системи, а розгортання планували почати приблизно о 21:00 UTC, тобто опівночі за Києвом.
Вона уточнила, що це орієнтовний час початку, а не гарантованого завершення розгортання.
Нарешті я отримав хоч якусь часову прив’язку. Але сайт усе ще залишався закритим. Я вирішив дочекатися підтвердження оновлення.
Ніч із PHP Info
Після півночі я періодично перевіряв версії PHP.
- 00:23
- 01:18
- 02:25
Оновлень не було. Я бачив ті самі старі версії. Тоді я вирішив, що на цьому годі. Цензурних слів уже не залишилося, тому пішов спати.
Вранці, розібравшись з найнагальнішими справавми о 10:16 знову спробував усе перевірити, ситуація на перший погляд не змінилася. Пізніше я знову перевірив всі гілки – номери PHP залишалися попередніми. Але саме тут історія виявилася складнішою, ніж здавалося.
Старий номер PHP не обов’язково означає старий код
Hostinger використовує пакети PHP від CloudLinux. У таких пакетах виправлення безпеки можуть переносити до попереднього випуску PHP, зберігаючи його номер. Наприклад, збірка може й далі називатися 8.3.35, але вже містити зміни, які усувають уразливість, виправлену в офіційному PHP 8.3.36.
За допомогою PHP Info та обмеженого SSH-доступу я підтвердив, що мій сайт використовує CloudLinux Alt-PHP. Дати складання PHP 8.3 та 8.4 припадали на 21 жовтня.
Згодом Hostinger пояснив, що саме так і встановлював виправлення: номер PHP міг залишитися старим, хоча необхідні зміни вже були вбудовані у збірку.
Компанія запропонувала перевіряти результат за полем Build Date у PHP Info: дата 21 жовтня 2026 року або пізніше, за її твердженням, означає наявність виправлення. Мої збірки відповідали цьому критерію.
Це стало відчутним аргументом на користь того, що PHP уже оновлено. Але сам по собі час компіляції не показує, які саме зміни включено до коду. Щоб установити це точніше, потрібна інформація про конкретний пакет та його журнал змін. На моєму shared hosting отримати ці відомості не вдалося.
Утім, вимагати від власника невеликого блогу самостійно досліджувати пакети PHP теж якось дивно. Саме тому я й плачу компанії, яка керує сервером.
Що написав Hostinger у своєму блозі
22 жовтня Hostinger оновив свій допис про PHP2Shell.
Компанія повідомила, що виправлення встановлено на всіх керованих хостингових серверах, а розгортання завершилося о 06:44 UTC, тобто о 09:44 за Києвом. Це ніби як добре, але в самій публікації мене збентежили кілька моментів.
Спочатку Hostinger пише, що після виходу PHP 8.5.12, 8.4.27, 8.3.36 та 8.2.35 ці оновлення розгорнули на платформі.
А в наступному реченні пояснює, що на керованому хостингу виправлення вбудовано в попередні версії PHP, тому номер може не змінитися.
Коли я читаю, що провайдер розгорнув PHP 8.3.36, а PHP Info показує 8.3.35, я не бачу чіткої відповіді, чи у безпеці мій сайт, чи ні.
Є в статті й рекомендація якнайшвидше оновитися до нових виправлених релізів, названих єдиним повним рішенням. Щоправда, ця інструкція адресована власникам VPS, які керують PHP самостійно. Для клієнтів managed hosting Hostinger окремо пояснює, що необхідні виправлення встановлюються автоматично.
Отже, я не буду стверджувати, що компанія радить мені зробити те, чого її панель не дозволяє. Але було б значно зрозуміліше, якби вона відразу пояснила різницю між офіційним номером PHP та виправленою збіркою CloudLinux, особливо під час критичного інциденту.
А де обіцяний лист?
Тут виникло ще одне запитання. У своїй публікації Hostinger прямо повідомляє, що після завершення розгортання клієнтам надіслали електронні листи.
Я такого листа не отримав. Не отримав і попереднього повідомлення про критичні вразливості. При цьому інші листи від Hostinger нормально надходили. Зокрема, повідомлення щодо підтримки та прохання оцінити спілкування. Я перевірив пошту, включно з архівом і спамом. Повідомлення про PHP2Shell не знайшов.
Зрозуміло, що це не доводить, ніби Hostinger взагалі нічого нікому не надсилав. Я можу говорити лише про власну поштову скриньку. Але якщо компанія публічно заявляє, що повідомила клієнтів, а я як клієнт повідомлення не отримав, мені хочеться дізнатися, чи його справді надіслали на мою адресу. І я спробував це з’ясувати.
Два запитання, на які підтримка так і не відповіла
22 жовтня я знову звернувся в чат. Цього разу не просив перевіряти сайт, оновлювати плагіни чи давати загальні рекомендації. Поставив лише два запитання:
Перше: яка саме ревізія пакета CloudLinux Alt-PHP встановлена на моєму сервері та чи можна отримати відповідні записи журналу змін, що підтверджують виправлення обох CVE?
Друге: чи було надіслано мені обіцяний лист про PHP2Shell? Якщо так – коли та з яким статусом доставки?
Я окремо наголосив, що не дозволяю нічого змінювати на сайті. Мені потрібна тільки інформація. І тут агент Hostinger нарешті відповів досить чесно.
Він підтвердив, що доступні йому дані не містять ідентифікатора встановленого RPM-пакета, журналу його змін чи записів про доставку електронного листа. Також визнав, що дата складання відповідає критерію Hostinger, але не є незалежним підтвердженням конкретного пакета та виправлень.
Отже, обидва мої запитання залишилися без відповіді. Я попросив передати їх технічному спеціалісту та надати номер звернення.
Відповідь була короткою:
I cannot provide a trackable reference because no numbered support case was created in this chat.
“Я не можу надати посилання для відстеження, оскільки в цьому чаті не було створено пронумерованого звернення до служби підтримки.”
Знову.
Під час усієї цієї історії я так і не зміг отримати відстежуване звернення, хоча просив про це неодноразово – і в чаті, і електронною поштою. Не знаю, як саме організована внутрішня система заявок Hostinger. Можливо, там є прекрасна тікетна система з усіма можливими функціями. Але мені дістатися до неї не вдалося. Всі мої звернення оброблялися так, щоб якомога швидше “відшити” мене.
Пізніше представник компанії на ім’я Justin ще раз підтвердив, що виправлення встановлено на всіх керованих серверах, а перевіряти їх потрібно за датою складання PHP. Це ніби як підтверджувало офіційну позицію Hostinger, але конкретної ревізії пакета я так і не отримав. Як і відповіді на запитання про лист.
Чому відсутність повідомлень мене особливо роздратувала
Проблема не в тому, що Hostinger узагалі не вміє надсилати повідомлення клієнтам. Уміє. І іноді робить це.
Наприклад, раніше я отримував листи про заплановані технічні роботи. У них зазначали, коли почнеться обслуговування, скільки триватиме та які сайти може зачепити.
Також я отримував повідомлення про автоматичне ввімкнення Hostinger CDN.
CDN – це мережа доставки контенту, яка може прискорювати роботу сайту. Корисна річ, коли вона правильно налаштована. Але мій сайт уже використовував Cloudflare. Мені не потрібне було автоматичне ввімкнення ще одного CDN без мого окремого рішення. Повідомлення передбачало, що CDN увімкнуть за замовчуванням, якщо я не відмовлюся. Я пропустив цей лист.
Після того в мене виникли проблеми з доступністю сайту, які тривали кілька днів.
Я не можу достеменно стверджувати, що причиною був саме Hostinger CDN. Не виключаю інших пояснень або поєднання кількох чинників. Але сам підхід мені не подобається: якщо я не просив змінювати мережеву конфігурацію сайту, така зміна не повинна відбуватися лише тому, що я не помітив листа.
Це одна з причин, чому моя довіра до Hostinger почала зменшуватися ще до PHP2Shell.
І тепер маємо дивний контраст. Про заплановане обслуговування компанія вміє попереджати. Про автоматичне ввімкнення CDN – теж. А про критичні вразливості PHP я дізнався сам. І повідомлення про завершення встановлення виправлень, яке Hostinger стверджує, що надсилав клієнтам, до мене також не дійшло. Якщо компанія знала про проблему й готувала виправлення, чому я дізнався про неї не від компанії, якій плачу за обслуговування сервера?
Чи був Hostinger насправді вразливим?
Hostinger стверджує, що його команда безпеки перевірила проблему й не змогла відтворити експлуатацію PHP2Shell у керованому хостинговому середовищі. За словами компанії, додаткові правила захисту блокували відомі спроби атак ще до встановлення виправлень. Це звучало досить дивно, але я не мав повної інформації щоб спростувати (чи підтвердити) це.
Згодом Hostinger повідомив про завершення розгортання виправлених збірок PHP.
Мої перевірки підтвердили використання CloudLinux Alt-PHP та дати складання, які відповідають критерію компанії. Це дає підстави вважати, що необхідні виправлення справді могли бути встановлені, навіть попри незмінний номер PHP.
Але я не зміг перевірити конкретну ревізію встановленого пакета. Тому я не стверджуватиму ні того, що Hostinger залишався вразливим, ні того, що його захисні механізми були неефективними.
Головна моя претензія полягає в тому, що у випадку критичного інциденту мені було складно отримати інформацію, достатню для ухвалення рішення щодо власного сайту. І саме це зрештою змусило мене тимчасово його закрити.
Чим усе закінчилося
22 жовтня я відновив публічний доступ до блогу. На той момент Hostinger уже офіційно повідомив про завершення розгортання виправлень, пояснив використання backport у CloudLinux, а моя збірка PHP відповідала запропонованому компанією критерію перевірки.
Я вирішив, що цих підстав достатньо для відновлення роботи сайту. Сайт працює нормально. Залишилося відновити кілька модифікацій NextGEN Gallery, які було втрачено після оновлення плагіна на початку всієї цієї історії.
Але головне питання для мене тепер навіть не в PHP.
Я розумію, що програмне забезпечення має вразливості. Розумію, що виправлення потребують часу. Розумію, що жоден хостинг-провайдер не може гарантувати абсолютного захисту від усіх можливих атак. Я також не очікую, що кожен оператор першої лінії підтримки матиме доступ до системних журналів або зможе пояснити всі подробиці складного інциденту.
Але я очікую, що в разі серйозної проблеми компанія повідомить мене про неї, пояснить свої дії та дасть можливість поставити запитання людині, яка має відповідну інформацію.
Якщо перша лінія підтримки не може відповісти, має бути зрозумілий спосіб передати питання далі.
У моєму випадку цей процес не спрацював. І я набув цінного досвіду, кілька довгих стенограм спілкування з ботом, а моє бажання продовжувати співпрацю з Hostinger сильно зменшилося. Я не можу оцінити роботу саме технічної команди, але як клієнт я бачив автоматичні відповіді, повторення загальних запевнень, неможливість отримати номер звернення та необхідність самостійно з’ясовувати, чи можна відкривати власний блог.
До речі, за весь цей час я так і не отримав листа про PHP2Shell.
Зате лист із проханням оцінити роботу підтримки прийшов.
Джерела та примітки
Статтю написано на основі мого листування зі службою підтримки Hostinger 21–22 жовтня 2026 року, власних перевірок стану хостингу й опублікованих компанією повідомлень.
Основні публічні джерела:
- Офіційний архів релізів PHP за жовтень 2026 року.
- Стаття Hostinger Hostinger deploys protections against php2shell PHP vulnerabilities.
- Сторінка статусу Hostinger PHP Security Update for Web, Agency and cPanel Hosting.
Час у тексті – київський літній (UTC+3).
Технічні відомості, які можуть розкривати конфігурацію мого сервера, свідомо не публікую. Повні оригінали листування та результати перевірок збережені в особистому архіві.
Створення допису було розпочато 22 жовтня, тому він не стосується вразливості CVE-2026-115560, про яку Hostinger написали у себе 23 жовтня.
