# Блог: PHP2Shell, сигурност на сървъри и спешна помощ

> Блог за PHP2Shell и сигурността на сървърите: ситуация, хостинг, откриване, заздравяване, сигурна разработка, управление и помощ при вземане на решения.

Източник: https://phpsos.de/bg/blog/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

Оценка на ситуацията, ръководства за администратори и помощ при вземане на решения за ръководството. Подредени по теми, всяка статия е с източници.

- [PHP2Shell: какво е доказано и какво не](https://phpsos.de/bg/blog/php2shell-was-belegt-ist/): Проверка на фактите за PHP2Shell: кои твърдения идват от първични източници, кои от медийни съобщения и кои твърдения не издържат проверка.
- [Защо PHP уязвимостта стана известна преди пача](https://phpsos.de/bg/blog/php-luecke-vorzeitig-bekannt/): Според съобщенията подробности за PHP2Shell са станали публични преди изтичането на ембаргото. Обясняваме хода на събитията и какво означава той за планирането на пачовете.
- [Институции изключват уебсайтове: какво да научат фирмите от това](https://phpsos.de/bg/blog/behoerden-webseiten-offline/): Майнц, правителството на Хесен и BKA изключиха уебсайтове предпазно. Какво могат да научат фирмите от това за собственото си решение.
- [BSI ниво на предупреждение оранжево: какво означава оценката](https://phpsos.de/bg/blog/bsi-warnstufe-orange-erklaert/): BSI оценява PHP2Shell с 3 / оранжево. Какво казва скалата и какво не, и как фирмите да превърнат оценката в решения.
- [Какво съветват CERT-EU и CERT-Bund за PHP2Shell](https://phpsos.de/bg/blog/cert-eu-empfehlungen-php/): Официалните органи са единодушни: пачвайте незабавно, иначе изолирайте. Сравняваме препоръките и показваме как изглежда изолирането на практика.
- [Правилата за защита на Cloudflare срещу PHP2Shell: какво постигат и какво не](https://phpsos.de/bg/blog/cloudflare-waf-php2shell/): Cloudflare рано пусна правила за защита срещу PHP2Shell. Защо това помага, защо въпреки това не заменя актуализацията на PHP и кои настройки да проверите.
- [22,6 милиона изложени инстанции: как да осмислим числата](https://phpsos.de/bg/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel и други посочват твърде различни числа за PHP2Shell. Обясняваме какво е броено и кое число наистина има значение за Вас.
- [PHP2Shell за пет минути: брифинг за управителите](https://phpsos.de/bg/blog/php2shell-briefing-geschaeftsfuehrung/): PHP уязвимостта PHP2Shell на една страница за вземащите решения: ситуация, риск, пет въпроса към ИТ и решенията за днес.
- [PHP уязвимостта в сигурността, обяснена просто](https://phpsos.de/bg/blog/php-luecke-einfach-erklaert/): PHP2Shell за нетехници: с картини от ежедневието, малък речник и три типични изходни положения - какво да направите като собственик на уебсайт.
- [PHP2Shell: 15 въпроса на клиенти на хостинг](https://phpsos.de/bg/blog/fragen-von-hosting-kunden/): Уебсайтът Ви е при хостинг доставчик и искате да знаете какво трябва да направите сами при PHP2Shell? Ето 15-те най-чести въпроса с кратки отговори.
- [Защо актуализацията на WordPress не помага срещу PHP2Shell](https://phpsos.de/bg/blog/warum-wordpress-update-nicht-hilft/): След заглавията много оператори актуализираха WordPress и се чувстват сигурни. Защо при PHP2Shell това е напразно и какво има значение вместо това.
- [PHP2Shell и Log4Shell: какво е общото между уязвимостите](https://phpsos.de/bg/blog/php2shell-und-log4shell/): Мнозина сравняват PHP2Shell с Log4Shell от 2021 г. Докъде стига сравнението, къде куца и кои поуки от онова време помагат днес.
- [Масови сканирания за непачнат PHP: как протичат автоматизираните атаки](https://phpsos.de/bg/blog/automatisierte-massenscans/): След PHP2Shell нападателите претърсват автоматизирано интернет за уязвими сървъри. Как протича това, защо размерът няма значение и какво Ви защитава.
- [Времевият прозорец между пач и атака](https://phpsos.de/bg/blog/zeitfenster-patch-angriff/): При PHP2Shell имаше опити за атака още преди пача. Обясняваме фазите на времевия прозорец, как да измерите собствения си и как да го съкратите.
- [След PHP2Shell: защо още съобщения са вероятни](https://phpsos.de/bg/blog/weitere-php-meldungen/): PHP2Shell не е приключила с пача от 21 октомври. Защо се очакват последващи съобщения и как да настроите екипа си за това.
- [PHP2Shell: картината на положението след първата седмица](https://phpsos.de/bg/blog/lagebild-erste-woche/): Една седмица след първия наблюдаван опит за атака: състоянието на пачовете, предупрежденията на институциите, атаките и изключванията, подредени ясно по източници.
- [Опасни погрешни съвети за PHP2Shell, които в момента циркулират](https://phpsos.de/bg/blog/gefaehrliche-falschtipps/): Блокиране на бисквитки, скриване на съобщения за грешки, актуализиране само на CMS: девет съвета за PHP2Shell, които създават фалшива сигурност, и какво наистина има значение.
- [Смяна на PHP версията в клиентската зона на хостинга](https://phpsos.de/bg/blog/php-version-hosting-aendern/): Как да смените PHP версията в клиентската зона на хостинг доставчика, коя версия да изберете и какво да проверите преди и след това.
- [Debian и Ubuntu: пачнат ли е моят PHP пакет?](https://phpsos.de/bg/blog/debian-ubuntu-paket-gepatcht/): Кои PHP пакети Debian и Ubuntu са коригирали срещу PHP2Shell, как да сравните точно инсталираното състояние и къде се проваля доказването.
- [RHEL, AlmaLinux и Rocky Linux: проверка на PHP пача](https://phpsos.de/bg/blog/rhel-almalinux-rocky-php/): Какво публикува Red Hat за PHP2Shell, как да докажете състоянието на пакета на RHEL и клоновете му и защо презареждането не стига.
- [Хранилището sury.org: PHP пакети от външен източник](https://phpsos.de/bg/blog/sury-repository-php/): Много сървъри с Debian и Ubuntu вземат PHP от хранилището sury. Какво означава това за актуализациите, доказателствата и старите PHP версии след PHP2Shell.
- [Хранилището Remi: поддържане на PHP на RHEL системи актуален](https://phpsos.de/bg/blog/remi-repository-php/): Remi доставя актуални PHP версии за семейството RHEL, като модул или за паралелна инсталация. Така проверявате състоянието след PHP2Shell и избягвате забравени клонове.
- [Защо php -v показва същия номер след актуализацията](https://phpsos.de/bg/blog/php-v-zeigt-alte-nummer/): Актуализацията мина, но php -v съобщава старата версия. Най-често това е backport, а не грешка. Така разграничавате безобидното от истинските проблеми.
- [Доказване на CVE номера в changelog на пакета](https://phpsos.de/bg/blog/cve-im-changelog-nachweisen/): Който трябва да докаже PHP пача пред ръководството, одиторите или застрахователите, се нуждае от повече от номер на версия. Така записът в changelog става доказателство.
- [Смяна на хостера след инцидент със сигурността: на какво да обърнете внимание?](https://phpsos.de/bg/blog/hoster-wechseln-nach-vorfall/): След инцидент желанието за нов хостер е разбираемо. За да не отнесе сменянето нападателя със себе си, значение имат редът на стъпките и изборът.
- [Няколко версии на PHP на един сървър: пачнете всяка поотделно](https://phpsos.de/bg/blog/mehrere-php-versionen-server/): На много сървъри работят три, четири или повече PHP инсталации една до друга. След PHP2Shell всяка трябва да бъде намерена, актуализирана и рестартирана.
- [Изключване на стари версии на PHP в хостинг панела](https://phpsos.de/bg/blog/alte-php-versionen-abschalten/): PHP2Shell е добър повод да се освободите от старите версии на PHP. Така действате на три фази, за да не отпадне незабелязано нито уебсайт, нито cron задача.
- [Plesk: разбиране на PHP handler-ите (FPM, FastCGI, Apache модул)](https://phpsos.de/bg/blog/plesk-php-handler/): Кой PHP handler Plesk ползва за уебсайт, решава изолацията, конфигурацията и риска. Сравнение с поглед към PHP2Shell.
- [CloudLinux и alt-php: какво трябва да знаят хостинг клиентите](https://phpsos.de/bg/blog/cloudlinux-alt-php/): На сървъри с CloudLinux уебсайтовете често работят със собствени пакети alt-php. Всяка от тези версии изисква собствен пач и само операторът на сървъра може да го инсталира.
- [PHP на NAS, защитни стени и устройства: забравените системи](https://phpsos.de/bg/blog/php-auf-nas-und-appliances/): Не само уеб сървърите ползват PHP. Засегнати могат да бъдат и NAS системи, защитни стени и специализирани устройства с уеб интерфейс. Пачва ги обикновено само производителят, достъпността регулирате Вие.
- [PHP при облачни и PaaS доставчици: кой пачва средата за изпълнение?](https://phpsos.de/bg/blog/paas-php-laufzeit/): При платформените услуги PHP пачът зависи от модела на работа. Решаваща е средата за изпълнение, която наистина обслужва, не локалната среда и не кодът на приложението.
- [Официални PHP Docker образи: тагове, digest и ново изграждане](https://phpsos.de/bg/blog/offizielle-php-docker-images/): Тагът на официалния PHP образ е указател, който с времето се премества към нови състояния. Който знае какво значат таг, вариант и digest, избира правилния образ и може да докаже състоянието на пача.
- [CI/CD: автоматично ново изграждане на PHP образи](https://phpsos.de/bg/blog/php-images-in-ci-neu-bauen/): Образът остарява и без промяна в кода. С build-ове по график, проверка на версията и разполагане по digest PHP пачовете стигат надеждно до продукция.
- [Дългосрочна поддръжка за стари версии на PHP: опции и граници](https://phpsos.de/bg/blog/langzeitsupport-alte-php-versionen/): Който не може веднага да премине от PHP 8.1 или по-стара версия, намира дългосрочна поддръжка при дистрибуции, външни доставчици и комерсиални услуги. Какво постигат тези пътища, какво Ви трябва писмено и къде са границите.
- [Актуализиране на PHP под Windows](https://phpsos.de/bg/blog/php-unter-windows-aktualisieren/): Под Windows няма автоматична актуализация на PHP. Който избере правилния вариант, провери изтеглянето и рестартира всички процеси, довежда пача за PHP2Shell чисто на всеки компютър.
- [Предупредителен сигнал: уеб сървърът стартира shell](https://phpsos.de/bg/blog/webserver-startet-shell/): Ако процес на PHP-FPM или на уеб сървъра стартира shell, това е един от най-силните предупредителни сигнали за проникване. Така проверявате дървото на процесите, класифицирате изключенията и наблюдавате модела трайно.
- [Намиране на подозрителни процеси на Linux сървъри](https://phpsos.de/bg/blog/verdaechtige-prozesse-linux/): Злонамерените процеси се маскират с безобидни имена, работят от временни директории или от изтрити файлове. С малко команди само за четене намирате странностите и ги класифицирате.
- [Разпознаване на скрити cron задачи като задна вратичка](https://phpsos.de/bg/blog/cronjobs-als-hintertuer/): Нападателите ползват планирани задачи, за да се върнат след почистване. Така проверявате изцяло crontab файловете, cron директориите, таймерите на systemd и задачите at и разпознавате подозрителните записи.
- [Намиране на наскоро променени файлове на уеб сървъра](https://phpsos.de/bg/blog/geaenderte-dateien-finden/): След възможно проникване има значение какво се е променило на сървъра. Така търсите по времеви прозорци, ползвате правилно mtime и ctime и сверявате с пакети, Git и резервни копия.
- [PHP файлове в директорията за качване: правилно тълкуване на находките](https://phpsos.de/bg/blog/php-dateien-im-upload-ordner/): PHP файл в директорията за качване е почти винаги тревожен знак, но не всеки е злонамерен код. Така оценявате находката, без да унищожите следи, и изяснявате дали някой го е извикал.
- [Разпознаване на замъглен PHP код](https://phpsos.de/bg/blog/verschleierter-php-code/): Нечетим PHP код с eval и base64_decode е класически знак за вмъкнат злонамерен код. Какви шаблони да търсите, как да ги намирате безопасно и кога замъгляването е легитимно.
- [Проверка на изходящите връзки на един сървър](https://phpsos.de/bg/blog/ausgehende-verbindungen-pruefen/): Уеб сървърът отговаря преди всичко на заявки. Ако сам изгражда връзки към непознати цели, това може да означава управление от нападатели или изтичане на данни. Така проверявате и ограничавате изходящия трафик.
- [Намиране на чужди админ акаунти в CMS и на сървъра](https://phpsos.de/bg/blog/fremde-admin-konten-finden/): Непознатият администратор често е най-простата задна вратичка. Така търсите ниво по ниво чужди акаунти, и такива, които интерфейсът скрива.
- [Намиране и премахване на непознати SSH ключове](https://phpsos.de/bg/blog/ssh-schluessel-pruefen/): Вмъкнат SSH ключ отваря вратата на нападателите, дори всички пароли да са сменени. Така намирате всеки файл authorized_keys и проверявате всеки запис.
- [Криптоминър на уеб сървъра: признаци и действия](https://phpsos.de/bg/blog/kryptominer-auf-dem-server/): Постоянно пълно натоварване на процесора, без да идват повече посетители: това може да е криптоминър. Така проверявате натоварването, намирате процеса и механизмите му за рестарт и действате подредено.
- [Сървърът изпраща спам: намиране на причините](https://phpsos.de/bg/blog/server-verschickt-spam/): Недоставени писма, черни списъци, оплаквания: когато собственият сървър изпраща спам, зад това обикновено стои скрипт или превзета пощенска кутия. Така намирате източника.
- [SEO спам и чужди страници в индекса на Google](https://phpsos.de/bg/blog/seo-spam-im-google-index/): Изведнъж под Вашия домейн се класират страници за лекарства или стоки с чужди марки. Така ще откриете откъде идва SEO спамът и ще го изведете от индекса.
- [Уебсайтът пренасочва към чужди страници](https://phpsos.de/bg/blog/website-leitet-um/): Посетителите попадат на томболи или съмнителни магазини, а Вие самият не виждате нищо? Така ще откриете слоя, в който се крие пренасочването, и ще го премахнете.
- [Запазете доказателствата, преди да преинсталирате сървъра](https://phpsos.de/bg/blog/beweise-sichern-vor-neuinstallation/): Новата инсталация премахва нападателя, но и всички следи. Който преди това отдели един час за запазване на доказателства, по-късно може да каже какво се е случило.
- [Изготвяне на времевата линия на един инцидент](https://phpsos.de/bg/blog/zeitleiste-eines-vorfalls/): Кога е дошъл нападателят, какво е направил, кога е забелязано? Добре водена времева линия отговаря на тези въпроси и е основа за уведомления, застраховка и отчет.
- [Сравняване на основните файлове на CMS с оригинала](https://phpsos.de/bg/blog/cms-kerndateien-vergleichen/): Сравнението с чист оригинал показва всеки променен файл, независимо дали скенерът го познава. Така изграждате проверката за WordPress, Composer проекти и системни пакети.
- [Проверка на базата данни за внедрен код](https://phpsos.de/bg/blog/datenbank-auf-schadcode-pruefen/): Който проверява само файловете, пропуска половината. Така претърсвате съдържанието, настройките, тригерите и акаунтите в базата данни за внедрен код, само за четене и върху копие.
- [Скенери за зловреден софтуер на сайтове: какво откриват и какво не](https://phpsos.de/bg/blog/grenzen-von-malware-scannern/): Скенерът не съобщава нищо, значи всичко е наред? Не непременно. Какви видове скенери за сайтове има, какво вижда всеки от тях и какво по принцип не може да види.
- [Изолиране на PHP-FPM пулове за всеки сайт](https://phpsos.de/bg/blog/php-fpm-pools-isolieren/): Отделен пул за всеки сайт е началото, не краят. Така проверявате съществуващите пулове и заздравявате сокетите, разширенията, статус страниците, ресурсите и логовете.
- [Правилна настройка на memory_limit](https://phpsos.de/bg/blog/memory-limit-richtig-setzen/): memory_limit ограничава паметта за всяка PHP заявка. След PHP2Shell php.net временно съветва обратното. Какво важи в нормална работа, по време на прехода и след актуализацията.
- [Разумно ограничаване на post_max_size и upload_max_filesize](https://phpsos.de/bg/blog/post-max-size-upload-limits/): Лимитите за качване действат на три места: в уеб сървъра, в PHP и в приложението. Така задавате стойностите съгласувано, включително с преходните стойности на php.net за PHP2Shell.
- [Изключване на session.upload_progress: правилно и трайно](https://phpsos.de/bg/blog/session-upload-progress-abschalten/): Мярката срещу CVE-2026-115560 и една от преходните мерки за PHP2Shell се задава бързо. За да издържи, тя трябва да стои на правилното място, да е заключена и да се проверява отново след всяка актуализация.
- [expose_php и Server заглавия: скриване на данните за версиите](https://phpsos.de/bg/blog/expose-php-versionsangaben/): PHP, Nginx и Apache по подразбиране посочват номера на версията си във всеки отговор. Това не защитава от атаки, но дава на скенерите удобен списък с цели. Така го изключвате и въпреки това запазвате прегледа.
- [display_errors off: изключване на изхода на грешки в продукция](https://phpsos.de/bg/blog/display-errors-produktion/): Видимите съобщения за грешки на PHP издават пътища, имена на бази данни и версии. Така ги изключвате в PHP, в рамката и в уеб сървъра, без да изпускате грешките от поглед.
- [php_admin_value: заключване на настройки срещу презаписване](https://phpsos.de/bg/blog/php-admin-value-sperren/): Настройка за сигурност помага малко, ако приложението я променя отново с един ред код. С php_admin_value и php_admin_flag фиксирате стойности за PHP-FPM и Apache задължително.
- [Задаване на лимити на паметта със systemd и cgroups](https://phpsos.de/bg/blog/speichergrenzen-systemd-cgroups/): php.net препоръчва като преходна мярка за PHP2Shell memory_limit=-1 и лимит на паметта извън PHP. Така задавате този лимит със systemd и cgroups, без един отделен worker да повлече цялата услуга.
- [Сигурна конфигурация на Nginx за PHP](https://phpsos.de/bg/blog/nginx-fuer-php-absichern/): Повечето слабости в Nginx настройките за PHP не са в Nginx, а в няколко реда на PHP location. Така конфигурирате предаването към PHP-FPM, че да се изпълняват само желаните скриптове.
- [Сигурна конфигурация на Apache за PHP](https://phpsos.de/bg/blog/apache-fuer-php-absichern/): Apache е гъвкав и именно това го прави уязвим към погрешна конфигурация. Така свързвате PHP през PHP-FPM, затваряте .htaccess като задна врата и настройвате сигурно най-важните основни опции.
- [Забрана за изпълнение на PHP в папки за качване](https://phpsos.de/bg/blog/php-in-uploads-verbieten/): Уеб шелът се нуждае от две неща: папка, в която може да се записва, и сървър, който го изпълнява. Така му отнемате второто, и то във всяка папка с право за писане, не само в uploads.
- [Филтриране на заявки за качване в периферията: възможности и рискове](https://phpsos.de/bg/blog/upload-anfragen-am-rand-filtern/): Специалисти предлагат заявките за качване извън истинските пътища за качване да се блокират на прокси сървъра, докато PHP не бъде пачнат. Това може да помогне, но и да спре формуляри и поръчки. Така действате контролирано.
- [Внедряване на ModSecurity и OWASP Core Rule Set](https://phpsos.de/bg/blog/modsecurity-owasp-crs/): Собствена Web Application Firewall с ModSecurity и OWASP Core Rule Set е безплатна и мощна, но не работи сама. Така избирате двигател, стартирате без прекъсвания и настройвате правилата.
- [Настройка на Fail2ban за уеб сървъри](https://phpsos.de/bg/blog/fail2ban-fuer-webserver/): Fail2ban блокира адреси, които многократно се набиват на очи в логовете. За уеб сървъри има готови филтри, а с няколко реда се добавят собствени. Така го настройвате, без да блокирате себе си или клиентите си.
- [Защитна стена за уеб сървъри: отваряйте само необходимите портове](https://phpsos.de/bg/blog/firewall-fuer-webserver/): Уеб сървърът обикновено се нуждае навън само от два порта. Въпреки това на много сървъри в интернет слушат бази данни, PHP-FPM или административни интерфейси. Така намирате отворените услуги и затваряте ненужните.
- [Автоматични актуализации за сигурност на Linux сървъри](https://phpsos.de/bg/blog/automatische-sicherheitsupdates/): Според съобщения дистрибуциите са доставяли backport корекции за PHP понякога още на 21 октомври 2026 г., деня на пачовете. Който ползва автоматични актуализации за сигурност, ги е имал бързо на сървъра. За да действат, са нужни рестартирания, външни източници и контрол.
- [Least Privilege: права на потребителя на уеб сървъра](https://phpsos.de/bg/blog/rechte-des-webserver-benutzers/): Внедреният код се изпълнява с правата на потребителя на уеб сървъра. Какво може този акаунт, определя докъде стига атакуващият. Ето как да ограничите shell, sudo, cron, базата данни и файловата система до необходимото.
- [Скриване на админ частта чрез IP, VPN или допълнителна защита](https://phpsos.de/bg/blog/admin-bereiche-abschirmen/): Защо административната част на един уебсайт не трябва да е достъпна за целия свят и как да я скриете чрез IP филтър, VPN или предварителен вход, без да заключите сами себе си.
- [Правилна конфигурация на TLS и HTTPS](https://phpsos.de/bg/blog/tls-https-richtig-konfigurieren/): Кои версии на TLS и кои набори от шифри (cipher suites) трябва да предлага един уеб сървър днес, на какво се опират препоръките и как да проверите Nginx, Apache и изходящите връзки на PHP.
- [CIS Benchmarks и модули на BSI за уеб сървъри](https://phpsos.de/bg/blog/cis-benchmarks-bsi-bausteine/): Какви стандарти за заздравяване има за Linux уеб сървъри, с какво се различават CIS Benchmarks и модулите на IT-Grundschutz и как да превърнете това в проверима насока за Вашите PHP сървъри.
- [Сигурно съхранение на пароли в PHP: правилно използване на password_hash](https://phpsos.de/bg/blog/passwoerter-in-php-speichern/): Как разработчиците съхраняват пароли в PHP с password_hash и password_verify, избират подходящия метод и заменят стари MD5 или SHA-1 хешове, без да принуждават всички потребители да сменят паролата си.
- [CSRF защита в PHP приложения](https://phpsos.de/bg/blog/csrf-schutz-php/): Как разработчиците предотвратяват Cross-Site Request Forgery в PHP приложения: токени за всяка заявка, която променя данни, проверка на произхода в заглавната част и SameSite бисквитки като допълнителен слой.
- [Валидиране и филтриране на вход в PHP с filter_var](https://phpsos.de/bg/blog/eingaben-validieren-php/): Как разработчиците проверяват входа в PHP с filter_var, filter_input_array и списъци с разрешени стойности, кои филтри са остарели и защо валидирането не замества Prepared Statements и кодирането на изхода.
- [Предотвратяване на Command Injection в PHP](https://phpsos.de/bg/blog/command-injection-php/): Как разработчиците избягват Command Injection в PHP: замяна на системни команди с PHP функции, proc_open без shell, проверка на аргументите и откриване на опасните места в съществуващия код.
- [Предотвратяване на Server-Side Request Forgery (SSRF) в PHP](https://phpsos.de/bg/blog/ssrf-in-php/): Как разработчиците предотвратяват PHP приложение да запитва вътрешни системи по поръчка на външни лица: списъци с разрешени стойности, ограничаване на протоколите, проверка на разрешения адрес и граници в мрежата.
- [Предотвратяване на XML External Entities (XXE) в PHP](https://phpsos.de/bg/blog/xxe-in-php/): Как разработчиците обработват XML сигурно в PHP: стандартно поведение на libxml, рискови опции като LIBXML_NOENT, защита с Entity Loader и LIBXML_NO_XXE и типични скрити входове за XML.
- [Type Juggling в PHP: хлабавите сравнения като риск за сигурността](https://phpsos.de/bg/blog/type-juggling-php/): Защо хлабавите сравнения с == в PHP могат да доведат до уязвимости, какво се промени с PHP 8.0 и как да пишете устойчиви сравнения във входове, токени и права.
- [Сигурни случайни числа и токени в PHP с random_bytes](https://phpsos.de/bg/blog/sichere-tokens-php/): Как разработчиците създават в PHP токени за връзки за парола, API ключове и еднократни кодове: криптографски сигурни източници, достатъчна дължина, съхранение като хеш и ограничена валидност.
- [Правилна защита на данните за достъп и .env файловете](https://phpsos.de/bg/blog/env-dateien-schuetzen/): Как да защитите пароли за бази данни, API ключове и други тайни в PHP проекти: .env файлове извън уеб корена, блокиране в уеб сървъра, тесни права и подредена подмяна след инцидент.
- [Публична папка .git: недооценено изтичане на данни](https://phpsos.de/bg/blog/git-ordner-oeffentlich/): Защо уеб корен, внедрен чрез Git, може да разкрие целия изходен код заедно с историята, как да го проверите, да го блокирате веднага и да изградите внедряването трайно без папка .git.
- [Резервни файлове в уеб корена: .zip, .sql и .bak](https://phpsos.de/bg/blog/backup-dateien-im-webroot/): Защо дъмповете на бази данни, архивите и резервните копия в публичната директория са сред най-честите изтичания на данни, как да ги откриете, да ги блокирате и да изясните дали са били изтегляни.
- [Файлове phpinfo(): защо трябва да изчезнат](https://phpsos.de/bg/blog/phpinfo-dateien-entfernen/): След PHP2Shell много администратори бързо създават info.php. Защо такива файлове са теч на данни, как да ги откриете и кои начини за проверка са по-добри.
- [Поддържане на зависимостите актуални: Composer, npm и добавки](https://phpsos.de/bg/blog/abhaengigkeiten-aktuell-halten/): Един проект се състои от три свята на пакети: Composer, npm и добавки за CMS. Как да поддържате и трите актуални с твърд ритъм, ясна отговорност и тестове.
- [Код ревю за сигурност в PHP проекти](https://phpsos.de/bg/blog/sicherheits-code-review-php/): Как екипите целенасочено преглеждат собствения PHP код за уязвимости: видове ревюта, критични функции, смислени инструменти и контролен списък.
- [Сигурно логване: записване на грешки без теч на данни](https://phpsos.de/bg/blog/sicher-loggen-php/): Журналите помагат при търсене на грешки и форензика, но бързо стават самите те теч на данни. Какво трябва да записват PHP приложенията, какво никога и как се защитават журналите.
- [Защита на REST API в PHP](https://phpsos.de/bg/blog/rest-api-php-absichern/): Интерфейсите често са защитени по-зле от уебсайта пред тях. Най-важните правила за REST API в PHP, от правата върху обектите до ограничаването на честотата.
- [Договори с ИТ доставчици: ясно уреждане на задълженията за сигурност](https://phpsos.de/bg/blog/dienstleistervertrag-sicherheit/): PHP2Shell показа колко често е неясно кой трябва да пачва. Кои задължения за сигурност принадлежат в договорите с агенция, хостинг и ИТ доставчик.
- [Обработване на данни по поръчка, когато доставчици имат достъп до сървъри](https://phpsos.de/bg/blog/auftragsverarbeitung-serverzugriff/): Който допуска външни лица до сървъри с данни на клиенти, обикновено се нуждае от споразумение за обработване на данни (AVV). Какво изисква чл. 28 от ОРЗД и как да организирате достъпите при спешен случай в съответствие със защитата на данните.
- [Управление на уязвимостите в средния бизнес](https://phpsos.de/bg/blog/schwachstellenmanagement-mittelstand/): Нито една средна фирма не може да обработи веднага всяко съобщение. Схемата с отчитане, оценка, решение и доказателства гарантира, че най-важното се прави първо.
- [Да знаем какво работи: инвентар на всички уебсайтове и сървъри](https://phpsos.de/bg/blog/inventar-websites-server/): При PHP2Shell мнозина се спънаха не в пача, а във въпроса къде изобщо работи PHP. Ето как да изградите инвентар на всички уебсайтове и сървъри.
- [Управление на пачовете като процес, а не като гасене на пожари](https://phpsos.de/bg/blog/patch-management-prozess/): Който пачва само когато гори, губи време в критичен момент. Как процес с твърди класове, прозорци и доказателства свързва рутината и извънредната ситуация.
- [Контакти за извънредни ситуации: кого и кога трябва да уведомим?](https://phpsos.de/bg/blog/notfallkontakte-liste/): В критичен момент важи кого можете да достигнете и кога. Как да изградите списък с ИТ контакти за извънредни случаи, с поводи, заместници и данните, които всяко обаждане изисква.
- [Колко струва хакнат сървър: разходните пера](https://phpsos.de/bg/blog/kostenposten-eines-hacks/): Хакнат уеб сървър струва повече от ремонта. Какви разходни пера възникват и как със собствени цифри да обосновете бюджет за превенция.
- [Уведомяване на клиентите след инцидент](https://phpsos.de/bg/blog/kunden-nach-vorfall-informieren/): Задължение или доброволно: как след инцидент да решите кого да уведомите, кои канали са сигурни и как да подготвите обслужването на клиенти.
- [Веригата в уеба: агенция, хостинг доставчик, доставчик на добавки](https://phpsos.de/bg/blog/lieferkette-agentur-hoster/): PHP2Shell показа колко звена има между един пач и Вашия уебсайт. Как да познавате веригата на уебсайта си, да я обезопасите и да поемете отпадането на отделни звена.
- [Осведоменост за сигурността при администратори и редактори: Security Awareness в уеб екипа](https://phpsos.de/bg/blog/sicherheitsbewusstsein-redaktion/): Който поддържа уебсайтове, решава ежедневно за сигурността, често без да го забелязва. Как да обучите администратори и редактори според ролята, без маратон от слайдове.
- [Упражнение за извънредни ситуации на маса: изиграване на инцидент с уеб сървър](https://phpsos.de/bg/blog/notfalluebung-am-tisch/): Упражнение на маса отнема един следобед и показва дали Вашият план за извънредни ситуации издържа. Тук ще намерите готов сценарий за инцидент на PHP уеб сървър.
- [ISO 27001 и TISAX: какво засяга уеб сървърите](https://phpsos.de/bg/blog/iso-27001-tisax-webserver/): Който поддържа ISMS по ISO 27001 или има етикет TISAX, трябва да мисли и за уеб сървърите. Тук е описано кои изисквания ги засягат и кои доказателства имат значение след PHP2Shell.
- [VdS 10000: информационна сигурност за малки и средни предприятия](https://phpsos.de/bg/blog/vds-10000-kmu/): VdS 10000 е стегната рамка за информационна сигурност в средния бизнес. Какво изисква, какво дойде ново през 2025 г. и какво означава това за уебсайтовете и уеб сървърите.
- [Lessons Learned: да станем по-добри след инцидента](https://phpsos.de/bg/blog/lessons-learned-nach-vorfall/): След инцидента е преди следващия. Структурирано обсъждане без търсене на виновни превръща една лоша седмица в измерим напредък.
- [Пач, изключване или изчакване? Помощ при решението за PHP уязвимостта](https://phpsos.de/bg/blog/patchen-abschalten-abwarten/): При критична PHP уязвимост отговорните трябва да решават бързо. Тази помощ подрежда трите варианта, посочва критерии и показва кога изчакването е допустимо.
- [WAF или ъпдейт: защо Ви трябват и двете](https://phpsos.de/bg/blog/waf-oder-update/): Web Application Firewall може да спира атаки, но не затваря уязвимост в интерпретатора на PHP. Кога WAF помага, докъде стига и как да комбинирате двете разумно.
- [Нова инсталация или почистване на сървъра? Решението след заразяване](https://phpsos.de/bg/blog/neu-aufsetzen-oder-bereinigen/): След проникване има два пътя: да почистите сървъра или да го изградите наново. Кои критерии решават и защо редът е по-важен от избора.
- [Да отстраним сами или да ангажираме доставчик? Честна преценка](https://phpsos.de/bg/blog/selbst-beheben-oder-dienstleister/): Не всяко положение със сигурността изисква външна помощ. С тези критерии и кратка самооценка решавате дали Вашият екип се справя с PHP2Shell сам или се нуждае от подкрепа.
- [Как да изберете доставчик на услуги по ИТ сигурност: 12 въпроса преди поръчката](https://phpsos.de/bg/blog/sicherheitsdienstleister-auswaehlen/): Под натиск на времето е трудно да намерите добър доставчик на услуги по сигурност. Тези дванадесет въпроса помагат да сравните офертите обективно, без да се хванете на рекламни обещания.
- [Managed хостинг или собствен сървър? Сравнение по сигурност](https://phpsos.de/bg/blog/managed-oder-eigener-server/): PHP2Shell беше стрес тест за всеки модел на експлоатация. Сравнението показва кога Managed хостингът е по-сигурен, кога собственият сървър и кои смесени форми се доказват.
- [Ъпгрейд на PHP или backport? Решението за стари системи](https://phpsos.de/bg/blog/php-upgrade-oder-backport/): За старите версии на PHP след PHP2Shell има няколко пътя: backport на дистрибуцията, трети източник, пач на изходния код, дългосрочна поддръжка или ъпгрейд. Какво струва всеки път и докога издържа.
- [Да сменим ли CMS след хака? Кога помага и кога не](https://phpsos.de/bg/blog/cms-wechsel-nach-hack/): След проникване доверието в CMS често изчезва. Но нова система рядко решава същинската причина. Кога смяната има смисъл и как да мине чисто.
- [Статични уебсайтове: по-малко PHP, по-малка повърхност за атака](https://phpsos.de/bg/blog/statische-website-alternative/): Статичният уебсайт обслужва готови HTML файлове и не се нуждае от PHP на сървъра. Това намалява значително повърхността за атака, но носи свои граници и задължения.
- [Пентест, Bug Bounty или сканиране за уязвимости? Изборът на подходящ метод за проверка](https://phpsos.de/bg/blog/pentest-bugbounty-scan/): Сканирането, тестът за проникване и Bug Bounty проверяват уебсайтовете по съвсем различен начин. Какво постига всеки метод, къде се проваля и какъв ред пасва на Вашата фирма.