Две критични уязвимости в PHP - какво да направите със сайта и магазина си

На 21 октомври 2026 г. в 17:00 българско време екипът на PHP планира да пусне спешна поправка на две критични уязвимости, оценени с 9.2 от 10. Подробностите ще станат ясни чак тогава, но едно е ясно още сега - PHP пуска официални поправки само за поддържаните клонове, а това днес са 8.2, 8.3, 8.4 и 8.5. Ако вашият сайт или магазин работи на PHP 7.x или 5.6, той няма да получи официална поправка от PHP нито днес, нито по-късно. В същите дни SuperHosting обяви месечна такса за хостинг акаунти, на които още има сайтове с PHP под 7.0. Ето какво се случва, какво да проверите днес и какво да направите в OpenCart и WooCommerce.

Статията е написана на 21.10.2026 преди официалното обявяване. Ще я обновим с поправените версии веднага след като PHP ги публикува.

Какво обяви PHP и какво още не се знае

На 20 октомври екипът по сигурността на PHP публикува предварително известие на php.net. В него пише, че поправката излиза в сряда, 21 октомври, в 14:00 UTC, че покрива две критични уязвимости, всяка с оценка 9.2 по CVSS 4.0, и че пълните подробности, засегнатите и поправените версии ще бъдат публикувани заедно с нея. Екипът си запазва правото да я пусне и по-рано, ако подробностите излязат публично или ако се появят атаки.

Обикновено поправките в PHP просто излизат с новите версии, без предупреждение. Когато екипът предупреждава ден по-рано и съветва всички да се подготвят, това е знак, че проблемът се смята за сериозен и че след обявяването няма да има много време за реакция.

Номерата CVE-2026-109618 и CVE-2026-109619 станаха известни още преди известието - изтекоха в социалните мрежи и във форума Hacker News. Към момента на писане и двата са със статус "запазен" в регистъра на CVE, без описание. Фирмата за сигурност watchTowr заяви, че номерата са истински, а в изтеклите съобщения те са описани като уязвимости за изпълнение на чужд код на сървъра. Самото известие на PHP не назовава номерата и не казва какъв е видът на проблема, така че към момента това е съобщено, а не официално потвърдено.

Какво още не се знае:

• Коя част от PHP е засегната - функция, разширение или конкретна настройка. Никой от публичните източници не я назовава.
• Кои версии са засегнати. В изтеклите съобщения се твърди, че е засегнат целият PHP от версия 5 насам, но авторът сам признава, че няма доказателство. watchTowr също пише, че това не е потвърдено.
• Дали атакуващият трябва да има някакъв достъп или може да атакува всеки сайт отвън. Има такива твърдения, но без източник.

Добрата новина е, че към 21 октомври няма публично съобщени атаки с тези уязвимости, а техническите подробности не са публични. Това дава няколко часа за подготовка.

Защо това е важно за един онлайн магазин

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

Оценка 9.2 от 10 по CVSS е в най-горния клас - "критична". Повечето уязвимости в плъгини и модули, за които се пише всяка седмица, са с по-ниска оценка.

Коя версия на PHP ще получи поправката

PHP пуска поправки само за клоновете, които са в поддръжка. Според официалния график към октомври 2026 г. това са:

• PHP 8.5 - пълна поддръжка до края на 2027 г., поправки за сигурност до 31.12.2029 г.
• PHP 8.4 - пълна поддръжка до края на 2026 г., поправки за сигурност до 31.12.2028 г.
• PHP 8.3 - само поправки за сигурност, до 31.12.2027 г.
• PHP 8.2 - само поправки за сигурност, до 31.12.2026 г. След два месеца и тя излиза от поддръжка.

Последните версии преди днешната поправка са 8.5.11, 8.4.26, 8.3.35 и 8.2.34 от 24 септември 2026 г. Ако сайтът ви е на някоя от тях или на по-стара в същия клон, след днешната поправка трябва да мине на следващата.

Всичко под 8.2 е извън поддръжка според списъка на php.net - PHP 8.1 от 31.12.2025 г., 8.0 от ноември 2023 г., 7.4 от ноември 2022 г., а 5.6 още от края на 2018 г. За тях PHP не пуска поправки. Някои хостинги и дистрибуции поддържат собствени закърпени версии на стари клонове, но това е тяхна услуга и трябва да се провери конкретно при вашия доставчик, не да се приема наготово.

Какво да направите днес, преди поправката

Срещу неизвестна уязвимост няма официална временна мярка - не търсете "кръпки" по форумите. Има обаче пет неща, които си струва да се направят още днес.

1. Разберете на каква версия на PHP работи всеки сайт. Не само основният домейн, а и всеки поддомейн и всяко старо копие в акаунта - demo, new, old, test. В cPanel версията се вижда в инструмента за избор на PHP (при SuperHosting това е PHP Manager by SuperHosting, при други хостинги Select PHP Version или MultiPHP Manager). В WordPress е в Инструменти, Здраве на сайта, раздел Информация, Сървър. В WooCommerce - в WooCommerce, Статус. В OpenCart 3 няма такъв екран и най-бързо е хостингът да ви каже.
2. Проверете и версията за задачите по график. Командата php -v в терминала показва версията за командния ред, която често е различна от тази на сайта. Синхронизациите със складови програми, XML фийдовете и напомнянията по имейл обикновено се пускат точно оттам.
3. Направете пълно резервно копие на файловете и базата данни и го свалете извън хостинга. Ако след обновяването нещо спре да работи или ако сайтът бъде атакуван, ще имате копие отпреди днешния ден. Уверете се, че копието се отваря и може да се възстанови - непроверено копие често се оказва непълно точно когато потрябва.
4. Махнете излишното. Забравени копия на сайта, папката install на OpenCart, файлове с phpinfo(), adminer.php, архиви .zip с целия сайт в публичната папка. Каквато и да се окаже уязвимостта, всеки излишен файл на сървъра е още една врата.
5. Разберете кой обновява PHP при вас. При споделен хостинг обикновено го прави хостингът - в рамките на клона (например от 8.3.35 към следващата 8.3 версия), без вие да правите нищо. На собствен сървър (VPS) обновяването е ваше - пакетите се обновяват и PHP-FPM или уеб сървърът се рестартира. Внимание при дистрибуциите като Ubuntu и Debian - те пренасят поправките в своите пакети, като номерът на PHP (например 8.3.6) остава същият, а се сменя само номерът на пакета. Там се гледа бюлетинът за сигурност на дистрибуцията за конкретния CVE и инсталираната версия на пакета, не номерът на PHP.

След 17:00 следете php.net за новите версии. Проверете още същата вечер или на следващата сутрин дали версията на сайта ви се е сменила - и за самия сайт, и за командния ред, от който вървят задачите по график.

Какво да направите в OpenCart

При OpenCart магазините въпросът рядко е в самата система. Последните версии от линията 3.0 (3.0.5.x) са подготвени за PHP 8.4 и 8.5 според бележките към тях, а OpenCart 4 изисква PHP 8.0 или по-нов (което не значи, че 8.0 е добър избор - той отдавна е без поддръжка). Подготвена система обаче не гарантира, че конкретният магазин с неговата тема и модули ще тръгне. Пречката при преминаване към нов PHP почти винаги са модулите и темата. По наш опит от поддръжката на магазини проблемите се събират на едни и същи места:

• Закодирани модули. Много платени модули и теми са закодирани с ionCube. За да работят на нов PHP, трябват две неща - хостингът да има ionCube Loader за тази версия и самите файлове да са закодирани за нея. Текущият loader 15.5.1 от 18.09.2026 г. поддържа и PHP 8.5, но модул, закодиран преди години само за PHP 7, на PHP 8 няма да тръгне. Някои разработчици пускат файлове, закодирани за няколко версии на PHP наведнъж, затова се проверява всеки модул поотделно. Ако модулът не върви, решението е нова версия от разработчика - проверете кои модули имате и дали разработчикът още ги поддържа.
• Модификациите и кешът. След смяна на версията обновете модификациите от Extensions, Modifications и изчистете кеша на шаблоните. Ако ползвате Journal 3 или модул за кеширане на страниците, изчистете и техния кеш.
• Дневникът с грешки. На PHP 8 по-старите модули пишат много предупреждения. Виждали сме error.log да порасне до стотици мегабайти и да запълни дисковото пространство на акаунта. Изключете показването на грешки в магазина (System, Settings, раздел Server, Display Errors), оставете записа им включен и погледнете дневника ден след смяната.
• Плащане и доставка. Минете през цялата поръчка с всеки начин на плащане - наложен платеж, карта, кредит - и с модулите на куриерите. Тези модули често са писани отдавна и първи показват проблем.
• Синхронизации. Връзката със складовата или счетоводната програма, фийдът за Google Merchant Center и сравнителните сайтове се пускат по график. Проверете, че след смяната продължават да вървят.

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

Работи ли темата Journal 3 с PHP 8.2 и по-новите версии

Зависи от версията на темата. Journal 3 е една от най-популярните теми за OpenCart и голяма част от магазините, които поддържаме, са на нея. При смяна на PHP тя често е първото, което спира, затова версията на Journal се проверява преди версията на PHP.

• Линията 3.2 е подготвена за новия PHP. Тя излезе през февруари 2025 г. с изцяло обновени вътрешни библиотеки, а в списъка с промени на версия 3.2.9 от 10.07.2026 г. изрично пише, че е добавена съвместимост с PHP 8.5. Последната версия към момента е 3.2.10 от 11.07.2026 г. Имаме магазини на Journal 3.2.8, които работят на PHP 8.2, и тестови копия на PHP 8.3 без проблеми.
• По-старите версии 3.0.x и 3.1.x са рискови. Библиотеките, с които идват, са от времето на PHP 7, и по наш опит, в зависимост от конкретната версия, тези магазини може да не работят коректно на PHP над 8.1. Официална страница с изисквания за PHP Journal няма, затова се проверява на тестово копие, не на основния магазин.
• Как да видите версията. Във файловете на магазина версията е в константата JOURNAL3_VERSION - във файла system/library/journal3/build.php при 3.2.x и в system/library/journal3.php при по-старите версии. Ако нямате достъп до файловете, попитайте разработчика, който поддържа магазина.
• Обновяването на темата е безплатно. Според официалния сайт на Journal всяка нова версия се изтегля от профила на купувача, със или без активна поддръжка. Темата работи с OpenCart 2.3, 3 и 4 и е тествана до OpenCart 3.0.5.1 и 4.1.0.4.
• Преходът от 3.1 към 3.2 не е само качване на файлове. В указанията на Journal пише, че някои настройки може да се върнат по подразбиране, а модули от други разработчици, преправени за 3.1, може да спрат да работят и да трябва да се адаптират наново. Затова темата се обновява първо на тестово копие, проверяват се дизайнът, филтрите, количката и поръчката, и чак тогава се обновява основният магазин.
• След обновяването обновете модификациите от Extensions, Modifications, изчистете кеша на шаблоните и кеша на Journal.

Редът е важен - първо темата и модулите, после PHP. Ако смените PHP на магазин със стар Journal, рискувате бяла страница точно в деня, в който трябва бързо да приложите поправка.

Какво да направите в WordPress и WooCommerce

WordPress препоръчва PHP 8.3 или по-нов, а в ръководството за хостинги, обновено на 14.10.2026 г., вече пише, че за работещи сайтове се препоръчва PHP 8.4. WordPress 7.1 работи с PHP от 7.4 до 8.5, но версиите до 8.1 са оставени само за съвместимост. WooCommerce е по-строг - за версия 10.8 и по-новите сървърните изисквания са PHP 8.3 или по-нов (тестван до PHP 8.4), WordPress 6.9 или по-нов и памет поне 256 MB. Затова за магазин на WooCommerce най-сигурният избор днес е PHP 8.3 или 8.4.

• Първо плъгините и темата, после PHP. Обновете всичко до последна версия. Най-често се чупят плъгини, които не са обновявани от години, и стари версии на билдъри като Elementor и WPBakery.
• Тестово копие. Много хостинги предлагат копие на WordPress сайта с един бутон. Сменете PHP там, проверете и тогава на основния сайт.
• Поръчка от начало до край. Количка, плащане, известията от платежните системи, имейлите за поръчката, формите за контакт.
• Обновяването на WordPress не поправя PHP. Уязвимостта е в езика, на който работи сайтът, а не в WordPress. Плъгините и ядрото се обновяват отделно и пак трябва, но днешният проблем се решава само с обновяване на PHP на сървъра.

Какво почва да прави SuperHosting от 1 ноември

На 21 октомври SuperHosting изпрати писма до клиентите си, на които още има сайтове с PHP под 7.0. От 1 ноември 2026 г. въвежда допълнителна услуга Legacy PHP Support за хостинг акаунтите с активна версия на PHP под 7.0 - 3,60 евро на месец с ДДС за хостинг акаунт. Сумата се добавя към първата фактура за подновяване на хостинга след 1 ноември. Таксата отпада, ако всички сайтове в акаунта минат на PHP 7.0 или по-нова, като SuperHosting препоръчва версия 8 или по-нова. Мотивът е, че за тези версии хостингът заделя отделни ресурси и допълнителни мерки за сигурност. Защо държи на обновяването, SuperHosting обяснява и в статията в блога си.

Три неща, които виждаме при клиентите си и които си струва да знаете:

• Таксата често идва от забравено копие. В писмата са изброени поотделно домейните и поддомейните на стар PHP. Основният сайт може отдавна да е на PHP 8, а в същия акаунт да стоят demo, new или стар поддомейн за поща на PHP 5.6. Такова копие е и риск за сигурността - то е в същия акаунт и стига до файловете и настройките на основния сайт.
• PHP 7.0 спира таксата, но не и риска. Целият клон 7 е без поправки от 2019-2022 г. и няма да получи и днешната. Минаването на 7.x само за да не се плаща е половин решение. Целта е PHP 8.3 или 8.4.
• Ако старият сайт не тръгва на PHP 8, това е знак, че системата под него не е обновявана от години. Тогава изборът е между обновяване на системата и модулите, нов сайт или изтриване на копието, ако вече не ви трябва - след резервно копие. Ако преходът ще отнеме време, поискайте от разработчика ясен срок и не оставяйте старото копие публично достъпно междувременно.

Версията се сменя от клиентския профил в SuperHosting - Хостинг акаунти, Вход в cPanel, раздел SuperHosting Tools, PHP Manager by SuperHosting. Може да се смени за целия акаунт или само за една папка.

Проверка след смяна на версията на PHP

Каквато и да е причината за смяната - днешната поправка, таксата или просто остарял сайт - след нея минете този кратък списък:

1. Начална страница, категория, продукт и търсене се отварят без грешки и без празни места.
2. Количка и поръчка с всеки начин на плащане и доставка.
3. Регистрация, вход и забравена парола.
4. Имейлите за поръчка и формите за контакт пристигат.
5. Вход в административния панел, редакция и запис на продукт.
6. Фийдовете и синхронизациите по график минават поне веднъж.
7. Дневникът с грешки ден по-късно - без нови фатални грешки.

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

Засегнат ли е моят сайт?

Засегнатите версии ще бъдат обявени заедно с поправката. Ако сайтът ви е на поддържан клон (8.2-8.5), отговорът е в това дали хостингът ще го обнови до поправената версия. Ако е на PHP 8.1 или по-стар, той е извън поддръжката на PHP - дори да се окаже засегнат, официална поправка за него няма да има. Такъв сайт трябва да се прехвърли на поддържан клон възможно най-скоро.

Хостингът обновява PHP сам - трябва ли да правя нещо?

Да, две неща. Първо, проверете след излизането на поправката, че версията наистина е сменена. Второ, хостингът обновява в рамките на клона, но не мести сайта от PHP 7.4 на PHP 8.3 сам, защото това може да го счупи. Тази стъпка е ваша.

Достатъчно ли е да мина на PHP 7.4, за да не плащам таксата на SuperHosting?

Таксата отпада от PHP 7.0 нагоре, но PHP 7.4 е без поправки от ноември 2022 г. и няма да получи и днешната. От гледна точка на сигурността има смисъл само преминаване на PHP 8.3 или 8.4.

Помага ли обновяването на OpenCart, WordPress или плъгините?

Не и за тази уязвимост. Тя е в самия PHP и се поправя само с обновяване на PHP на сървъра. Обновяването на системата и модулите е отделно и също нужно, особено ако подготвяте преминаване към PHP 8.

Ще работи ли магазин с Journal 3 на PHP 8.3?

Ако темата е от линията 3.2 и модулите са актуални - най-вероятно да, защото Journal 3.2.9 и по-новите са обявени като съвместими дори с PHP 8.5. Ако темата е 3.0.x или 3.1.x, първо я обновете на тестово копие, защото по-старите версии може да не работят коректно на PHP над 8.1.

Колко трудно е да мине един OpenCart магазин от PHP 7 на PHP 8?

Зависи от модулите и от версията на темата. Магазин с актуални версии на OpenCart и на темата и с малко модули минава без проблеми. Магазин с много стари закодирани модули може да има нужда от нови версии от разработчиците им или от замяна на някои модули. Затова първо се прави опис на модулите и проба на тестово копие.

Заключение

Днешната поправка на PHP е напомняне, че версията на PHP не е настройка, която се избира веднъж при пускането на сайта. Поддържаните клонове се сменят всяка година, а сайтовете, останали на стар клон, остават без защита точно в моменти като днешния. Проверете версиите на всички сайтове и копия в акаунта си, направете резервно копие, а след 17:00 се уверете, че поправката е стигнала до сървъра.

TEDBG следи версиите на PHP и съвместимостта на модулите като част от абонаментната поддръжка на сайтове. Ако искате да прехвърлите OpenCart или WooCommerce магазин на нов PHP или да проверите какво има в хостинг акаунта ви, пишете ни през формата за контакт с адреса на сайта.

Източници: php.net - Upcoming Critical PHP Security Release (20.10.2026), php.net - Supported Versions, php.net - Unsupported Branches, watchTowr - FAQ за CVE-2026-109618 и CVE-2026-109619, Cyber Kendra (21.10.2026), WordPress Hosting Handbook, WooCommerce - Server Requirements, ionCube Loaders, Journal - Changelog, Journal - обновяване от 3.1 към 3.2, писмо на SuperHosting до клиентите (21.10.2026)