Ми офіційно без PHP. Ось чого нас (поки що) навчив жовтень

Тиждень з 19 по 24 жовтня 2026 року, з понеділка по суботу, приніс цілу низку серйозних новин безпеки в усій галузі. Якщо ви це пропустили, наш огляд того тижня містить подробиці. Коротка версія: у кількох випадках зловмисники діяли швидше за виправлення.

Такий тиждень не змушує нас починати з чистого аркуша, але він загострює лінії, які вже на ньому накреслені. Одна справа триматися принципу, і зовсім інша спостерігати, випадок за випадком, що стається там, де цього принципу бракує. Тож замість переліку технічних кроків ми хочемо пояснити принципи, за якими працюємо, адже для вас як клієнта підхід важить більше, ніж будь-яке окреме оновлення. Один із цих принципів щойно досяг своєї віхи: тепер ми офіційно без PHP.

Чому латання постфактум є програшною гонитвою?

Роками стандартна порада була простою: латайте швидко, і все буде гаразд. Тенденція вже тоді працювала проти цієї поради. Команда Mandiant від Google виміряла середній час між тим, як вразливість стає відомою, та її експлуатацією: 63 дні у 2018-2019 роках, 32 дні протягом 2021 та 2022 років і п'ять днів у 2023 році, у середньому, без урахування аномальних значень.

П'ять днів: це показник 2023 року, ще до того, як інструменти ШІ стали частиною повсякденної роботи з програмним забезпеченням. Цей місяць дав нам свіжий вимір гонитви, зроблений із трьох різних точок огляду навколо розкриття PHP2Shell 21 жовтня 2026 року.

Команда розвідки загроз Amazon зафіксувала спробу експлуатації PHP2Shell 17 жовтня, за чотири дні до публічного розкриття, і повідомляє, що щойно ембарго зняли та випустили патч, нові демонстраційні експлойти з'явилися протягом кількох годин. F5 Labs побачила перше сканування на PHP2Shell більш ніж за п'ять годин до публікації двох CVE, а протягом кількох годин після розкриття її сенсори фіксували тисячі спроб експлуатації. Генеральний директор Cloudflare Matthew Prince заявив 22 жовтня, що Cloudflare бачила тисячі спроб ще до оголошення, десятки тисяч за 45 хвилин після нього, сотні тисяч протягом двох годин і мільйони на момент його допису. Це були спроби, а не підтверджені зломи, але вони показують, як швидко смикали двері: вікно тепер вимірюється хвилинами й годинами, а для декого воно зачинилося ще до того, як патч узагалі з'явився.

Експлуатація до появи будь-якого виправлення теж не рідкість. У 2023 році 70% експлуатованих вразливостей, які відстежувала Mandiant, 97 зі 138, були використані як уразливості нульового дня, тобто ще до того, як існувало хоч якесь виправлення.

Якщо експлуатація може початися до того, як патч стане доступним, і прибувати масово вже за лічені хвилини після його виходу, то латання, хоч би яким дисциплінованим воно було, не може бути всім планом. Захисник, який покладається лише на нього, вступив у гонитву, яка часто вирішена ще до старту. Тож ми припускаємо, що гонитву іноді буде програно, і проєктуємо з розрахунком на програш. Це припущення перетворюється на три питання. Поки вразливість відкрита, яку частину наших систем можна вразити? Якщо щось вражено, скільки можна втратити? І щойно виправлення з'явиться, як швидко ми можемо відновитися та закрити прогалину? Кожен наш принцип відповідає на одне з цих питань, і все нижче впорядковано навколо них.

Чому ми видаляємо програмне забезпечення, а не латаємо навколо нього?

Почнімо з першого питання: скільки можна вразити. Кожна організація накопичує програмне забезпечення, яке погано постаріло: інструменти, чиї розробники пішли далі, компоненти, що застрягли на старих версіях, бо від них залежить щось інше, код, якого ніхто не хоче торкатися. Звична реакція: обгорнути таке програмне забезпечення обхідними рішеннями та правилами фаєрвола і сподіватися на краще.

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

Чому обхідні рішення зазнають невдачі? Бо обхідне рішення блокує лише ті вразливості, які вже відомі. Непідтримуване програмне забезпечення не перестає мати слабкі місця в день, коли його розробники йдуть. Дослідники та зловмисники рік за роком знаходять нові, а писати виправлення вже нікому. Кожне відкриття змушує додати ще одне правило, ще один фільтр, ще один шар поверх попереднього, і ця купа стає дедалі крихкішою з кожним доповненням. Рано чи пізно з'являється вразливість, яку жоден зовнішній шар не може відсіяти, або два шари заважають один одному, і захист тихо здається. Обхідне рішення купує час, а на покинутому коді цей час немає на що корисне витратити, бо глибинну проблему ніхто ніколи не виправить.

Згадайте гонитву вище, яка тепер триває хвилини й години. Проти підтримуваного програмного забезпечення ця гонитва жорстоко коротка, але її принаймні можна бігти. Проти покинутого програмного забезпечення гонитви немає взагалі, бо виправлення, яке мало б її завершити, ніколи не прибуде. На папері це звучить очевидно. На практиці це важчий шлях, адже видалити щось зазвичай означає перебудувати те, що на нього спиралося. Ми вважаємо, що ця ціна того варта. Зловмисник не може використати слабке місце в системі, якої більше не існує.

Як насправді виглядає мала поверхня атаки?

Видалення є найпрямолінійнішим способом зменшити те, що можна вразити. Ширша звичка, що стоїть за ним, має технічну назву: тримати поверхню атаки малою. Поверхня атаки, попри термін, ідея проста: сума всіх місць, де зловмисник міг би спробувати ключ у замку. Кожен відкритий сервіс, кожна стороння бібліотека, кожен плагін додає ще один замок, який треба боронити. Наше визначення хорошої безпеки починається саме тут: найсильніший код той, якого ви не запускаєте, а найбезпечніші дані ті, яких ви ніколи не зберігали.

Замисліться, чим насправді є стороння бібліотека чи плагін. Коли розробник підключає її, він довіряє незнайомцеві, часто неоплачуваному волонтеру, підтримувати безпеку цього коду стільки, скільки той працює. Бібліотеці потрібні власні оновлення, власні виправлення безпеки, власний супровідник, який пильнує. Якщо цей супровідник втратить інтерес, змінить роботу чи просто перестане відповідати, код продовжить працювати, але за ним уже ніхто не стежитиме. Вразливість, знайдена після цього, лишається відкритою назавжди, і це та сама проблема покинутого коду з попереднього розділу, що заходить через бічні двері. Помножте це на безліч компонентів, від яких залежить типовий застосунок, і картина стане зрозумілою. Кожна залежність є маленькою обіцянкою людини, якої ви ніколи не зустрічали, і деякі з цих обіцянок тихо спливають. Що менше їх у вас працює, то меншій кількості незнайомців ви завдячуєте своєю безпекою.

Системи, у які ви входите, через які платите і з якими спілкуються наші застосунки, написані мовою Go. PHP зник, а разом із ним і довгий хвіст бібліотек, плагінів та залежностей, які застосунки на PHP зазвичай тягнуть за собою.

Ми обрали Go для найкритичніших систем, бо він відповідає на проблему залежностей на рівні самої мови. Go безпечний щодо пам'яті: мова керує пам'яттю замість програміста, що виключає цілий клас помилок, як-от переповнення буфера, і CISA (агентство кібербезпеки США) включає Go до переліку безпечних щодо пам'яті мов у документі The Case for Memory Safe Roadmaps. Цей клас більший, ніж здається: проєкт Chromium виявив, що близько 70% його серйозних помилок безпеки є проблемами безпеки пам'яті. Стандартна бібліотека Go покриває більшу частину потреб вебсервісу, включно з криптографією, тож сервісу на Go потрібно менше сторонніх пакетів, а отже, менше тих обіцянок від незнайомців. До криптографії там ставляться настільки серйозно, що власний криптографічний модуль Go пройшов валідацію за стандартом уряду США FIPS 140-3, сертифікат CMVP #5247. А коли вразливість усе ж з'являється в ширшій екосистемі, команда безпеки Go веде базу даних вразливостей, і її інструмент govulncheck повідомляє лише про вразливості в коді, який програма справді викликає, завдяки чому сповіщення лишаються нешумними та практичними.

Це важливо через те, наскільки поширеними та наскільки старими є розгортання PHP. За даними W3Techs, PHP використовують 69,2% усіх сайтів, чия серверна мова їй відома, причому 26,6% сайтів на PHP досі працюють на PHP 7, а 7,7% на PHP 5, станом на 27 жовтня 2026 року. Сам проєкт PHP підтримує кожну гілку випуску два роки виправленнями помилок і безпеки, а потім ще два роки лише критичними виправленнями безпеки. PHP 7 і PHP 5 уже поза всім цим. Велика частка вебу працює на коді, який його власні творці більше не захищають, і це та сама програшна гонитва з першого розділу, у яку вступили добровільно.

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

Які дані про вас ми зберігаємо?

Мала поверхня обмежує те, як зловмисник міг би потрапити всередину. Друге питання стосується того, що він знайшов би, якби одного дня хтось із них усе ж таки проник. Наша відповідь: зробити знахідку якомога нуднішою, тобто менше даних, які зберігаються менше часу.

Ми просимо лише те, що потрібно для роботи облікового запису. Наша політика конфіденційності (англійською) перелічує це прямо: ім'я користувача, адреса електронної пошти, зашифрований пароль та IP-адреса, використана під час реєстрації. Платежі проходять через сторонні платіжні сервіси, тож дані вашої картки зберігаються у фахівців, увесь бізнес яких полягає в їхньому захисті, а не в нас.

Ми також посилюємо те, що відбувається з часом. Старі невикористовувані облікові записи видалятимуться автоматично. Дані, яких не існує, не можуть витекти, не можуть бути викрадені й не можуть бути витребувані. Обліковий запис, який ви покинули роки тому, не повинен лежати як ризик із вашим ім'ям на ньому. Якщо гонитву колись буде програно на нашому боці огорожі, приз на столі має бути таким малим, яким ми тільки можемо його зробити.

Та сама логіка діє й за нашими межами, бо інші компанії теж програють гонитви. Багато витоків, від яких страждають люди, стаються в магазинах, на форумах і в сервісах, де вони зареєструвалися давним-давно. Саме тому ми пропонуємо сповіщення про витоки даних: наш Data Breach Scanner перевіряє відомі витоки даних на наявність вашої електронної адреси та надсилає вам листа, якщо вона там з'явиться, щоб ви могли змінити паролі, перш ніж витоком зловживуть.

Що станеться, якщо щось усе-таки зламається?

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

Наші системи побудовані так, що їх можна відтворити або перенести в інше місце за потреби. Для вас це означає, що збій або локація, яка більше не відповідає нашим стандартам, не мусить перетворюватися на тривалий простій, адже уражену систему можна перебудувати або перенести. Якщо ми колись дійдемо висновку, що середовище більше не є достатньо добрим, ми можемо його покинути, а не домовлятися з ним.

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

Як швидко виправлення досягають наших систем?

Друга половина третього питання стосується швидкості. Ніщо з наведеного вище не скасовує потреби латати; воно змінює те, що саме латання має на собі нести. З малою поверхнею та актуальним програмним забезпеченням встановлення виправлення є рутиною, а не окремим проєктом.

Наше правило просте: оновлення виходять, щойно з'являються виправлення. Жовтневі виміри пояснюють чому. Коли спроби експлуатації прибувають за лічені хвилини й години після публікації виправлення, а іноді ще до його появи, виправлення, що лежить і чекає, нікого не захищає. Випущений патч ми сприймаємо як стартовий постріл. Відрізок між появою виправлення та його встановленням є єдиною частиною гонитви, яку захисник контролює повністю, тож саме її ми відмовляємося здавати.

А оскільки наш стек малий, латати просто менше, і саме тут три питання сходяться: що менше можна вразити, то швидше закривається прогалина.

Поставлені поруч, питання та принципи, які на них відповідають, виглядають так:

Що все це означає для вас?

Це означає, що три питання мають відповіді, які можна відчути. Між вами та вашим обліковим записом стоїть менше коду, тож існує менше місць, де щось може піти не так. Ваших даних існує менше, тож навіть найгірший випадок розкриє небагато. А наші системи можна перебудувати, тож поганий день для нас не мусить ставати тривалим простоєм для вас.

Будемо чесними щодо межі всього цього. Гонитву, з якої ми почали, неможливо надійно вигравати, ні нам, ні будь-кому, бо вразливості іноді експлуатуються ще до того, як хтось дізнається про їхнє існування, і жодна архітектура цього не змінює. Жоден провайдер не може обіцяти нульовий ризик, а той, хто обіцяє, продає впевненість, а не безпеку. Що ми можемо обіцяти, так це форму втрати: мало шляхів усередину, мало що можна забрати і швидкий шлях назад. Ми не можемо гарантувати, що виграємо кожен раунд гонитви. Ми збудували все так, щоб програш одного раунду коштував вам якомога менше, і вважаємо, що така обіцянка, виконувана послідовно, варта більше, ніж гучна, якої виконати неможливо.

Безпека є також спільною справою. Навіть найсильніша конфігурація, яку ми можемо збудувати, виграє від хороших звичок з вашого боку, тож якщо вам потрібні практичні кроки, почніть із нашого посібника про те, як підвищити свою безпеку в інтернеті (англійською). А якщо ви обираєте VPN, у нас чи в будь-кого іншого, питайте провайдера, як він мислить, а не лише що він продає. Відповідь багато скаже про те, якими будуть ваші тихі тижні, та й гучні теж.