# Времевият прозорец между пач и атака

> Времевият прозорец между пач и атака, обяснен: фазите при PHP2Shell, как да измерите собствения си прозорец и с кои стъпки да го съкратите.

Източник: https://phpsos.de/bg/blog/zeitfenster-patch-angriff/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Времевият прозорец между пач и атака при PHP2Shell беше отрицателен: според медийни съобщения имаше първи опит за атака още на 17 октомври 2026 г., четири дни преди актуализациите. За операторите затова не въпросът „Колко време остава?“ е важен, а „Докога е отворен моят сървър?“. Този личен прозорец свършва едва когато актуализацията е инсталирана и всички PHP процеси са рестартирани.

## Поводът: атаки преди пача

Дълго важеше едно удобно допускане: между актуализацията за сигурност и първите атаки минават няколко дни, достатъчно за следващия прозорец за поддръжка. PHP2Shell опроверга това допускане. Според медийни съобщения, които се позовават на Amazon, първи опит за атака е наблюдаван още на 17 октомври. Cloudflare също съобщи за ранни атаки. Пачовете дойдоха на 21 октомври в 14:00 UTC.

Тази статия обяснява как възникват такива времеви прозорци и как да съкратите Вашия. Точната последователност на датите ще намерите в [хронологията на PHP2Shell](https://phpsos.de/bg/ratgeber/php2shell-chronologie/).

## Времевият прозорец между пач и атака по фази

Около една уязвимост могат да се разграничат няколко фази. При PHP2Shell те изглеждаха така:

| Фаза | Общо | При PHP2Shell |
|---|---|---|
| Преди да стане известна | уязвимостта е известна само на откривателите и на производителя | разработка на поправката под ембарго |
| Първи атаки без пач | нападателите ползват уязвимостта, преди да има актуализация | според медийни съобщения първи опит на 17.10. |
| Предварително известие | производителят обявява актуализация | 20.10., php.net обявява изданието |
| Пач наличен | излизат актуализацията и съобщението за сигурност | 21.10., 14:00 UTC |
| Анализ на пача | изследователи и нападатели анализират промените | watchTowr според собствените си данни е възпроизвела CVE-2026-109618 |
| Масова експлоатация | автоматизирани кампании срещу непачнати сървъри | очаквана от BSI; потвърдени успешни атаки в голям мащаб първоначално не са известни |
| Вашият пач | актуализация и рестарт на Вашите сървъри | индивидуално |

Последният ред е единственият, който можете да повлиявате. Всичко преди него определят други.

## Защо самият пач увеличава натиска

Актуализацията за сигурност затваря уязвимостта, но едновременно я прави видима. Промените в изходния код при проекти с отворен код като PHP са публични. Който сравнява разликите между старата и новата версия, научава на кое място е била грешката. Това не е упрек към PHP проекта, а нормалният случай при отворен софтуер и основата дистрибуциите да могат да изграждат backport-ове.

За операторите от това следва: с всеки ден след пача расте броят на онези, които знаят как работи уязвимостта. В същото време намалява броят на непачнатите сървъри. Останалите стават така очевидните цели. Как PHP доставя актуализации за сигурност в рамките на поддръжката на версиите си, обяснява статията за [цикъла на издания на PHP](https://phpsos.de/bg/php/release-zyklus/).

> **Действайте веднага:**
> Ако Вашият сървър е бил достъпен между 17 октомври и Вашия пач, проверката за следи е задължителна. Запазете логовете от 20 октомври, преди да бъдат загубени чрез ротация.

## Измерете собствения си времеви прозорец

Вашият личен времеви прозорец започва най-късно с публикуването на пачовете и свършва с рестарта на последния PHP процес. Запишете за всеки сървър:

- **Узнаване:** Кога някой във фирмата е научил за уязвимостта?
- **Наличност:** Кога пакетът на Вашата дистрибуция или на хостинг доставчика е бил наличен?
- **Инсталиране:** Кога е бил инсталиран?
- **Рестарт:** Кога вече не са работили стари PHP процеси?

Именно рестартът често се забравя. Инсталираната актуализация действа едва когато старите процеси са спрени. Как да проверите това, описва [Рестартиране на PHP-FPM и на всички PHP процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/). Дали още работят процеси отпреди актуализацията, показва поглед към времената на стартиране:

```bash
# Показване на времето на стартиране на всички PHP процеси
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
```

Ако времето на стартиране е преди инсталирането на актуализацията, прозорецът още е отворен.

### Защо Вашият прозорец зависи от пътя на доставка

Колко бързо можете да пачнете, не зависи само от Вас, а и от това откъде идва Вашият PHP. Дистрибуциите според съобщенията на места са доставили backport-ове още на 21 октомври. Който получава PHP от хранилище на трета страна, зависи от неговото темпо. Който ползва контейнери, трябва да изгради наново и да разгърне образите, обикновена актуализация в работещия контейнер не стига. А при споделения хостинг моментът го определя хостинг доставчикът.

Когато познавате пътя на доставка на всеки сървър, знаете и къде Вашият прозорец остава най-дълго отворен. Именно там подготовката си струва най-много, например чрез договорка с хостинг доставчика или изпробван процес за нови контейнерни образи.

## Как да съкратите времевия прозорец следващия път

1. **Абонирайте се за съобщения:** Получавайте съобщенията за сигурност на php.net и на Вашата дистрибуция директно, не едва чрез пресата.
2. **Определете отговорността:** За всеки сървър отговорно лице със заместник.
3. **Ползвайте автоматика, където е подходяща:** Актуализациите за сигурност от дистрибуцията могат да се инсталират автоматично. Какво говори за и какво против, описва [Автоматични актуализации за сигурност](https://phpsos.de/bg/blog/automatische-sicherheitsupdates/).
4. **Планирайте рестарта:** Рестартът на PHP услугите е твърда част от процеса, не от последващата работа.
5. **Подгответе авариен път:** Страница за извънредни случаи и решение за временно изключване, ако актуализация не е възможна веднага.
6. **Водете доказателство:** Документирайте моментите на инсталиране и рестарт, за да можете по-късно да докажете своя прозорец.

Траен процес, който обединява тези точки, е описан в статията за [процеса на управление на пачовете](https://phpsos.de/bg/blog/patch-management-prozess/).

## Как помага PHP SOS конкретно?

- **Пач и рестарт:** Инсталираме актуализацията и осигуряваме, че вече не работят стари PHP процеси.
- **Доказване на прозореца:** Документираме инсталирането и рестарта за всеки сървър с момент.
- **Проверка за следи:** За времето, в което Вашият сървър е бил отворен, запазваме логове и проверяваме за необичайни находки.
- **Процес за бъдещето:** Изграждаме с Вас пътища за съобщаване, отговорности и процеси за актуализация.

Повече на [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/).

## Заключение

При PHP2Shell нямаше гратисен период. Времевият прозорец между пач и атака при критични уязвимости днес често е нула или дори отрицателен. Каквото можете да управлявате, е Вашият собствен прозорец: той свършва с рестарта и с подготовка може да се съкрати от дни на часове.


## Често задавани въпроси

**Колко време остава след актуализация за сигурност до атаките?**  
Фиксиран срок няма. При PHP2Shell според медийни съобщения първи опит за атака е наблюдаван още на 17 октомври, тоест четири дни преди пачовете. При критични уязвимости в разпространен софтуер приемайте, че практически няма гратисен период.

**Какво е Zero-Day?**  
Уязвимост, която се атакува, преди да има налична актуализация. Производителят е имал, така да се каже, нула дни, за да я поправи. След това често се говори за позната или N-Day уязвимост, за която вече има пач.

**Защо атаките след пача често стават по-чести?**  
С пача става публично известно на кое място е била грешката. Изследователите на сигурността и нападателите могат да анализират промените. В същото време много сървъри остават непачнати още дни или седмици и така са изгодни цели.

**Кога сървърът ми е наистина защитен?**  
Когато актуализацията е инсталирана и всички PHP процеси са рестартирани. Новите файлове сами не действат, докато в паметта работят стари процеси. Краят на Вашия личен времеви прозорец е следователно рестартът, не изтеглянето.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)