Kritiska PHP ievainojamība: ko pilnīgā šifrēšana mainīja (un ko nemainīja)

Kas notika (un kāpēc bija jārīkojas nekavējoties)

2026. gada 21. oktobrī tika izlaistas PHP versijas 8.5.12, 8.4.27, 8.3.36 un 8.2.35, lai novērstu divas kritiskas ievainojamības: CVE-2026-109618 un CVE-2026-109619. Abām piešķirts kritisks CVSS novērtējums 9.2, un tās ļauj neautentificētam attālinātam uzbrucējam izpildīt patvaļīgu kodu serverī.

CERT-EU un neatkarīgu drošības pētnieku ziņojumi apliecināja, ka tehniskās detaļas tiek publiski apspriestas un funkcionējoši uzbrukuma kodi (PoC) tīklā parādījās jau pirmajās stundās. Operatīvā ziņā tas nozīmēja vienu: šo atjauninājumu nedrīkstēja atlikt līdz nākamā mēneša apkopes logam — bija jārīkojas tūlīt.

encrypted1on1 darbojas uz PHP 8.5 oficiālajā FrankenPHP konteinerā. Atjauninātie bāzes attēli Docker Hub krātuvē kļuva pieejami tajā pašā vakarā.

Ko mēs paveicām savā infrastruktūrā

Mēs atjauninājām konteinerus visā mūsu infrastruktūrā praktiski uzreiz pēc jaunās versijas iznākšanas:

• Mūsu pakalpojums tika pārbūvēts ar PHP 8.5.12 bāzes attēlu un pārstartēts bez dīkstāves.
• Nav nepieciešamas koda izmaiņas: Tā kā mūsu ražošanas Dockerfiles izmanto birku php8.5, parasta konteinera pārbūve automātiski ietvēra atjaunoto PHP izpildlaiku.
• Audits un žurnāli: Mēs veicām detalizētu piekļuves žurnālu un tīkla anomāliju auditu starpniekserveros un lietojumprogrammu procesos. Netika konstatētas nekādas skenēšanas, ielaušanās vai aizdomīgas aktivitātes pēdas pirms atjaunināšanas vai tās laikā.

Kāpēc 1 pret 1 sarunu piezīmes serverī nekad nebija izlasāmas

Tieši šādos brīžos Zero-Knowledge arhitektūra pilnībā attaisno savu esamību.

Tradicionālā 1:1 rīkā vai iekšējā uzņēmuma viki (Notion, Google Docs, Slack vai parastā personāla vadības sistēmā) koda izpildes ievainojamība serverī ir katastrofa. Uzbrucējs atver konsoli, nolasa datubāzes piekļuves datus un lejupielādē pilnu datubāzes kopiju. Tajā pašā mirklī atklāts kļūst viss uzņēmuma iekšējais saturs: bažas par kompetenci, strīdi par atalgojumu, personiskās problēmas un nefiltrēta atgriezeniskā saite.

Savukārt encrypted1on1 serveris arhitektoniski nespēj redzēt jūsu sarunu tekstu. Visas tikšanās piezīmes, darba kārtība, personiskās domas un atbilžu melnraksti tiek šifrēti tieši lietotāja pārlūkprogrammā ar AES-GCM-256 vēl pirms datu nosūtīšanas tīklā.

Servera datubāze satur tikai un vienīgi necaurredzamu šifrētu tekstu:

• Abu dalībnieku atbildes un pārdomas (gan melnrakstus, gan publicētos ierakstus);
• Komentārus, vienošanās, apspriežamos jautājumus un uzdevumus;
• Katra dalībnieka personīgās piezīmes;
• Progresa atzīmes un individuālo attīstības mērķu piezīmes.

Atšifrēšanas atslēgas tiek ģenerētas dalībnieku ierīcēs no viņu parolēm, izmantojot atmiņas ziņā prasīgo Argon2id algoritmu. Šīs atslēgas nekad neatstāj ierīci atklātā veidā — serveris glabā tikai aizzīmogotas kriptogrāfiskās aploksnes, kuras tas matemātiski nespēj atvērt.

Pat ja uzbrucējs iegūtu pilnu ražošanas datubāzes kopiju un visus diska failus, viņa rīcībā nonāktu tikai neizmantojams šifrs, kuru nav iespējams nolasīt bez konkrēto lietotāju parolēm. Tā ir mūsu pamatfilozofija: mēs neprasām uzticēties tam, ka mūsu serveros nekad nebūs nevienas drošības kļūdas. Kļūda PHP, operētājsistēmas C bibliotēkā vai mūsu kodā nepārvēršas par darbinieku privāto sarunu noplūdi.

Godīgā robeža: ko pilnīgā šifrēšana aizsargā un ko tā nespēj aizsargāt

Drošība balstās inženiertehniskā atklātībā, nevis mārketinga apgalvojumos. Šeit ir precīzas mūsu apdraudējumu modeļa robežas servera kompromitēšanas gadījumā:

1. Metadati serverī ir redzami. Šifrēšana uzticami aizsargā sarunu saturu, taču serverim ir jānodrošina darbības maršrutēšana. Uzbrucējs ar root piekļuvi serverim varētu redzēt kontu identifikatorus, kas ar ko tiekas 1 pret 1 sarunās, to biežumu un laika zīmogus. Turklāt ērtības nolūkos daži vispārīgi organizācijas dati tiek glabāti nešifrēti: mērķu nosaukumi, termiņi, statuss un uzņēmuma jautājumu sagataves. Pilns saraksts ir publiski pieejams mūsu apdraudējumu modelī.

2. Šifrēšana aizsargā esošos datus, nevis nākotnes koda piegādi. encrypted1on1 ir tīmekļa lietotne: pārlūkprogramma ielādē JavaScript kodu no servera. Ja uzbrucējs iegūtu noturīgu koda izpildes piekļuvi serverī, viņš teorētiski varētu mēģināt modificēt šos skriptus, lai mēģinātu pārtvert paroli nākamās lietotāja pieslēgšanās laikā. Mēs pret to aizsargājamies ar stingru CSP (Content-Security-Policy) politiku, nemainīgiem konteineru attēliem un apakšresursu integritātes pārbaudēm. Tomēr neviena klienta puses šifrēšana pasaulē nespēj pilnībā novērst to, ka pilnībā kompromitēts tīmekļa serveris mēģina nodot modificētu kodu nākotnes apmeklētājiem.

Galvenais secinājums: Pilnīgā šifrēšana pārvērš katastrofālu vēsturisko datu noplūdi par parastu, operatīvi pārvaldāmu programmatūras atjaunināšanas procesu. Viss, kas tika uzrakstīts iepriekš, paliek matemātiski neaizskarams; savlaicīga servera ielāpu uzstādīšana nodrošina turpmāko sesiju integritāti. Ir nepieciešamas abas pieejas.

Kā atjaunināt savu pašmitināto serveri (Soli pa solim)

Ja jūs darbināt encrypted1on1 savā serverī ar Docker, atjaunināšana prasa mazāk par divām minūtēm un tai nav vajadzīgas datubāzes migrācijas vai konfigurācijas labojumi.

1. solis: Lejupielādējiet atjaunināto bāzes attēlu.
Izvietošanas skripts būvē lietojumprogrammas konteineru, taču Docker var izmantot vietēji kešoto slāni ar veco PHP. Skaidra lejupielāde nodrošina tīra PHP 8.5.12 iegūšanu:

docker pull dunglas/frankenphp:php8.5

2. solis: Pārbūvējiet un palaidiet no jauna.
Palaidiet standarta izvietošanas skriptu no savas projekta direktorijas:

PROD_COMPOSE_FILE=docker-compose.prod.yml ./docker/prod/deploy.sh

(Vai vienkārši ./docker/prod/deploy.sh, ja compose fails jau ir definēts jūsu vidē).
Skripts automātiski uzbūvēs attēlu ar jūsu pašreizējo kodu, pārveidos konteineru, izpildīs migrācijas, atjaunos kešatmiņu un veiks iekšējo veselības pārbaudi.

Piezīme: Nav nepieciešams veikt lietotnes koda git pull, ja vēlaties tikai drošības ielāpu. Pārbūve uz svaigā bāzes attēla pilnībā atrisina ievainojamību.

3. solis: Pārbaudiet PHP versiju konteinerā.
Pārbaudiet aktīvo PHP versiju strādājošajā konteinerā:

docker compose -f docker-compose.prod.yml --env-file .env.prod exec app php -v

Komandai jāatgriež PHP 8.5.12 vai jaunāka versija.

Ja darbināt lietotni bez Docker tieši operētājsistēmā, atjauniniet PHP pakotnes ar savas sistēmas rīkiem un noteikti restartējiet PHP procesu (FrankenPHP darbinieku vai PHP-FPM), lai iztīrītu veco izpildāmo failu no operatīvās atmiņas.

Nobeigumā: Uzticieties matemātikai, nevis solījumiem

Drošības ievainojamības radīsies arī turpmāk — PHP, Linux kodolā, OpenSSL vai pārlūkprogrammu dzinējos. Neviens programmatūras izstrādātājs nevar godīgi apsolīt, ka viņa infrastruktūra nekad nesaskarsies ar kādu kļūdu.

Taču ko mēs varam apsolīt — un ko jūs paši jebkurā brīdī varat neatkarīgi pārbaudīt mūsu atvērtajā pirmkodā —, ir tas, ka jūsu komandas uzticēšanās nekad netiek pakļauta servera labvēlībai. Kad infrastruktūra svārstās, matemātika notur aizsardzību.

Ja jums ir jautājumi par šo laidienu vai šifrēšanas modeli, aicinām pievienoties diskusijai GitHub.