Dabartinė padėtis: PHP2Shell. Du kritiniai PHP pažeidžiamumai (CVSS 9,2) leidžia vykdyti kenkėjišką kodą be prisijungimo. Pataisos nuo 2026-10-21.Ką dabar daryti →

Kaip PHP projektas tvarko saugumo spragas

PHP saugumo spragos pranešamos konfidencialiai, įvertinamos, ištaisomos leidime ir paskelbiamos kaip GitHub Security Advisory. PHP2Shell parodo eigą ypatingu atveju.

Būsena 4 min. skaitymoPHP žinios

Trumpai: PHP saugumo spragos pranešamos konfidencialiai, pirmiausia per privačią Advisory formą GitHub saugykloje php/php-src, alternatyviai į security@php.net. PHP kūrėjai radinį įvertina kaip aukštą, vidutinį ar žemą; sunkios klaidos taisomos atskiroje saugumo saugykloje ir paskelbiamos tik su leidimu kartu su GitHub Security Advisory ir dažniausiai CVE numeriu. Esant PHP2Shell, šis procesas vyko skubiai: išankstinis pranešimas 2026-10-20, pataisos 2026-10-21, papildomas pranešimas 2026-10-23.

Kas PHP rūpinasi saugumu?

PHP yra atvirojo kodo projektas. Saugumo politika wiki jį apibūdina kaip savanorių projektą be biudžeto premijoms. Kiekvienai versijai yra leidimų vadovai (release managers), atsakingi už leidimus. Be to, yra PHP Foundation, kuri, pasak savo pačios pristatymo, samdo ne visu ir visu etatu dirbančių kūrėjų komandą, dirbančią prie PHP priežiūros, saugumo ir naujų funkcijų.

Įmonėms tai reiškia: nėra gamintojo su sutartimi, karštąja linija ar garantuotais reagavimo laikais. Kam reikia įpareigojančių įsipareigojimų, juos gauna iš savo Linux distribucijos, hostingo teikėjo ar ilgalaikės pagalbos teikėjo, o ne iš paties PHP projekto. Šią tiekimo grandinę turėtumėte žinoti.

Kaip pranešama apie spragą

Kelias aprašytas saugumo politikoje GitHub:

  1. Pranešti: per privačią Security Advisories formą saugykloje php/php-src. Kas to negali naudoti arba nori aptarti temą, kuri nėra klaidos pranešimas, rašo į security@php.net.
  2. Aprašyti glaustai: pageidaujamas trumpas pavyzdys, rodantis klaidą, o ne ilgas pranešimas apie galimas pasekmes. Taip komanda gali peržiūrėti greičiau.
  3. Konfidencialumas: pranešimas lieka privatus iki paskelbimo.
  4. Paminėjimas: pranešėjai pagal MITRE Credit sistemą minimi kaip prisidėję asmenys.

Senesnis wiki puslapis papildomai mini klasikinį klaidų sekimo įrankį su tipu „Security“. Šiandien lemiamas yra kelias per GitHub.

Ką PHP projektas laiko saugumo spraga

Ne kiekvienas strigimas yra saugumo spraga. Wiki nurodo keturis kriterijus: klaida leidžia neteisėtus veiksmus, peržengia saugumo ribas, atveria prieigą prie svetimų duomenų arba sunkiai pablogina prieinamumą ar našumą. Vertinama trimis lygiais:

Lygis Reikšmė pagal politiką CVE numeris
Aukštas trečiosios šalys gali pažeisti daugumą diegimų, vykdyti kodą ar skaityti failus paprastai taip
Vidutinis panašus poveikis, bet tik retesnėmis sąlygomis, pavyzdžiui, retas plėtinys ar konfigūracija dažniausiai taip
Žemas teoriškai įmanoma, praktiškai labai sunku išnaudoti dažniausiai ne

Taip pat pamokantis yra sąrašas to, kas aiškiai nėra saugumo spraga: tyčia vykdomas kenkėjiškas kodas, open_basedir ir disable_functions apėjimai, kenkėjiški duomenys unserialize(), FFI naudojimas ir įprastas atminties nutraukimas, kai suveikia memory_limit ir baigiasi tik dabartinė užklausa. Eksploatuotojams tai reiškia: disable_functions yra prasmingas sutvirtinimas, bet ne apsauginė siena.

Nuo ištaisymo iki paskelbimo

Aukštų ir vidutinių spragų ištaisymai, pasak wiki, įtraukiami į atskirą saugumo saugyklą prieš sukuriant leidimą. Žemai įvertintos klaidos tvarkomos kaip įprasti klaidų taisymai. Spraga skelbiama pagal atsakingo atskleidimo principą: pirma ištaisymas, paskui detalės. Leidimai, pasak wiki, paprastai išleidžiami ketvirtadieniais, dažnai kartu su reguliariais mėnesiniais leidimais.

Su leidimu paskelbiamas GitHub Security Advisory su savo identifikatoriumi (GHSA) ir sunkumo lygiu. Saugykloje, pavyzdžiui, 2026-09-24 pasirodė keli advisories apie srautų apvalkalus (stream wrappers), FastCGI ir filtrus su sunkumo lygiais nuo žemo iki aukšto. Šaltinio paketai php.net siūlomi su SHA-256 kontrolinėmis sumomis ir leidimų vadovų GPG parašais; Git žymės pasirašytos. Kurios versijų šakos apskritai dar gauna saugumo pataisymus, rodo puslapis apie PHP versijas ir leidimų ciklą.

PHP2Shell kaip ypatingo atvejo pavyzdys

PHP2Shell rodo, kaip procesas vyksta spaudžiant:

  • 2026-10-20: php.net paskelbia kritinį saugumo leidimą 2026-10-21 14:00 UTC ir pasilieka teisę paskelbti anksčiau, jei detalės taptų viešos ar atsirastų atakų. Pasak kelių pranešimų, detalės iš tikrųjų paaiškėjo dar nesibaigus draudimo laikotarpiui; aplinkybes nušviečia Kodėl PHP spraga paaiškėjo prieš pataisą.
  • 2026-10-21: išleidžiamos PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35, taip pat advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) ir GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), abu įvertinti kaip kritiniai. Pasak php.net, Linux distribucijos ir ilgalaikės pagalbos teikėjai ištaisymus gavo iš anksto. 7.4, 8.0 ir 8.1 skirti minimalūs backport.
  • 2026-10-23: informacinis pranešimas apie CVE-2026-115560 rekomenduoja session.upload_progress.enabled=0; visas advisory pateikiamas su kitu leidimu.

Ką eksploatuotojai iš to išveda

  1. Prenumeruoti šaltinius: php.net, php/php-src GitHub advisories ir jūsų distribucijos saugumo pranešimai.
  2. Žinoti tiekimo grandinę: kas tiekia jūsų PHP paketą ir kaip greitai ten pasiekia backport?
  3. Planuoti laiko langą: kritiniai leidimai gali pasirodyti ne įprastu ritmu; pataisų langas turi būti įmanomas trumpu įspėjimu.
  4. Numatyti paleidimą iš naujo: atnaujinimas veikia tik tada, kai paleisti iš naujo visi PHP procesai.
  5. Išsaugoti įrodymą: dokumentuoti versiją, paketo būseną ir laiką.

Kaip PHP SOS padeda konkrečiai?

Su PHP pataisų paslauga perimame dalį, kuri tenka jums:

  • Sekti pranešimus: stebime php.net, advisories ir distribucijų pranešimus ir vertiname, ar jūsų sistemos paveiktos.
  • Įgyvendinti pataisą: atnaujinimas iš tinkamo šaltinio, visų procesų paleidimas iš naujo, veikiančios versijos kontrolė.
  • Apsaugoti pereinamąjį laikotarpį: kur atnaujinimas strigsta, įgyvendiname oficialias pereinamąsias priemones.
  • Dokumentuoti: gaunate įrodymą su versijomis, paketų būsena ir laikais.

Dažni klausimai

Kaip pranešti apie PHP saugumo spragą?

Pirmiausia per privačią Security Advisories pranešimo formą GitHub saugykloje php/php-src. Kas to negali naudoti, rašo į security@php.net. Pranešimas lieka konfidencialus iki paskelbimo.

Ar PHP projektas moka premiją už rastas spragas?

Ne. Pasak saugumo politikos, PHP yra savanorių projektas be lėšų klaidų paieškos premijoms (bug bounty). Tačiau pranešėjai minimi kaip prisidėję asmenys.

Ar disable_functions apėjimas yra saugumo spraga?

Pagal PHP projekto politiką ne. open_basedir ir disable_functions apėjimai nelaikomi PHP saugumo problema. Nustatymai yra sutvirtinimas, bet ne patikima saugumo riba.

Kur sužinoti apie naujas PHP saugumo spragas?

php.net pradžios puslapyje su leidimų pranešimais ir GitHub saugyklos php/php-src Security Advisories. Kas PHP gauna iš distribucijos, papildomai seka jos saugumo pranešimus.

Kodėl PHP2Shell buvo paskelbta trečiadienį?

Pasak wiki, leidimai paprastai išleidžiami ketvirtadieniais. PHP2Shell atveju php.net 2026-10-20 paskelbė saugumo leidimą trečiadienį, 2026-10-21, 14:00 UTC, ir pasiliko teisę paskelbti anksčiau, jei detalės taptų viešos.

Šaltiniai

Skubus kontaktas

Kiekviena valanda svarbi. Parašykite mums dabar.

Trumpai aprašykite sistemą, PHP versiją ir pastebėjimus. Mes atsakysime, išsiaiškinsime padėtį ir dirbsime nuotoliu, kol incidentas bus užbaigtas ir dokumentuotas.

Skubi pagalba