PHP kodo spragos 2026: ką tikrinti ir kaip apsisaugoti

Naujausi PHP ir ekosistemos pažeidžiamumai — nuo Object Injection iki SQLi. Praktinis sąrašas kūrėjams ir svetainių savininkams.

Arvaidas Rekis
  • PHP
  • Saugumas
  • Web

PHP vis dar varo didžiąją dalį svetainių — nuo WordPress ir Magento iki custom sistemų. 2025–2026 m. saugumo naujienose dominuoja ne tiek „vienas stebuklingas CVE“, kiek pasikartojantys modeliai: nesaugus unserialize(), SQL injekcijos, failų įkėlimai ir pasenę įskiepiai.

Kas dažniausiai skamba 2025–2026

  • PHP Object Injection — vartotojo duomenys patenka į unserialize() (slapukai, forma, cache). Su tinkama „gadget chain“ bibliotekoje tai gali virsti nuotoline komanda (RCE).
  • SQL injekcija — vis dar randama custom PHP ir kartais branduoliuose.
  • RCE per įskiepius — WordPress formų, hostingo panelių ar senų CRM scenarijai su eval() ar dinaminiais include.
  • Branduolio PHP — atminties ir vaizdų apdorojimo spragos (getimagesize(), iptcembed() ir pan.) — reikia atnaujintų PHP versijų.

Kodėl tai lieka aktualu Lietuvoje

Dauguma smulkių verslų svetainių — WordPress, OpenCart, senesni PHP 7.x hostingai, vienas žmogus „prižiūri viską“. Vienas neatsargus įskiepis ar senas composer paketas gali atverti visą serverį.

5 taisyklės kūrėjui

  1. Versijos. PHP 8.2+ (ar naujesnė palaikoma), composer audit. EOL PHP — ne diskusijų tema.
  2. Duomenų bazė. Tik paruoštos užklausos (PDO / mysqli su parametrais).
  3. Serializacija. Vartotojui — json_encode / json_decode. Jei būtina unserialize() — griežtas allowed_classes.
  4. Išvestis. htmlspecialchars(..., ENT_QUOTES, 'UTF-8') ar Twig su auto-escape. CSP antraštės.
  5. Failai. Įkėlimai už public_html, atsitiktiniai vardai, MIME tikrinimas. display_errors=Off produkcijoje.

php.ini ir serveris

expose_php=Off, allow_url_include=Off, riboti disable_functions, saugūs slapukai (httponly, samesite).

Ką stebėti po incidento

  • Nauji admin vartotojai, nepažįstami .php failai uploads/.
  • Serializuoti objektai slapukuose (O:).
  • Anomalijos access loguose.

Išvada

Stipriausia gynyba — atnaujinimai, draudimas deserializuoti nepatikimus duomenis, paruoštos užklausos ir mažiausios teisės.

Šaltiniai: php.net security, CISA KEV, CMS biuleteniai.

Rašote PHP projektą? Galiu padėti su auditų sąrašu ar saugesniu kodu — parašykite užklausą.