# Blog: PHP2Shell, bezpieczeństwo serwerów i pomoc awaryjna

> Blog o PHP2Shell i bezpieczeństwie serwerów: sytuacja, hosting, wykrywanie, utwardzanie, bezpieczne programowanie, zarządzanie i pomoc w podejmowaniu decyzji.

Źródło: https://phpsos.de/pl/blog/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

Ocena sytuacji, instrukcje dla administratorów i pomoc w podejmowaniu decyzji dla zarządu. Uporządkowane tematycznie, każdy artykuł ze źródłami.

- [PHP2Shell: co jest udowodnione, a co nie](https://phpsos.de/pl/blog/php2shell-was-belegt-ist/): Sprawdzenie faktów dotyczących PHP2Shell: które twierdzenia pochodzą ze źródeł pierwotnych, które z doniesień medialnych i których twierdzeń nie da się obronić.
- [Dlaczego luka w PHP stała się znana przed poprawką](https://phpsos.de/pl/blog/php-luecke-vorzeitig-bekannt/): Według doniesień szczegóły PHP2Shell stały się publiczne przed upływem embarga. Wyjaśniamy przebieg i co oznacza on dla Państwa planowania łatania.
- [Urzędy wyłączają strony internetowe: czego uczy to firmy](https://phpsos.de/pl/blog/behoerden-webseiten-offline/): Moguncja, rząd krajowy Hesji i BKA prewencyjnie odłączyły strony od sieci. Czego firmy mogą się stąd nauczyć na potrzeby własnej decyzji.
- [Poziom pomarańczowy BSI: co oznacza ta klasyfikacja](https://phpsos.de/pl/blog/bsi-warnstufe-orange-erklaert/): BSI klasyfikuje PHP2Shell jako 3 / pomarańczowy. Co mówi ta skala, czego nie mówi i jak firmy zamieniają klasyfikację w decyzje.
- [Co CERT-EU i CERT-Bund radzą w sprawie PHP2Shell](https://phpsos.de/pl/blog/cert-eu-empfehlungen-php/): Oficjalne instytucje są zgodne: załatać od razu, w przeciwnym razie odizolować. Porównujemy zalecenia i pokazujemy, jak wygląda izolowanie w praktyce.
- [Reguły ochronne Cloudflare przeciw PHP2Shell: co dają, a czego nie](https://phpsos.de/pl/blog/cloudflare-waf-php2shell/): Cloudflare wcześnie wdrożył reguły ochronne przeciw PHP2Shell. Dlaczego to pomaga, dlaczego nie zastępuje aktualizacji PHP i jakie ustawienia warto sprawdzić.
- [22,6 miliona wystawionych instancji: jak właściwie ocenić liczby](https://phpsos.de/pl/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel i inni podają bardzo różne liczby dotyczące PHP2Shell. Wyjaśniamy, co policzono i która liczba naprawdę ma dla Państwa znaczenie.
- [PHP2Shell w pięć minut: briefing dla zarządu](https://phpsos.de/pl/blog/php2shell-briefing-geschaeftsfuehrung/): Luka bezpieczeństwa PHP2Shell na jednej stronie dla decydentów: sytuacja, ryzyko, pięć pytań do IT i decyzje na dziś.
- [Luka bezpieczeństwa PHP wyjaśniona prosto](https://phpsos.de/pl/blog/php-luecke-einfach-erklaert/): PHP2Shell dla nietechników: z obrazami z codziennego życia, małym słowniczkiem i trzema typowymi sytuacjami wyjściowymi, co powinni zrobić operatorzy stron.
- [PHP2Shell: 15 pytań klientów hostingu](https://phpsos.de/pl/blog/fragen-von-hosting-kunden/): Państwa strona znajduje się u dostawcy hostingu i chcą Państwo wiedzieć, co przy PHP2Shell trzeba zrobić samemu? Oto 15 najczęstszych pytań z krótkimi odpowiedziami.
- [Dlaczego aktualizacja WordPressa nie pomaga przy PHP2Shell](https://phpsos.de/pl/blog/warum-wordpress-update-nicht-hilft/): Wielu operatorów po nagłówkach zaktualizowało WordPressa i czuje się bezpiecznie. Dlaczego przy PHP2Shell to nie wystarcza i co się naprawdę liczy.
- [PHP2Shell i Log4Shell: co mają wspólnego te luki](https://phpsos.de/pl/blog/php2shell-und-log4shell/): Wielu porównuje PHP2Shell z Log4Shell z 2021 roku. Co wnosi to porównanie, gdzie kuleje i jakie lekcje z tamtego czasu pomagają dziś.
- [Masowe skanowanie w poszukiwaniu niezałatanego PHP: jak działają automatyczne ataki](https://phpsos.de/pl/blog/automatisierte-massenscans/): Po PHP2Shell atakujący automatycznie przeszukują internet w poszukiwaniu podatnych serwerów. Jak to przebiega, dlaczego wielkość nie ma znaczenia i co chroni.
- [Okno czasowe między poprawką a atakiem](https://phpsos.de/pl/blog/zeitfenster-patch-angriff/): Przy PHP2Shell próby ataków pojawiły się jeszcze przed poprawką. Wyjaśniamy fazy okna czasowego, jak zmierzyć własne i jak je skrócić.
- [Po PHP2Shell: dlaczego kolejne komunikaty są prawdopodobne](https://phpsos.de/pl/blog/weitere-php-meldungen/): PHP2Shell nie kończy się wraz z poprawką z 21 października. Dlaczego należy spodziewać się kolejnych komunikatów i jak przygotować na to swój zespół.
- [PHP2Shell: obraz sytuacji po pierwszym tygodniu](https://phpsos.de/pl/blog/lagebild-erste-woche/): Tydzień po pierwszej zaobserwowanej próbie ataku: stan poprawek, ostrzeżeń urzędów, ataków i wyłączeń, czysto rozdzielony według źródeł.
- [Niebezpieczne fałszywe porady o PHP2Shell, które teraz krążą](https://phpsos.de/pl/blog/gefaehrliche-falschtipps/): Blokowanie cookies, ukrywanie komunikatów o błędach, aktualizowanie tylko CMS: dziewięć rad o PHP2Shell, które dają fałszywe poczucie bezpieczeństwa, i co naprawdę się liczy.
- [Zmiana wersji PHP w panelu klienta hostingu](https://phpsos.de/pl/blog/php-version-hosting-aendern/): Jak przestawić wersję PHP w panelu klienta dostawcy hostingu, którą wersję wybrać i co sprawdzić przed zmianą i po niej.
- [Debian i Ubuntu: czy mój pakiet PHP jest załatany?](https://phpsos.de/pl/blog/debian-ubuntu-paket-gepatcht/): Które pakiety PHP Debian i Ubuntu poprawiły przeciw PHP2Shell, jak dokładnie porównać zainstalowany stan i na czym zawodzi dowód.
- [RHEL, AlmaLinux i Rocky Linux: sprawdzanie poprawki PHP](https://phpsos.de/pl/blog/rhel-almalinux-rocky-php/): Co Red Hat opublikował o PHP2Shell, jak na RHEL i jego klonach udokumentować stan pakietów i dlaczego przeładowanie nie wystarcza.
- [Repozytorium sury.org: pakiety PHP z zewnętrznego źródła](https://phpsos.de/pl/blog/sury-repository-php/): Wiele serwerów Debiana i Ubuntu pobiera PHP z repozytorium sury. Co to oznacza dla aktualizacji, dowodów i starych wersji PHP po PHP2Shell.
- [Repozytorium Remi: utrzymanie aktualnego PHP na systemach RHEL](https://phpsos.de/pl/blog/remi-repository-php/): Remi dostarcza aktualne wersje PHP dla rodziny RHEL, jako moduł lub instalowane równolegle. Jak sprawdzić stan po PHP2Shell i unikać zapomnianych gałęzi.
- [Dlaczego php -v pokazuje po aktualizacji ten sam numer](https://phpsos.de/pl/blog/php-v-zeigt-alte-nummer/): Aktualizacja przeszła, a php -v zgłasza starą wersję. Zwykle to backport, a nie błąd. Jak odróżnić nieszkodliwe przypadki od prawdziwych problemów.
- [Dowód CVE w changelogu pakietu](https://phpsos.de/pl/blog/cve-im-changelog-nachweisen/): Kto musi wykazać poprawkę PHP przed zarządem, audytorami lub ubezpieczycielami, potrzebuje więcej niż numeru wersji. Oto jak wpis w changelogu staje się dowodem.
- [Zmiana dostawcy hostingu po incydencie bezpieczeństwa: na co zwrócić uwagę?](https://phpsos.de/pl/blog/hoster-wechseln-nach-vorfall/): Po incydencie chęć zmiany dostawcy hostingu jest zrozumiała. Aby przeprowadzka nie zabrała ze sobą atakującego, liczą się kolejność działań i wybór nowego dostawcy.
- [Wiele wersji PHP na jednym serwerze: każdą łatać osobno](https://phpsos.de/pl/blog/mehrere-php-versionen-server/): Na wielu serwerach równolegle działają trzy, cztery lub więcej instalacji PHP. Po PHP2Shell każdą trzeba znaleźć, zaktualizować i zrestartować.
- [Wyłączanie starych wersji PHP w panelu hostingowym](https://phpsos.de/pl/blog/alte-php-versionen-abschalten/): PHP2Shell to dobry powód, by pozbyć się starych wersji PHP. Oto postępowanie w trzech fazach, aby żadna strona ani zadanie cron nie przestały działać niezauważenie.
- [Plesk: zrozumieć handlery PHP (FPM, FastCGI, moduł Apache)](https://phpsos.de/pl/blog/plesk-php-handler/): To, jakiego handlera PHP Plesk używa dla strony, decyduje o izolacji, konfiguracji i ryzyku. Porównanie z uwzględnieniem PHP2Shell.
- [CloudLinux i alt-php: co powinni wiedzieć klienci hostingu](https://phpsos.de/pl/blog/cloudlinux-alt-php/): Na serwerach z CloudLinux strony często działają na własnych pakietach alt-php. Każda z tych wersji potrzebuje własnej poprawki, a zainstalować ją może tylko operator serwera.
- [PHP na NAS, firewallach i urządzeniach: zapomniane systemy](https://phpsos.de/pl/blog/php-auf-nas-und-appliances/): PHP nie używają tylko serwery WWW. Dotknięte mogą być także systemy NAS, firewalle i urządzenia specjalistyczne z interfejsem webowym. Łatać je zwykle może tylko producent, o dostępności decydują Państwo sami.
- [PHP u dostawców chmury i PaaS: kto łata środowisko uruchomieniowe?](https://phpsos.de/pl/blog/paas-php-laufzeit/): W usługach platformowych poprawka PHP zależy od modelu działania. Rozstrzygające jest środowisko uruchomieniowe, które faktycznie obsługuje żądania, a nie środowisko lokalne czy kod aplikacji.
- [Oficjalne obrazy PHP Docker: tagi, digesty i przebudowa](https://phpsos.de/pl/blog/offizielle-php-docker-images/): Tag oficjalnego obrazu PHP to wskaźnik, który z czasem przesuwa się na nowe stany. Kto rozumie tag, wariant i digest, wybiera właściwy obraz i może udowodnić stan poprawek.
- [CI/CD: automatyczna przebudowa obrazów PHP](https://phpsos.de/pl/blog/php-images-in-ci-neu-bauen/): Obraz starzeje się nawet bez zmian w kodzie. Dzięki buildom według harmonogramu, kontroli wersji i wdrożeniu po digeście poprawki PHP niezawodnie trafiają na produkcję.
- [Wsparcie długoterminowe dla starych wersji PHP: opcje i granice](https://phpsos.de/pl/blog/langzeitsupport-alte-php-versionen/): Kto nie może od razu odejść od PHP 8.1 lub starszego, znajdzie wsparcie długoterminowe u dystrybucji, dostawców zewnętrznych i usług komercyjnych. Co dają te drogi, co jest potrzebne na piśmie i gdzie leżą granice.
- [Aktualizacja PHP w systemie Windows](https://phpsos.de/pl/blog/php-unter-windows-aktualisieren/): W Windows nie ma automatycznej aktualizacji PHP. Kto wybierze właściwy wariant, sprawdzi pobrany plik i zrestartuje wszystkie procesy, czysto wprowadzi poprawkę PHP2Shell na każdym komputerze.
- [Sygnał ostrzegawczy: serwer WWW uruchamia powłokę](https://phpsos.de/pl/blog/webserver-startet-shell/): Jeśli proces PHP-FPM lub serwera WWW uruchamia powłokę, to jeden z najsilniejszych sygnałów ostrzegawczych włamania. Oto jak sprawdzić drzewo procesów, ocenić wyjątki i stale monitorować wzorzec.
- [Znajdowanie podejrzanych procesów na serwerach Linux](https://phpsos.de/pl/blog/verdaechtige-prozesse-linux/): Szkodliwe procesy maskują się nieszkodliwymi nazwami, działają z katalogów tymczasowych lub z usuniętych plików. Kilkoma poleceniami tylko do odczytu znajdą Państwo nieprawidłowości i je ocenią.
- [Rozpoznawanie ukrytych zadań cron jako tylnej furtki](https://phpsos.de/pl/blog/cronjobs-als-hintertuer/): Atakujący używają zaplanowanych zadań, aby wrócić po oczyszczeniu. Oto jak w pełni sprawdzić crontaby, katalogi cron, timery systemd i zlecenia at oraz rozpoznać podejrzane wpisy.
- [Znajdowanie niedawno zmienionych plików na serwerze WWW](https://phpsos.de/pl/blog/geaenderte-dateien-finden/): Po możliwym włamaniu liczy się to, co zmieniło się na serwerze. Oto jak szukać według okien czasowych, prawidłowo używać mtime i ctime oraz porównywać z pakietami, Git i kopiami zapasowymi.
- [Pliki PHP w katalogu uploadu: jak prawidłowo ocenić znaleziska](https://phpsos.de/pl/blog/php-dateien-im-upload-ordner/): Plik PHP w katalogu uploadu to prawie zawsze sygnał alarmowy, ale nie każdy jest złośliwym kodem. Oto jak ocenić znalezisko bez niszczenia śladów i wyjaśnić, czy ktoś go wywołał.
- [Rozpoznawanie zaciemnionego kodu PHP](https://phpsos.de/pl/blog/verschleierter-php-code/): Nieczytelny kod PHP z eval i base64_decode to klasyczny znak wprowadzonego złośliwego kodu. Jakich wzorców szukać, jak je bezpiecznie znaleźć i kiedy zaciemnianie jest uzasadnione.
- [Sprawdzanie połączeń wychodzących serwera](https://phpsos.de/pl/blog/ausgehende-verbindungen-pruefen/): Serwer WWW odpowiada przede wszystkim na żądania. Jeśli sam nawiązuje połączenia z nieznanymi celami, może to oznaczać sterowanie przez atakujących lub wyciek danych. Oto jak sprawdzić i ograniczyć ruch wychodzący.
- [Znajdowanie obcych kont administratora w CMS i na serwerze](https://phpsos.de/pl/blog/fremde-admin-konten-finden/): Nieznany administrator to często najprostsza tylna furtka. Oto jak szukać obcych kont poziom po poziomie, także tych, które interfejs ukrywa.
- [Znajdowanie i usuwanie nieznanych kluczy SSH](https://phpsos.de/pl/blog/ssh-schluessel-pruefen/): Wprowadzony klucz SSH otwiera atakującym drzwi, nawet gdy wszystkie hasła zostały zmienione. Oto jak znaleźć każdy plik authorized_keys i sprawdzić każdy wpis.
- [Koparka kryptowalut na serwerze WWW: oznaki i działania](https://phpsos.de/pl/blog/kryptominer-auf-dem-server/): Stale pełne obciążenie CPU, choć nie przybywa odwiedzających: to może być koparka kryptowalut. Oto jak sprawdzić obciążenie, znaleźć proces i jego mechanizmy restartu oraz postępować w sposób uporządkowany.
- [Serwer rozsyła spam: znajdowanie przyczyn](https://phpsos.de/pl/blog/server-verschickt-spam/): Niedostarczalne maile, listy blokujące, skargi: gdy własny serwer wysyła spam, zwykle stoi za tym skrypt lub przejęta skrzynka. Oto jak znaleźć źródło.
- [SEO spam i obce strony w indeksie Google](https://phpsos.de/pl/blog/seo-spam-im-google-index/): Nagle pod Państwa domeną pozycjonują się strony o lekach lub podróbkach markowych towarów. Jak ustalić, skąd pochodzi SEO spam, i usunąć go z indeksu.
- [Strona przekierowuje na obce witryny](https://phpsos.de/pl/blog/website-leitet-um/): Odwiedzający trafiają na konkursy lub podejrzane sklepy, a Państwo sami nic nie widzą? Jak znaleźć warstwę, w której ukryte jest przekierowanie, i je usunąć.
- [Zabezpieczyć dowody, zanim zainstalują Państwo serwer od nowa](https://phpsos.de/pl/blog/beweise-sichern-vor-neuinstallation/): Przebudowa usuwa atakującego, ale też wszystkie ślady. Kto przed nią poświęci godzinę na zabezpieczenie dowodów, będzie mógł później powiedzieć, co się stało.
- [Przygotowanie osi czasu incydentu](https://phpsos.de/pl/blog/zeitleiste-eines-vorfalls/): Kiedy pojawił się atakujący, co robił, kiedy to zauważono? Rzetelna oś czasu odpowiada na te pytania i jest podstawą zgłoszeń, ubezpieczenia i raportu.
- [Porównywanie plików rdzenia CMS z oryginałem](https://phpsos.de/pl/blog/cms-kerndateien-vergleichen/): Porównanie z czystym oryginałem pokazuje każdy zmieniony plik, niezależnie od tego, czy skaner go zna. Jak zbudować takie porównanie dla WordPress, projektów Composera i pakietów systemowych.
- [Sprawdzanie bazy danych pod kątem wstrzykniętego kodu](https://phpsos.de/pl/blog/datenbank-auf-schadcode-pruefen/): Kto sprawdza tylko pliki, pomija połowę. Jak przeszukać treści, ustawienia, wyzwalacze i konta bazy danych pod kątem wstrzykniętego kodu, w trybie do odczytu i na kopii.
- [Skanery malware dla stron WWW: co znajdują, a czego nie](https://phpsos.de/pl/blog/grenzen-von-malware-scannern/): Skaner nic nie zgłasza, więc wszystko w porządku? Niekoniecznie. Jakie są rodzaje skanerów stron, co widzi każdy z nich i czego zasadniczo zobaczyć nie może.
- [Izolowanie pul PHP-FPM dla każdej strony](https://phpsos.de/pl/blog/php-fpm-pools-isolieren/): Osobna pula dla każdej strony to początek, a nie koniec. Jak sprawdzić istniejące pule i utwardzić gniazda, rozszerzenia, strony statusu, zasoby i logi.
- [Prawidłowe ustawienie memory_limit](https://phpsos.de/pl/blog/memory-limit-richtig-setzen/): memory_limit ogranicza pamięć na jedno żądanie PHP. Po PHP2Shell php.net zaleca tymczasowo coś odwrotnego. Co obowiązuje w normalnej pracy, w okresie przejściowym i po aktualizacji.
- [Rozsądne ograniczanie post_max_size i upload_max_filesize](https://phpsos.de/pl/blog/post-max-size-upload-limits/): Limity uploadu działają w trzech miejscach: w serwerze WWW, w PHP i w aplikacji. Jak ustawić wartości spójnie, także z wartościami przejściowymi z php.net dla PHP2Shell.
- [Wyłączanie session.upload_progress: poprawnie i na stałe](https://phpsos.de/pl/blog/session-upload-progress-abschalten/): Środek zaradczy wobec CVE-2026-115560 i jeden ze środków przejściowych dla PHP2Shell ustawia się szybko. Aby był trwały, musi stać we właściwym miejscu, być zablokowany i sprawdzany po każdej aktualizacji.
- [expose_php i nagłówki Server: ukrywanie informacji o wersji](https://phpsos.de/pl/blog/expose-php-versionsangaben/): PHP, Nginx i Apache domyślnie podają numer wersji w każdej odpowiedzi. Nie chroni to przed atakami, ale daje skanerom wygodną listę celów. Jak to wyłączyć i mimo to zachować przegląd.
- [display_errors off: wyłączanie komunikatów błędów w produkcji](https://phpsos.de/pl/blog/display-errors-produktion/): Widoczne komunikaty błędów PHP zdradzają ścieżki, nazwy baz danych i wersje. Jak wyłączyć je w PHP, we frameworku i w serwerze WWW, nie tracąc błędów z oczu.
- [php_admin_value: blokowanie ustawień przed nadpisaniem](https://phpsos.de/pl/blog/php-admin-value-sperren/): Ustawienie bezpieczeństwa niewiele daje, jeśli aplikacja zmienia je jednym wierszem kodu. Za pomocą php_admin_value i php_admin_flag określają Państwo wartości dla PHP-FPM i Apache w sposób wiążący.
- [Ustawianie limitów pamięci za pomocą systemd i cgroups](https://phpsos.de/pl/blog/speichergrenzen-systemd-cgroups/): php.net zaleca jako środek przejściowy dla PHP2Shell memory_limit=-1 i limit pamięci poza PHP. Jak ustawić ten limit za pomocą systemd i cgroups, tak aby pojedynczy proces roboczy nie pociągnął za sobą całej usługi.
- [Bezpieczna konfiguracja Nginx dla PHP](https://phpsos.de/pl/blog/nginx-fuer-php-absichern/): Większość słabych punktów w konfiguracjach Nginx dla PHP nie tkwi w Nginx, lecz w kilku wierszach lokalizacji PHP. Jak skonfigurować przekazywanie do PHP-FPM, aby wykonywane były tylko zamierzone skrypty.
- [Bezpieczna konfiguracja Apache dla PHP](https://phpsos.de/pl/blog/apache-fuer-php-absichern/): Apache jest elastyczny i właśnie to czyni go podatnym na błędy konfiguracji. Jak podłączyć PHP przez PHP-FPM, zamknąć .htaccess jako tylną furtkę i bezpiecznie ustawić najważniejsze opcje podstawowe.
- [Zakazywanie wykonywania PHP w katalogach uploadu](https://phpsos.de/pl/blog/php-in-uploads-verbieten/): Webshell potrzebuje dwóch rzeczy: katalogu, do którego można ją zapisać, i serwera, który ją wykona. Jak odebrać jej to drugie, i to w każdym zapisywalnym katalogu, nie tylko w uploads.
- [Filtrowanie żądań uploadu na brzegu: szanse i ryzyka](https://phpsos.de/pl/blog/upload-anfragen-am-rand-filtern/): Autorzy branżowi proponują blokowanie na proxy żądań uploadu poza prawdziwymi ścieżkami uploadu, dopóki PHP nie zostanie załatane. Może to pomóc, ale też sparaliżować formularze i zamówienia. Jak postępować kontrolowanie.
- [Stosowanie ModSecurity i OWASP Core Rule Set](https://phpsos.de/pl/blog/modsecurity-owasp-crs/): Własna Web Application Firewall z ModSecurity i OWASP Core Rule Set jest bezpłatna i potężna, ale nie działa sama. Jak wybrać silnik, ruszyć bez awarii i dostroić reguły.
- [Konfiguracja Fail2ban dla serwerów WWW](https://phpsos.de/pl/blog/fail2ban-fuer-webserver/): Fail2ban blokuje adresy, które wielokrotnie rzucają się w oczy w logach. Dla serwerów WWW ma gotowe filtry, a kilkoma wierszami dodają Państwo własne. Jak go skonfigurować, nie blokując siebie ani klientów.
- [Zapora dla serwera WWW: otwierać tylko niezbędne porty](https://phpsos.de/pl/blog/firewall-fuer-webserver/): Serwer WWW potrzebuje na zewnątrz zwykle tylko dwóch portów. Mimo to na wielu serwerach w internecie nasłuchują bazy danych, PHP-FPM lub panele administracyjne. Jak znaleźć otwarte usługi i zamknąć te, które nie są potrzebne.
- [Automatyczne aktualizacje zabezpieczeń na serwerach Linux](https://phpsos.de/pl/blog/automatische-sicherheitsupdates/): Według doniesień dystrybucje dostarczały backporty PHP częściowo jeszcze 21 października 2026, w dniu poprawek. Kto używa automatycznych aktualizacji zabezpieczeń, miał je szybko na serwerze. Aby działały, potrzebne są restarty, źródła zewnętrzne i kontrola.
- [Least Privilege: uprawnienia użytkownika serwera WWW](https://phpsos.de/pl/blog/rechte-des-webserver-benutzers/): Wstrzyknięty kod działa z uprawnieniami użytkownika serwera WWW. To, na co pozwala to konto, decyduje o tym, jak daleko zajdzie atakujący. Jak ograniczyć powłokę, sudo, cron, bazę danych i system plików do tego, co niezbędne.
- [Zabezpieczanie paneli administracyjnych przez IP, VPN lub dodatkową ochronę](https://phpsos.de/pl/blog/admin-bereiche-abschirmen/): Dlaczego backend strony nie musi być dostępny dla całego świata i jak go zabezpieczyć za pomocą listy adresów IP, VPN lub wstępnego logowania, bez odcinania sobie dostępu.
- [Prawidłowa konfiguracja TLS i HTTPS](https://phpsos.de/pl/blog/tls-https-richtig-konfigurieren/): Jakie wersje TLS i zestawy szyfrów powinien dziś oferować serwer WWW, na czym opierają się zalecenia i jak sprawdzić Nginx, Apache oraz wychodzące połączenia PHP.
- [Benchmarki CIS i moduły BSI dla serwerów WWW](https://phpsos.de/pl/blog/cis-benchmarks-bsi-bausteine/): Jakie standardy utwardzania istnieją dla serwerów WWW z Linuksem, czym różnią się benchmarki CIS od modułów IT-Grundschutz i jak zrobić z nich weryfikowalne wytyczne dla Państwa serwerów PHP.
- [Bezpieczne przechowywanie haseł w PHP: prawidłowe użycie password_hash](https://phpsos.de/pl/blog/passwoerter-in-php-speichern/): Jak programiści przechowują hasła w PHP za pomocą password_hash i password_verify, dobierają odpowiednią metodę i zastępują stare skróty MD5 lub SHA-1 bez resetu haseł dla wszystkich użytkowników.
- [Ochrona przed CSRF w aplikacjach PHP](https://phpsos.de/pl/blog/csrf-schutz-php/): Jak programiści zapobiegają Cross-Site Request Forgery w aplikacjach PHP: tokeny dla każdego żądania zmieniającego dane, kontrola pochodzenia w nagłówku i ciasteczka SameSite jako dodatkowa warstwa.
- [Walidacja i filtrowanie danych wejściowych w PHP za pomocą filter_var](https://phpsos.de/pl/blog/eingaben-validieren-php/): Jak programiści sprawdzają dane wejściowe w PHP za pomocą filter_var, filter_input_array i list dozwolonych, które filtry są przestarzałe i dlaczego walidacja nie zastępuje prepared statements ani kodowania wyjścia.
- [Zapobieganie command injection w PHP](https://phpsos.de/pl/blog/command-injection-php/): Jak programiści unikają command injection w PHP: zastępowanie poleceń systemowych funkcjami PHP, użycie proc_open bez powłoki, sprawdzanie argumentów i wyszukiwanie niebezpiecznych miejsc w istniejącym kodzie.
- [Zapobieganie Server-Side Request Forgery (SSRF) w PHP](https://phpsos.de/pl/blog/ssrf-in-php/): Jak programiści zapobiegają temu, aby aplikacja PHP na zlecenie obcych odpytywała systemy wewnętrzne: listy dozwolonych, ograniczenie protokołów, kontrola rozwiązanego adresu i granice w sieci.
- [Zapobieganie XML External Entities (XXE) w PHP](https://phpsos.de/pl/blog/xxe-in-php/): Jak programiści bezpiecznie przetwarzają XML w PHP: domyślne zachowanie libxml, ryzykowne opcje takie jak LIBXML_NOENT, ochrona za pomocą entity loadera i LIBXML_NO_XXE oraz typowe ukryte wejścia XML.
- [Type juggling w PHP: luźne porównania jako ryzyko bezpieczeństwa](https://phpsos.de/pl/blog/type-juggling-php/): Dlaczego luźne porównania za pomocą == w PHP mogą prowadzić do luk w zabezpieczeniach, co zmieniło się w PHP 8.0 i jak pisać odporne porównania w logowaniu, tokenach i uprawnieniach.
- [Bezpieczne liczby losowe i tokeny w PHP z random_bytes](https://phpsos.de/pl/blog/sichere-tokens-php/): Jak programiści generują w PHP tokeny dla linków do resetu hasła, kluczy API i kodów jednorazowych: kryptograficznie bezpieczne źródła, wystarczająca długość, przechowywanie jako skrót i ograniczona ważność.
- [Prawidłowa ochrona danych dostępowych i plików .env](https://phpsos.de/pl/blog/env-dateien-schuetzen/): Jak chronić hasła do baz danych, klucze API i inne sekrety w projektach PHP: pliki .env poza webroot, blokady w serwerze WWW, wąskie uprawnienia i uporządkowana wymiana po incydencie.
- [Publiczny katalog .git: niedoceniany wyciek danych](https://phpsos.de/pl/blog/git-ordner-oeffentlich/): Dlaczego webroot wdrażany przez Git może ujawnić cały kod źródłowy wraz z historią, jak to sprawdzić, natychmiast zablokować i trwale zbudować wdrażanie bez katalogu .git.
- [Pliki kopii zapasowych w webroot: .zip, .sql i .bak](https://phpsos.de/pl/blog/backup-dateien-im-webroot/): Dlaczego zrzuty baz danych, archiwa i kopie zapasowe w katalogu publicznym należą do najczęstszych wycieków danych, jak je znaleźć, zablokować i ustalić, czy zostały pobrane.
- [Pliki phpinfo(): dlaczego muszą zniknąć](https://phpsos.de/pl/blog/phpinfo-dateien-entfernen/): Po PHP2Shell wielu administratorów szybko zakłada plik info.php. Dlaczego takie pliki są wyciekiem danych, jak je znaleźć i jakie sposoby kontroli są lepsze.
- [Aktualne zależności: Composer, npm i wtyczki](https://phpsos.de/pl/blog/abhaengigkeiten-aktuell-halten/): Projekt składa się z trzech światów pakietów: Composer, npm i wtyczki CMS. Jak utrzymywać wszystkie trzy na bieżąco dzięki stałemu rytmowi, jasnej odpowiedzialności i testom.
- [Przegląd kodu pod kątem bezpieczeństwa w projektach PHP](https://phpsos.de/pl/blog/sicherheits-code-review-php/): Jak zespoły celowo przeglądają własny kod PHP pod kątem luk bezpieczeństwa: rodzaje przeglądów, krytyczne funkcje, sensowne narzędzia i lista kontrolna.
- [Bezpieczne logowanie: rejestrować błędy bez wycieku danych](https://phpsos.de/pl/blog/sicher-loggen-php/): Logi pomagają w szukaniu błędów i informatyce śledczej, ale same szybko stają się wyciekiem danych. Co aplikacje PHP powinny rejestrować, czego nigdy i jak chronić logi.
- [Zabezpieczanie API REST w PHP](https://phpsos.de/pl/blog/rest-api-php-absichern/): Interfejsy są często gorzej chronione niż strona internetowa przed nimi. Najważniejsze zasady dla API REST w PHP, od uprawnień do obiektu po ograniczanie liczby żądań.
- [Umowy z dostawcami IT: jasne uregulowanie obowiązków w zakresie bezpieczeństwa](https://phpsos.de/pl/blog/dienstleistervertrag-sicherheit/): PHP2Shell pokazał, jak często niejasne jest, kto ma łatać. Jakie obowiązki w zakresie bezpieczeństwa należą do umów z agencją, firmą hostingową i dostawcą IT.
- [Powierzenie przetwarzania danych, gdy dostawcy mają dostęp do serwerów](https://phpsos.de/pl/blog/auftragsverarbeitung-serverzugriff/): Kto wpuszcza zewnętrznych na serwery z danymi klientów, potrzebuje zwykle umowy powierzenia (AVV). Czego wymaga art. 28 RODO i jak zgodnie z ochroną danych zorganizować dostępy w sytuacji awaryjnej.
- [Zarządzanie podatnościami w średnich firmach](https://phpsos.de/pl/blog/schwachstellenmanagement-mittelstand/): Żadna średnia firma nie jest w stanie od razu obsłużyć każdego komunikatu. Szczupły cykl: rejestrowanie, ocena, decyzja i dokumentowanie sprawia, że to, co ważne, dzieje się najpierw.
- [Wiedzieć, co działa: inwentarz wszystkich stron i serwerów](https://phpsos.de/pl/blog/inventar-websites-server/): Przy PHP2Shell wielu nie zawiodła poprawka, lecz pytanie, gdzie w ogóle działa PHP. Oto jak zbudować inwentarz wszystkich stron i serwerów.
- [Zarządzanie poprawkami jako proces, a nie straż pożarna](https://phpsos.de/pl/blog/patch-management-prozess/): Kto łata tylko wtedy, gdy się pali, traci czas w razie awarii. Jak proces zarządzania poprawkami ze stałymi klasami, oknami i dowodami łączy rutynę z sytuacją awaryjną.
- [Kontakty awaryjne: kogo i kiedy trzeba poinformować?](https://phpsos.de/pl/blog/notfallkontakte-liste/): W razie awarii liczy się to, do kogo można dotrzeć i kiedy. Jak zbudować listę awaryjnych kontaktów IT z wyzwalaczami, zastępstwami i danymi, których wymaga każda rozmowa.
- [Ile kosztuje zhakowany serwer: pozycje kosztów](https://phpsos.de/pl/blog/kostenposten-eines-hacks/): Zhakowany serwer WWW generuje więcej kosztów niż sama naprawa. Jakie pozycje kosztów się pojawiają i jak własnymi liczbami uzasadnić budżet na prewencję.
- [Informowanie klientów po incydencie](https://phpsos.de/pl/blog/kunden-nach-vorfall-informieren/): Obowiązkowo czy dobrowolnie: jak po incydencie zdecydować, kogo poinformować, które kanały są bezpieczne i jak przygotować obsługę klienta.
- [Łańcuch dostaw w sieci: agencja, firma hostingowa, dostawca wtyczek](https://phpsos.de/pl/blog/lieferkette-agentur-hoster/): PHP2Shell pokazało, ile ogniw dzieli poprawkę od Państwa strony. Jak poznać łańcuch dostaw swojej strony, zabezpieczyć go i amortyzować awarie poszczególnych ogniw.
- [Świadomość bezpieczeństwa administratorów i redaktorów: security awareness w zespole WWW](https://phpsos.de/pl/blog/sicherheitsbewusstsein-redaktion/): Kto prowadzi strony internetowe, codziennie decyduje o bezpieczeństwie, często nie zdając sobie z tego sprawy. Jak szkolić administratorów i redaktorów odpowiednio do ról i bez zalewu slajdów.
- [Ćwiczenie awaryjne przy stole: przećwiczenie incydentu serwera WWW](https://phpsos.de/pl/blog/notfalluebung-am-tisch/): Ćwiczenie przy stole zajmuje jedno popołudnie i pokazuje, czy Państwa plan awaryjny się sprawdza. Znajdą tu Państwo gotowy scenariusz incydentu na serwerze WWW z PHP.
- [ISO 27001 i TISAX: czego dotyczą serwery WWW](https://phpsos.de/pl/blog/iso-27001-tisax-webserver/): Kto prowadzi SZBI według ISO 27001 lub ma etykietę TISAX, musi uwzględniać serwery WWW. Tu opisano, jakich wymagań dotyczą i jakie dowody po PHP2Shell się liczą.
- [VdS 10000: bezpieczeństwo informacji dla małych i średnich firm](https://phpsos.de/pl/blog/vds-10000-kmu/): VdS 10000 to szczupłe ramy bezpieczeństwa informacji w średnich firmach. Czego wymaga, co nowego przyniósł rok 2025 i co to oznacza dla stron internetowych i serwerów WWW.
- [Lessons learned: stać się lepszym po incydencie](https://phpsos.de/pl/blog/lessons-learned-nach-vorfall/): Po incydencie jest przed następnym. Uporządkowane omówienie bez szukania winnych zamienia zły tydzień w policzalny postęp.
- [Łatać, wyłączyć czy czekać? Pomoc w decyzji przy luce w PHP](https://phpsos.de/pl/blog/patchen-abschalten-abwarten/): Przy krytycznej luce w PHP osoby odpowiedzialne muszą decydować szybko. Ta pomoc porządkuje trzy opcje, podaje kryteria i pokazuje, kiedy czekanie jest uzasadnione.
- [WAF czy aktualizacja: dlaczego potrzebują Państwo obu](https://phpsos.de/pl/blog/waf-oder-update/): Web Application Firewall może przechwytywać ataki, ale nie zamyka luki w interpreterze PHP. Kiedy WAF pomaga, gdzie się kończy i jak sensownie połączyć jedno z drugim.
- [Zainstalować serwer od nowa czy oczyścić? Decyzja po zainfekowaniu](https://phpsos.de/pl/blog/neu-aufsetzen-oder-bereinigen/): Po włamaniu są dwie drogi: oczyścić serwer lub zbudować go od nowa. Jakie kryteria decydują i dlaczego kolejność jest ważniejsza niż wybór.
- [Naprawić samemu czy zatrudnić usługodawcę? Uczciwe rozważenie](https://phpsos.de/pl/blog/selbst-beheben-oder-dienstleister/): Nie każda sytuacja bezpieczeństwa wymaga zewnętrznej pomocy. Dzięki tym kryteriom i krótkiemu autotestowi ocenią Państwo, czy Państwa zespół poradzi sobie z PHP2Shell sam, czy potrzebuje wsparcia.
- [Wybór usługodawcy bezpieczeństwa IT: 12 pytań przed zleceniem](https://phpsos.de/pl/blog/sicherheitsdienstleister-auswaehlen/): Pod presją czasu trudno znaleźć dobrego usługodawcę bezpieczeństwa. Te dwanaście pytań pomaga rzeczowo porównać oferty i nie dać się nabrać na obietnice reklamowe.
- [Hosting zarządzany czy własny serwer? Porównanie bezpieczeństwa](https://phpsos.de/pl/blog/managed-oder-eigener-server/): PHP2Shell było testem wytrzymałościowym dla każdego modelu działania. Porównanie pokazuje, kiedy bezpieczniejszy jest hosting zarządzany, kiedy własny serwer i jakie formy mieszane się sprawdzają.
- [Aktualizacja PHP czy backport? Decyzja dla starych systemów](https://phpsos.de/pl/blog/php-upgrade-oder-backport/): Dla starych wersji PHP istnieje po PHP2Shell kilka dróg: backport dystrybucji, źródło zewnętrzne, poprawka ze źródeł, wsparcie długoterminowe lub aktualizacja. Ile jest warta każda droga i jak długo wytrzymuje.
- [Zmienić CMS po włamaniu? Kiedy to pomaga, a kiedy nie](https://phpsos.de/pl/blog/cms-wechsel-nach-hack/): Po włamaniu zaufanie do CMS często znika. Nowy system rzadko jednak usuwa prawdziwą przyczynę. Kiedy zmiana ma sens i jak przeprowadzić ją czysto.
- [Strony statyczne: mniej PHP, mniejsza powierzchnia ataku](https://phpsos.de/pl/blog/statische-website-alternative/): Strona statyczna serwuje gotowe pliki HTML i nie potrzebuje PHP na serwerze. To wyraźnie zmniejsza powierzchnię ataku, ale przynosi własne ograniczenia i obowiązki.
- [Pentest, bug bounty czy skan podatności? Wybór odpowiedniej metody kontroli](https://phpsos.de/pl/blog/pentest-bugbounty-scan/): Skan, test penetracyjny i bug bounty sprawdzają strony w zupełnie różny sposób. Co potrafi każda metoda, gdzie zawodzi i jaka kolejność pasuje do Państwa firmy.