# Po PHP2Shell: zakaj so nadaljnja obvestila verjetna

> Po PHP2Shell so nadaljnja obvestila o PHP verjetna. Po čem to prepoznate, katere vire spremljati in kako se vaša ekipa pripravljena odzove.

Vir: https://phpsos.de/sl/blog/weitere-php-meldungen/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Po PHP2Shell so nadaljnja obvestila o PHP verjetna, ker je že dva dni po popravku prišlo tretje obvestilo, popolno obvestilo (advisory) še manjka, distribucije pa svoje pakete dostavljajo postopoma. Kdor zdaj vzpostavi trden potek za opazovanje, ocenjevanje, posodobitev in ponovni zagon, se na naslednjo novo varnostno ranljivost PHP odzove v urah namesto v dneh.

## Popravek ni bil konec zgodbe

21. oktobra 2026 je projekt PHP zaprl obe kritični ranljivosti CVE-2026-109618 in CVE-2026-109619 z različicami 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Mnogi odgovorni so potem postavili kljukico. Dva dni pozneje, 23. oktobra, pa je sledilo še eno obvestilo php.net o CVE-2026-115560.

To tretje obvestilo zadeva samo nenavadno konfiguracijo sej. Kaže pa vzorec, ki ga poznamo iz velikih varnostnih primerov: ko komponenta nenadoma stopi v središče pozornosti, se mnogi strokovnjaki hkrati natančneje ozrejo vanjo. Ali bodo iz tega nastale nadaljnje ranljivosti, danes ne ve nihče. Verjetno pa je, da novic ne bo zmanjkalo.

Za vas kot upravljavca to pomeni: računajte z nadaljnjimi obvestili, namesto da vas vsako preseneti. Dosedanji potek dogodkov povzema naša [kronologija PHP2Shell](https://phpsos.de/sl/ratgeber/php2shell-chronologie/).

## Zakaj so nadaljnja obvestila verjetna

Naslednja ocena temelji na javno znanih dejstvih. Ni napoved konkretnih ranljivosti.

1. **Advisory še manjka.** php.net CVE-2026-115560 obravnava v rednem ciklu izdaj in je napovedal, da bo popolni advisory objavil ob naslednji izdaji. Do takrat kot pomoč velja `session.upload_progress.enabled=0`.
2. **Podrobnosti so bile javne zgodaj.** Po več poročilih so podrobnosti postale znane pred iztekom embarga. Po poročilih je watchTowr CVE-2026-109618 po lastnih navedbah poustvaril. Taka dela pogosto vodijo do nadaljnjih vprašanj na sosednjih mestih kode.
3. **Distribucije dobavljajo postopoma.** Ubuntu je 21. oktobra z USN-8948-1 oskrbel aktualne izdaje in z USN-8948-2 prek Ubuntu Pro dodatno dostavil popravke za 14.04 do 20.04. Red Hat je v svojem biltenu zapisal, da so nekatere posodobitve na voljo, druge so v delu.
4. **Razvojna različica je prizadeta.** Po php.net popravke vsebuje tudi PHP 8.6.0 RC4. Kdor preizkuša predizdaje, mora ta okolja prav tako posodobiti.
5. **Stare različice ostanejo odprte.** Za PHP 8.1 in starejše obstajajo samo minimalni backporti izvorne kode. Vsak ponudnik, ki take različice dobavlja, svoje stanje javlja samostojno in ob lastnih časih.

## Kako do vas pride nova varnostna ranljivost PHP

Obvestila prihajajo po različnih poteh in z različno zanesljivostjo. Vrstni red je skoraj vedno enak: najprej projekt PHP, nato distribucije in ponudniki gostovanja, potem uradi in mediji.

| Vir | Kaj tam izveste | Kako zanesljivo |
|---|---|---|
| php.net | Prizadete veje, odpravljene različice, prehodni ukrepi | Primarni vir |
| Ubuntu, Debian, Red Hat | Stanje paketov po izdajah, čas dostave | Primarni vir za vaš sistem |
| Ponudniki gostovanja in panelov | Stanje lastnih gradenj PHP | Zavezujoče le, če pisno |
| BSI, CERT-Bund | Ocena položaja, opozorilna stopnja, priporočila | Uradna uvrstitev |
| Strokovni tisk in varnostna podjetja | Opazovanja napadov, števila, ozadje | Koristno, označiti kot poročilo |

Pomembna je razlika med „obstaja popravek“ in „moj sistem ima popravek“. Prvo trditev najdete na php.net. Drugo morate za vsak strežnik dokazati sami.

> **Nasvet:**
> Naročite se na obvestila php.net in svoje distribucije prek RSS ali poštnega seznama in jih preusmerite v skupni nabiralnik ali kanal, ki ga bere več kot ena oseba. Dopust in bolezen sta najpogostejša razloga za zamujene posodobitve.

## Kaj pripraviti pred naslednjim obvestilom

Izkušnja iz PHP2Shell kaže, kje se izgublja čas: pri iskanju strežnikov, razjasnjevanju odgovornosti in pozabljenem ponovnem zagonu. Vse to je mogoče urediti vnaprej.

- **Popis:** Seznam vseh strežnikov in spletnih strani z vejo PHP, načinom delovanja (PHP-FPM, mod_php, LiteSpeed) in virom paketov. Brez tega seznama se vsako obvestilo začne z iskanjem. Kako to uspe, opisuje prispevek [Popis vseh spletnih strani in strežnikov](https://phpsos.de/sl/blog/inventar-websites-server/).
- **Odgovornost:** Za vsak sistem je določeno, kdo posodobi, kdo znova zažene in kdo odobri. Pri ponudnikih gostovanja in agencijah to sodi v pogodbo.
- **Okvir ocenjevanja:** Za prvo uvrstitev zadoščajo tri vprašanja. Ali je naša veja prizadeta? Ali uporabljamo prizadeto funkcijo ali način delovanja? Ali obstaja popravek ali samo prehodni ukrepi?
- **Pot preizkusa:** Staging okolje, v katerem je mogoče posodobitev PHP v kratkem času preveriti.
- **Dokazilo:** Fiksna oblika, v kateri se zabeležijo stanje paketa, zadetek v changelogu in čas ponovnega zagona.

Kako tak potek deluje kot rutina in ne kot gasilska akcija, je opisano pod [Upravljanje popravkov kot proces](https://phpsos.de/sl/blog/patch-management-prozess/). Ozadje o ravnanju projekta PHP z ranljivostmi ponuja stran [Kako projekt PHP obravnava varnostne ranljivosti](https://phpsos.de/sl/php/php-sicherheitsprozess/).

## Lastna konfiguracija kot sistem zgodnjega opozarjanja

Del nadaljnjih obvestil zadeva samo določene nastavitve. CVE-2026-115560 je za to primer: php.net kot pogoj navaja, da aplikacija med delovanjem preklopi serializer sej, medtem ko je upload progress aktiven. Aplikacije, ki tega nikoli ne storijo, po php.net niso prizadete.

Kdor pozna svojo veljavno konfiguracijo, lahko taka obvestila hitreje uvrsti. Zato za vsako vejo zabeležite, katere vrednosti so nastavljene na strežniku in katere aplikacije jih smejo prepisati. Že preprosta primerjava aktivnih nastavitev pomaga:

```bash
# Veljavne vrednosti ukazne vrstice (spletna konfiguracija se lahko razlikuje)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"

# Nastavljene vrednosti v poolih FPM (pot se po distribuciji razlikuje)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
```

Ukazna vrstica ne kaže nujno, kaj velja v spletnem kontekstu. Jasnost prinesejo konfiguracija poola ali VirtualHost in, za kratek čas in zaščiteno, stran phpinfo.

Še ena prednost: kdor ve, katere prehodne vrednosti so še nastavljene iz tedna PHP2Shell, jih lahko po naslednji redni izdaji zavestno preveri. Nekatere nastavitve, na primer izklopljen upload progress, lahko ostanejo trajno smiselne. Druge, kot so zelo ozke meje nalaganja, po posvetu s strokovnimi oddelki spet prilagodite dejanski potrebi.

## Kako konkretno pomaga PHP SOS?

- Spremljamo obvestila php.net, distribucij in BSI ter nova opozorila ovrednotimo za vaše konkretne sisteme.
- Z vami izdelamo popis vseh namestitev PHP in določimo odgovornosti za vsak strežnik.
- V okviru [varnostne pogodbe o vzdrževanju](https://phpsos.de/sl/leistungen/security-wartungsvertrag/) nameščamo posodobitve, znova zaganjamo vse procese in dokumentiramo stanje.
- Pri obvestilih brez popravka uvedemo prehodne ukrepe, ki jih ni mogoče prepisati, in jih naknadno preverimo.


## Pogosta vprašanja

**Ali po PHP2Shell že obstaja nova varnostna ranljivost PHP?**  
23. oktobra 2026 je php.net objavil obvestilo o CVE-2026-115560. Izvajanje kode je po njem mogoče samo pri nenavadni konfiguraciji sej. Popolno obvestilo (advisory) naj bi sledilo ob naslednji redni izdaji.

**Ali moram po vsakem novem obvestilu takoj ukrepati?**  
Vsako obvestilo ne zahteva enake nujnosti. Odločilni so stopnja resnosti, prizadetost vaše konfiguracije in vprašanje, ali je popravek na voljo. Določen potek pomaga, da to ocenite v minutah namesto v dneh.

**Kje najprej izvem za nove ranljivosti PHP?**  
Primarni viri so obvestila na php.net in varnostne opombe vaše distribucije, na primer Ubuntu Security Notices, Debian Security Tracker ali Red Hat. BSI (nemški zvezni urad za informacijsko varnost) obvešča z opozorili. Medijska poročila so koristna, a pogosto pozneje in manj natančna.

**Zakaj distribucije včasih obvestijo dneve pozneje kot php.net?**  
Distribucije morajo popravek prevzeti v svoje pakete, jih zgraditi in preizkusiti. Za starejše izdaje lahko to traja dlje ali poteka samo prek dodatnih ponudb. Zato se splača oba vira spremljati ločeno.

## Viri

- [php.net: obvestila in varnostne opombe](https://www.php.net/)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [BSI](https://www.bsi.bund.de/)