# Słownik: PHP i bezpieczeństwo IT

> Pojęcia fachowe dotyczące PHP i bezpieczeństwa IT, krótko wyjaśnione.

Źródło: https://phpsos.de/pl/glossar/  
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

**2FA**: 2FA (uwierzytelnianie dwuskładnikowe) wymaga przy logowaniu oprócz hasła drugiego dowodu, na przykład kodu z aplikacji lub klucza bezpieczeństwa. Samo skradzione hasło już wtedy nie wystarcza. Dla wszystkich dostępów administracyjnych do CMS, panelu hostingowego i serwerów 2FA powinno być standardem. Więcej: [Jak wdrożyć uwierzytelnianie dwuskładnikowe dla dostępów administratora](https://phpsos.de/pl/ratgeber/zwei-faktor-admin/)

**Apache**: Apache HTTP Server to jeden z najstarszych i najbardziej rozpowszechnionych serwerów WWW. PHP działa w nim albo jako moduł (mod_php), albo przez PHP-FPM za pomocą FastCGI. Za pomocą plików .htaccess można dostosowywać konfigurację dla poszczególnych katalogów. Więcej: [Zabezpieczenie Apache z mod_php](https://phpsos.de/pl/server/apache-mod-php/)

**Backdoor**: Backdoor (tylna furtka) to ukryty dostęp, przez który atakujący mogą wrócić po włamaniu. Może to być plik, konto administratora, zadanie cron lub klucz SSH. Dlatego do każdego oczyszczania należy wyszukiwanie wszystkich rodzajów dostępów, a nie tylko plików. Więcej: [Backdoor w WordPressie: systematyczne wyszukiwanie tylnych furtek](https://phpsos.de/pl/ratgeber/backdoor-wordpress-finden/)

**Backport**: Backport przenosi poprawkę bezpieczeństwa do starszej wersji programu, bez przechodzenia na nową wersję. Dystrybucje Linuksa i firmy hostingowe robią to często; wyświetlany numer wersji pozostaje wtedy taki sam. To, czy backport został wprowadzony, potwierdza changelog pakietu i potwierdzenie dostawcy, a nie numer. Więcej: [Aktualizacja PHP czy backport? Decyzja dla starych systemów](https://phpsos.de/pl/blog/php-upgrade-oder-backport/)

**Brute Force**: W ataku brute force atakujący automatycznie próbuje wielu haseł do jednego konta. Celem są często logowania administratorów CMS, SSH lub FTP. Ochronę zapewniają silne hasła, uwierzytelnianie dwuskładnikowe i automatyczne blokady, takie jak Fail2ban. Więcej: [Ochrona logowania administratora przed brute force: ochrona każdego logowania](https://phpsos.de/pl/ratgeber/brute-force-login-schutz/)

**BSI**: BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) to niemiecki federalny organ ds. cyberbezpieczeństwa. Publikuje ostrzeżenia, zalecenia i standardy, takie jak IT-Grundschutz. W sprawie PHP2Shell BSI ogłosiło poziom ostrzeżenia 3 (pomarańczowy) i zaleciło natychmiastową aktualizację. Więcej: [Co BSI zaleca w sprawie PHP2Shell](https://phpsos.de/pl/compliance/bsi-empfehlungen/)

**CDN**: CDN (Content Delivery Network) dostarcza treści przez wiele rozproszonych serwerów i stoi tym samym przed właściwą stroną. Wiele sieci CDN oferuje dodatkowo reguły WAF, na przykład Cloudflare przeciw PHP2Shell. Ochrona działa tylko dla ruchu przechodzącego przez CDN i nie zastępuje aktualizacji PHP. Więcej: [Reguły ochronne Cloudflare przeciw PHP2Shell: co dają, a czego nie](https://phpsos.de/pl/blog/cloudflare-waf-php2shell/)

**CERT-Bund**: CERT-Bund to Computer Emergency Response Team niemieckiej administracji federalnej przy BSI. Publikuje usługi ostrzegawcze i informacyjne o lukach i powiadamia operatorów sieci o podatnych systemach. CERT-Bund ostrzegał także w sprawie PHP2Shell. Więcej: [Co CERT-EU i CERT-Bund radzą w sprawie PHP2Shell](https://phpsos.de/pl/blog/cert-eu-empfehlungen-php/)

**CERT-EU**: CERT-EU to zespół cyberbezpieczeństwa dla instytucji, organów i agencji Unii Europejskiej. Według raportów CERT-EU uważa za możliwe, że w przypadku PHP2Shell dotknięte są wersje od PHP 5. Zaleca izolowanie aplikacji dostępnych publicznie, jeśli nie da się ich załatać w krótkim czasie. Więcej: [Co CERT-EU i CERT-Bund radzą w sprawie PHP2Shell](https://phpsos.de/pl/blog/cert-eu-empfehlungen-php/)

**CGI**: CGI (Common Gateway Interface) to stary interfejs, w którym serwer WWW uruchamia zewnętrzny program dla każdego żądania i zwraca jego wynik. Jest prosty, ale wolny, i w PHP został w dużej mierze zastąpiony przez FastCGI. Stare konfiguracje CGI nadal spotyka się w niektórych systemach hostingowych i systemach Windows. Więcej: [CGI i FastCGI: podstawy](https://phpsos.de/pl/php/cgi-und-fastcgi/)

**cgroups**: cgroups (Control Groups) to funkcja jądra Linuksa, za pomocą której można ograniczać pamięć, CPU i inne zasoby dla grup procesów. Korzystają z nich kontenery i systemd, na przykład z MemoryMax. php.net zaleca jako środek tymczasowy przeciw PHP2Shell limit pamięci ustawiony przez kontener lub cgroup zamiast przez RLIMIT_AS lub RLIMIT_DATA. Więcej: [Ustawianie limitów pamięci za pomocą systemd i cgroups](https://phpsos.de/pl/blog/speichergrenzen-systemd-cgroups/)

**Chain of Custody**: Chain of custody (łańcuch dowodowy) dokumentuje bez luk, kto, kiedy zabezpieczył, przekazał i opracował dany dowód. Uzupełniony sumami kontrolnymi dowodzi, że dane nie zostały zmienione. Bez tej dokumentacji ślady tracą wartość przed sądem lub wobec ubezpieczycieli. Więcej: [Informatyka śledcza po ataku na serwer WWW](https://phpsos.de/pl/leistungen/it-forensik/)

**Changelog**: Changelog wymienia zmiany w wersji programu lub pakietu, przy poprawkach bezpieczeństwa zwykle z numerem CVE. W Debianie i Ubuntu changelog pakietu pokazuje apt-get changelog, w rodzinie RHEL rpm -q --changelog. W ten sposób można udokumentować backport także przy niezmienionym numerze wersji. Więcej: [Dowód CVE w changelogu pakietu](https://phpsos.de/pl/blog/cve-im-changelog-nachweisen/)

**CLI**: CLI (Command Line Interface) to PHP w wierszu poleceń, na przykład dla zadań cron, poleceń konsolowych CMS i Composera. PHP w CLI może być inną wersją niż PHP obsługujące strony internetowe. Polecenie php -v pokazuje więc tylko wersję z wiersza poleceń; obie ścieżki muszą być załatane. Więcej: [PHP w wierszu poleceń (CLI)](https://phpsos.de/pl/php/php-cli/)

**CloudLinux**: CloudLinux to dystrybucja Linuksa dla hostingu współdzielonego, która rozdziela klientów w ograniczonych środowiskach. Za pomocą alt-php udostępnia obok siebie wiele wersji PHP, także starszych. Każda z tych wersji musi być załatana osobno. Więcej: [CloudLinux i alt-php: co powinni wiedzieć klienci hostingu](https://phpsos.de/pl/blog/cloudlinux-alt-php/)

**Command Injection**: Przy command injection dane wejściowe trafiają bez sprawdzenia do polecenia systemowego, które wykonuje aplikacja. Atakujący może w ten sposób uruchamiać własne polecenia z uprawnieniami serwera WWW. Ochronę zapewniają rezygnacja z wywołań powłoki tam, gdzie to możliwe, oraz konsekwentne maskowanie za pomocą escapeshellarg(). Więcej: [Zapobieganie command injection w PHP](https://phpsos.de/pl/blog/command-injection-php/)

**Composer**: Composer to menedżer pakietów dla PHP. Instaluje biblioteki zgodnie z danymi w composer.json i zapisuje dokładne wersje w composer.lock. Poleceniem composer audit można sprawdzić zainstalowane pakiety pod kątem znanych luk bezpieczeństwa; luk w samym PHP to polecenie nie znajdzie. Więcej: [Composer: menedżer pakietów dla PHP](https://phpsos.de/pl/php/composer/)

**cPanel**: cPanel to panel zarządzania hostingiem, z WHM jako interfejsem dla administratora serwera. Wersje PHP są tam zwykle udostępniane przez własne pakiety (EasyApache). To, które buildy są załatane, potwierdzają stan pakietów i firma hostingowa. Więcej: [cPanel i WHM: zabezpieczenie PHP](https://phpsos.de/pl/server/cpanel/)

**Credential Stuffing**: W credential stuffing atakujący próbują w innych usługach danych logowania z wcześniejszych wycieków. Działa to dlatego, że wielu ludzi używa haseł wielokrotnie. Ochronę zapewniają unikalne hasła dla każdej usługi i uwierzytelnianie dwuskładnikowe. Więcej: [Jak wdrożyć uwierzytelnianie dwuskładnikowe dla dostępów administratora](https://phpsos.de/pl/ratgeber/zwei-faktor-admin/)

**CSP**: CSP (Content Security Policy) to nagłówek, który określa, z jakich źródeł strona może ładować skrypty, obrazy i inne treści. Utrudnia XSS i wprowadzanie obcych skryptów, na przykład przy skimmingu. Restrykcyjną CSP trzeba starannie przetestować, aby strona nadal działała. Więcej: [Nagłówki bezpieczeństwa stron WWW: jak je prawidłowo ustawić](https://phpsos.de/pl/ratgeber/sicherheits-header/)

**CSRF**: CSRF (Cross-Site Request Forgery) skłania przeglądarkę zalogowanego użytkownika do niezamierzonego wykonania akcji na innej stronie. Typowe są zmiany w panelach administracyjnych. Ochronę zapewniają losowe tokeny w formularzach i ciasteczka z atrybutem SameSite. Więcej: [Ochrona przed CSRF w aplikacjach PHP](https://phpsos.de/pl/blog/csrf-schutz-php/)

**CVE**: CVE (Common Vulnerabilities and Exposures) to używany na całym świecie rejestr, który każdej znanej luce bezpieczeństwa nadaje jednoznaczny numer, na przykład CVE-2026-109618. Numer sprawia, że komunikaty producentów, organów i dystrybucji są porównywalne. Po numerze CVE można także sprawdzić w changelogu pakietu, czy poprawka została wprowadzona. Więcej: [Dowód CVE w changelogu pakietu](https://phpsos.de/pl/blog/cve-im-changelog-nachweisen/)

**CVSS**: CVSS (Common Vulnerability Scoring System) ocenia wagę luki w skali od 0 do 10. Ocena uwzględnia na przykład to, czy atak jest możliwy przez sieć i bez logowania. Luki PHP2Shell mają po CVSS v4.0 9,2; o konkretnym ryzyku w Państwa środowisku sama ta wartość nic nie mówi.

**Cykl wydawniczy**: Każda wersja PHP otrzymuje najpierw poprawki błędów, a następnie przez pewien czas już tylko poprawki bezpieczeństwa. Kiedy kończy się wsparcie dla danej wersji, projekt PHP publikuje na php.net w sekcji wspieranych wersji. Według php.net PHP 8.2 osiąga koniec wsparcia 31.12.2026. Więcej: [Wersje PHP i cykl wydawniczy](https://phpsos.de/pl/php/release-zyklus/)

**DDoS**: Atak DDoS (Distributed Denial of Service) przeciąża usługę żądaniami z wielu źródeł, aż przestanie być dostępna. Dane zasadniczo nie są przy tym wykradane. DDoS należy odróżniać od exploitu, który celowo wykorzystuje lukę. Więcej: [DDoS czy atak hakerski? Jak prawidłowo ocenić atak](https://phpsos.de/pl/ratgeber/ddos-oder-exploit/)

**Defacement**: Przy defacement atakujący widocznie zmieniają stronę główną lub treści strony internetowej, na przykład wstawiając komunikaty lub obrazy. Jest to rzucające się w oczy, ale często stanowi tylko widoczny znak głębszego włamania. Do czasu wyjaśnienia stronę należy traktować jako skompromitowaną. Więcej: [Strona zhakowana, co robić? Zdalna pomoc awaryjna](https://phpsos.de/pl/leistungen/website-gehackt-notfallhilfe/)

**Deserializacja**: Deserializacja zamienia zapisane dane z powrotem w obiekty, w PHP na przykład za pomocą unserialize(). Jeśli dane pochodzą od użytkowników, atakujący mogą skonstruować obiekty tak, że przy ich ładowaniu uruchomi się niepożądany kod. Dla danych użytkowników bezpieczniejszym wyborem jest JSON. Więcej: [Niebezpieczna deserializacja w PHP: unserialize i bezpieczeństwo](https://phpsos.de/pl/ratgeber/deserialisierung-php/)

**disable_functions**: disable_functions to ustawienie php.ini, którym wyłącza się pojedyncze funkcje PHP, zazwyczaj te służące do wykonywania poleceń systemowych. Można je ustawić tylko w php.ini, nie w kodzie aplikacji. Utrudnia życie atakującym, ale nie zastępuje ani aktualizacji, ani prawidłowych uprawnień. Więcej: [Jak prawidłowo stosować PHP disable_functions](https://phpsos.de/pl/ratgeber/disable-functions/)

**display_errors**: display_errors określa, czy PHP wyświetla komunikaty o błędach bezpośrednio w przeglądarce. W produkcji wartość powinna wynosić Off, a błędy zapisuje się zamiast tego do dziennika za pomocą log_errors. Widoczne komunikaty zdradzają bowiem ścieżki, wersje i fragmenty kodu. Więcej: [display_errors off: wyłączanie komunikatów błędów w produkcji](https://phpsos.de/pl/blog/display-errors-produktion/)

**EDR**: EDR (Endpoint Detection and Response) to oprogramowanie na serwerach i stanowiskach pracy, które obserwuje procesy, dostępy do plików i połączenia sieciowe oraz zgłasza lub zatrzymuje podejrzane zachowania. Na serwerach WWW może rozpoznać na przykład to, że PHP-FPM uruchamia powłokę. Ponieważ dla PHP2Shell nie ma potwierdzonych IOC, taka analiza zachowania jest szczególnie ważna. Więcej: [Sygnał ostrzegawczy: serwer WWW uruchamia powłokę](https://phpsos.de/pl/blog/webserver-startet-shell/)

**Embargo**: Embargo to uzgodniony termin, w którym szczegóły luki pozostają poufne do czasu przygotowania poprawek. Dzięki temu producenci i dystrybucje mogą przygotować aktualizacje. W przypadku PHP2Shell szczegóły stały się według kilku raportów publiczne przed upływem embargo; php.net zapowiedział więc poprawki 20.10.2026. Więcej: [Dlaczego luka w PHP stała się znana przed poprawką](https://phpsos.de/pl/blog/php-luecke-vorzeitig-bekannt/)

**End of Life**: End of Life (EOL) oznacza, że wersja oprogramowania nie otrzymuje już od producenta żadnych aktualizacji, także poprawek bezpieczeństwa. PHP 8.1 i starsze nie otrzymują od projektu PHP oficjalnych aktualizacji; dla 7.4, 8.0 i 8.1 istnieją tylko minimalne backporty źródłowe. Systemy z oprogramowaniem EOL potrzebują planu modernizacji. Więcej: [Koniec wsparcia PHP (End of Life): ryzyko przestarzałych wersji](https://phpsos.de/pl/ratgeber/php-end-of-life-risiken/)

**Exploit**: Exploit to kod lub metoda, która faktycznie wykorzystuje konkretną lukę. Gdy tylko pojawi się poprawka, atakujący mogą ją przeanalizować i wyprowadzić z niej exploity. Dlatego po opublikowaniu poprawki czas do pierwszych ataków często wyraźnie się skraca. Więcej: [Okno czasowe między poprawką a atakiem](https://phpsos.de/pl/blog/zeitfenster-patch-angriff/)

**expose_php**: expose_php steruje tym, czy PHP ujawnia swoją wersję w nagłówku HTTP X-Powered-By. W środowisku produkcyjnym ustawienie powinno mieć wartość Off, aby atakujący nie widzieli od razu, jaka wersja PHP działa. To ochrona informacji, a nie zamiennik aktualizacji. Więcej: [expose_php i nagłówki Server: ukrywanie informacji o wersji](https://phpsos.de/pl/blog/expose-php-versionsangaben/)

**Fail2ban**: Fail2ban czyta pliki logów i po powtarzających się nieudanych próbach tymczasowo blokuje adresy IP w zaporze. Typowe zastosowania to SSH, poczta i logowania administratorów stron. Przeciw rozproszonym atakom z wielu adresów pomaga tylko w ograniczonym stopniu. Więcej: [Konfiguracja Fail2ban dla serwerów WWW](https://phpsos.de/pl/blog/fail2ban-fuer-webserver/)

**FastCGI**: FastCGI to protokół, którym serwer WWW przekazuje żądania do stale działających procesów programów, na przykład do PHP-FPM. W odróżnieniu od klasycznego CGI nie uruchamia się nowego procesu dla każdego żądania. Ponieważ procesy obsługują kolejno wiele żądań, po aktualizacjach ważny jest prawidłowy restart. Więcej: [CGI i FastCGI: podstawy](https://phpsos.de/pl/php/cgi-und-fastcgi/)

**FrankenPHP**: FrankenPHP to nowoczesny serwer aplikacji dla PHP oparty na serwerze WWW Caddy. PHP jest tam osadzone bezpośrednio, a w trybie worker aplikacja pozostaje w pamięci między żądaniami. Według zespołu PHP FrankenPHP należy do dotkniętych trybów pracy; po aktualizacji serwer trzeba zrestartować z nowym PHP. Więcej: [Zabezpieczenie FrankenPHP](https://phpsos.de/pl/server/frankenphp/)

**GHSA**: GHSA to identyfikator GitHub Security Advisory, czyli komunikatu bezpieczeństwa w bazie GitHuba. Wiele projektów open source, także PHP, publikuje tam swoje komunikaty dodatkowo obok numeru CVE. Dla PHP2Shell są to GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp.

**Hosting współdzielony**: W hostingu współdzielonym (shared hosting) wielu klientów dzieli serwer, który prowadzi firma hostingowa. Firma hostingowa odpowiada za PHP, system operacyjny i serwer WWW, klient za swoją aplikację. W przypadku PHP2Shell oznacza to: zapytać firmę hostingową o stan poprawek i sprawdzić własną stronę pod kątem śladów. Więcej: [Hosting współdzielony: co robi hoster, a co muszą zrobić Państwo](https://phpsos.de/pl/server/shared-hosting/)

**HSTS**: HSTS (HTTP Strict Transport Security) to nagłówek, którym strona informuje przeglądarkę, że przez określony czas ma być wywoływana wyłącznie przez HTTPS. Zapobiega to obniżeniu połączeń do nieszyfrowanego HTTP. Przed włączeniem HTTPS powinno niezawodnie działać na wszystkich objętych domenach. Więcej: [Nagłówki bezpieczeństwa stron WWW: jak je prawidłowo ustawić](https://phpsos.de/pl/ratgeber/sicherheits-header/)

**.htaccess**: Pliki .htaccess to pliki konfiguracyjne obowiązujące w poszczególnych katalogach, dla Apache i zgodnych serwerów, takich jak LiteSpeed. CMS używają ich do przekierowań i ochrony dostępu, atakujący do ukrytych przekierowań. Nginx nie interpretuje .htaccess; reguły ochronne trzeba tam umieścić w konfiguracji serwera. Więcej: [Bezpieczna konfiguracja Apache dla PHP](https://phpsos.de/pl/blog/apache-fuer-php-absichern/)

**Image Digest**: Image digest to wartość skrótu (sha256), która jednoznacznie określa zawartość obrazu kontenera. W odróżnieniu od tagu, takiego jak php:8.3-fpm, który można przesunąć na nowe buildy, digest nigdy się nie zmienia. Kto przypina obrazy przez digest, musi go po aktualizacji bezpieczeństwa świadomie zaktualizować. Więcej: [Oficjalne obrazy PHP Docker: tagi, digesty i przebudowa](https://phpsos.de/pl/blog/offizielle-php-docker-images/)

**Informatyka śledcza**: Informatyka śledcza (IT-Forensik) bada metodycznie po incydencie, co się stało: jak atakujący się dostał, co zrobił i jakie dane zostały dotknięte. Podstawą są zabezpieczone kopie nośników danych, pamięci operacyjnej i logów. Wyniki są ważne dla obowiązków zgłoszeniowych, ubezpieczenia i zawiadomienia o przestępstwie. Więcej: [Informatyka śledcza po ataku na serwer WWW](https://phpsos.de/pl/leistungen/it-forensik/)

**ini_set()**: ini_set() to funkcja PHP, którą skrypt zmienia ustawienia w czasie działania. To, co skrypt może zmienić, zależy od trybu zmiany danego ustawienia. Ponieważ także złośliwy kod może wywołać ini_set(), ustawienia ochronne należą do konfiguracji serwera lub puli, a nie do kodu aplikacji. Więcej: [php.ini wyjaśniony: budowa, poziomy i pierwszeństwo](https://phpsos.de/pl/php/php-ini-erklaert/)

**IOC**: IOC (Indicator of Compromise) to konkretne ślady ataku, na przykład nazwy plików, wartości skrótu, adresy IP lub domeny. Pozwalają celowo sprawdzić systemy pod kątem znanego ataku. Dla PHP2Shell nie ma opublikowanych, potwierdzonych IOC; wykrywanie opiera się na analizie zachowania. Więcej: [Czy już doszło do naruszenia? Oznaki po PHP2Shell](https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/)

**ISO 27001**: ISO/IEC 27001 to międzynarodowa norma dla systemów zarządzania bezpieczeństwem informacji (ISMS). Wymaga uporządkowanego postępowania z ryzykami, środkami i usprawnieniami, w tym zarządzania lukami i incydentami. Firmy mogą się według niej certyfikować. Więcej: [ISO 27001 i TISAX: czego dotyczą serwery WWW](https://phpsos.de/pl/blog/iso-27001-tisax-webserver/)

**IT-Grundschutz**: IT-Grundschutz BSI to metodyka z modułami i wymaganiami dla bezpieczeństwa informacji w firmach i urzędach. Istnieją osobne moduły, na przykład dla serwerów WWW i aplikacji internetowych. Można go wykorzystać jako podstawę dla ISMS lub certyfikacji. Więcej: [Benchmarki CIS i moduły BSI dla serwerów WWW](https://phpsos.de/pl/blog/cis-benchmarks-bsi-bausteine/)

**JIT**: JIT (kompilator Just-in-Time) tłumaczy często wykonywany kod PHP na kod maszynowy w czasie działania programu. Pojawił się w PHP 8.0 i jest częścią OPcache. Dla typowych stron internetowych zysk wydajności jest zwykle niewielki, większy przy zadaniach wymagających dużej mocy obliczeniowej. Więcej: [JIT i wydajność w PHP 8](https://phpsos.de/pl/php/jit-und-performance/)

**Kontener**: Kontener to wyizolowane środowisko uruchomieniowe, które uruchamia aplikację ze wszystkimi zależnościami z obrazu, na przykład za pomocą Dockera. PHP w kontenerze pochodzi z obrazu, a nie z systemu gospodarza. Aktualizacja na hoście nie łata go więc; obraz trzeba zbudować od nowa, a kontener zrestartować. Więcej: [Eksploatacja PHP w kontenerach](https://phpsos.de/pl/php/php-in-containern/)

**Kontrola integralności**: Przy kontroli integralności pliki porównuje się ze znanym stanem oryginalnym, zwykle za pomocą sum kontrolnych. Wiele systemów CMS oferuje do tego własne polecenia, na przykład WordPress, Nextcloud czy Matomo. Takie porównanie nie obejmuje zmodyfikowanych plików, przesłanych plików ani zawartości bazy danych. Więcej: [Porównywanie plików rdzenia CMS z oryginałem](https://phpsos.de/pl/blog/cms-kerndateien-vergleichen/)

**Koparka kryptowalut**: Koparka kryptowalut (kryptominer) to złośliwe oprogramowanie, które na cudzych serwerach wylicza kryptowalutę. Typowe oznaki to stale wysokie obciążenie procesora i nieznane procesy. Koparka pokazuje, że atakujący może wykonywać kod; serwer należy wtedy uznać za skompromitowany. Więcej: [Koparka kryptowalut na serwerze WWW: oznaki i działania](https://phpsos.de/pl/blog/kryptominer-auf-dem-server/)

**Kopia zapasowa 3-2-1**: Reguła 3-2-1 zaleca trzy kopie danych na dwóch różnych nośnikach, z czego jedną w innym miejscu. Co najmniej jedna kopia powinna być niemożliwa do zmiany z serwera, aby atakujący nie mogli jej usunąć ani zaszyfrować. Kopia zapasowa liczy się dopiero wtedy, gdy odtwarzanie zostało przetestowane. Więcej: [Strategia backupu serwera: backupy według reguły 3-2-1](https://phpsos.de/pl/ratgeber/backups-3-2-1/)

**Least Privilege**: Least privilege (zasada minimalnych uprawnień) oznacza, że każdy użytkownik i każdy proces otrzymuje tylko te uprawnienia, których naprawdę potrzebuje. Jeśli PHP działa ze skromnymi uprawnieniami, atakujący po włamaniu może narobić mniej szkód. Dotyczy to użytkowników systemowych, uprawnień do plików, kont bazodanowych i dostępów administracyjnych. Więcej: [Least Privilege: uprawnienia użytkownika serwera WWW](https://phpsos.de/pl/blog/rechte-des-webserver-benutzers/)

**Lessons Learned**: Lessons learned to omówienie incydentu po jego zakończeniu: co się stało, co poszło dobrze, co trzeba zmienić? Celem są konkretne działania z osobami odpowiedzialnymi i terminami, a nie wskazywanie winnych. Wyniki trafiają do planu awaryjnego, procesu poprawek i szkoleń. Więcej: [Lessons learned: stać się lepszym po incydencie](https://phpsos.de/pl/blog/lessons-learned-nach-vorfall/)

**LFI**: LFI (Local File Inclusion) występuje wtedy, gdy aplikacja włącza lokalny plik, którego ścieżkę może kształtować atakujący. W ten sposób można odczytywać pliki konfiguracyjne lub w pewnych okolicznościach wykonać wprowadzony kod. Ochronę zapewniają stałe listy dozwolonych zamiast nazw plików z danych wpisanych przez użytkownika. Więcej: [Zapobieganie Local File Inclusion w PHP: LFI i RFI](https://phpsos.de/pl/ratgeber/lfi-rfi/)

**LiteSpeed**: LiteSpeed to serwer WWW, który jest w dużej mierze zgodny z konfiguracjami Apache, takimi jak .htaccess, i łączy PHP przez własny interfejs LSAPI. Jest rozpowszechniony u firm hostingowych; OpenLiteSpeed to wersja swobodna. Według zespołu PHP LiteSpeed należy do trybów pracy dotkniętych przez PHP2Shell. Więcej: [LiteSpeed i LSAPI: aktualizacja PHP](https://phpsos.de/pl/server/litespeed/)

**memory_limit**: memory_limit ogranicza, ile pamięci operacyjnej może zająć pojedynczy skrypt PHP; domyślnie jest to 128 MB. Po osiągnięciu limitu PHP przerywa działanie z błędem braku pamięci. Przeciw CVE-2026-109618 php.net zaleca tymczasowo memory_limit=-1, ustawione na stałe, oraz limit pamięci ustawiony przez kontener lub cgroup. Więcej: [Prawidłowe ustawienie memory_limit](https://phpsos.de/pl/blog/memory-limit-richtig-setzen/)

**mod_php**: mod_php to moduł PHP dla serwera WWW Apache. PHP działa wtedy bezpośrednio w procesie Apache i zwykle z jego uprawnieniami użytkownika. Zespół PHP ocenia ryzyko związane z PHP2Shell w przypadku mod_php jako najwyższe; pokazano tam exploit, zanim jeszcze zacznie działać kod aplikacji. Więcej: [mod_php wyjaśniony: PHP w procesie Apache](https://phpsos.de/pl/php/mod-php-erklaert/)

**ModSecurity**: ModSecurity to popularna zapora WAF o otwartym kodzie, działająca jako moduł w Apache, Nginx lub innych serwerach WWW. Ocenia żądania na podstawie reguł i może je rejestrować lub blokować. Zwykle stosuje się ją razem z OWASP Core Rule Set. Więcej: [Stosowanie ModSecurity i OWASP Core Rule Set](https://phpsos.de/pl/blog/modsecurity-owasp-crs/)

**Monitoring**: Monitoring to bieżący nadzór nad systemami, na przykład dostępnością, obciążeniem, plikami logów i zmianami w plikach. Monitoring bezpieczeństwa szuka celowo nieprawidłowości, takich jak nowe pliki PHP lub powłoki uruchamiane przez serwer WWW. Pomaga tylko wtedy, gdy ktoś ocenia komunikaty w krótkim czasie. Więcej: [Monitoring bezpieczeństwa dla serwerów WWW](https://phpsos.de/pl/leistungen/security-monitoring/)

**Nagłówki bezpieczeństwa**: Nagłówki bezpieczeństwa to nagłówki odpowiedzi HTTP, które narzucają przeglądarce reguły ochronne, na przykład Content-Security-Policy, Strict-Transport-Security lub X-Content-Type-Options. Chronią odwiedzających przed pewnymi atakami w przeglądarce. Przed lukami na serwerze, takimi jak PHP2Shell, nie pomagają. Więcej: [Nagłówki bezpieczeństwa stron WWW: jak je prawidłowo ustawić](https://phpsos.de/pl/ratgeber/sicherheits-header/)

**Nginx**: Nginx to rozpowszechniony serwer WWW i reverse proxy. Nie wykonuje PHP sam, lecz przekazuje żądania przez FastCGI do PHP-FPM. Ważna jest konfiguracja, która przekazuje do PHP tylko prawdziwe pliki PHP i pomija katalogi przesyłanych plików. Więcej: [Zabezpieczenie Nginx z PHP-FPM](https://phpsos.de/pl/server/nginx-php-fpm/)

**NIS2**: NIS2 to dyrektywa UE, która dla wielu firm i podmiotów określa obowiązki w zakresie zarządzania ryzykiem i zgłaszania incydentów bezpieczeństwa. Obejmuje wyraźnie więcej branż i wielkości przedsiębiorstw niż poprzednie uregulowanie. To, czy Państwa firma jest objęta, należy ustalić na podstawie krajowego wdrożenia i przy pomocy prawnej. Więcej: [NIS2 a bezpieczeństwo serwerów WWW](https://phpsos.de/pl/compliance/nis2/)

**OPcache**: OPcache to dołączana do PHP pamięć podręczna bajtkodu. Przechowuje już przetłumaczony kod we wspólnej pamięci, aby pliki PHP nie były kompilowane od nowa przy każdym żądaniu. Po aktualizacji lub oczyszczeniu trzeba opróżnić pamięć podręczną albo zrestartować PHP, w przeciwnym razie może nadal działać stary kod. Więcej: [OPcache wyjaśniony: pamięć podręczna bajtkodu PHP](https://phpsos.de/pl/php/opcache/)

**open_basedir**: open_basedir ogranicza, do jakich katalogów skrypty PHP mogą sięgać funkcjami plikowymi. Na serwerach z wieloma stronami zapobiega to temu, by jedna strona po prostu czytała pliki innej. To nie jest pełna izolacja; należą do niej także oddzielni użytkownicy systemowi i pule FPM. Więcej: [open_basedir i izolacja każdej strony](https://phpsos.de/pl/ratgeber/open-basedir/)

**Out of Memory**: Out of Memory oznacza stan, w którym program nie dostaje więcej pamięci i musi przerwać działanie. W PHP dzieje się tak po przekroczeniu memory_limit. W przypadku CVE-2026-109618 takie przerwanie może zatrzymać PHP w chwili, gdy dane żądania są zainicjowane tylko częściowo. Więcej: [memory_limit i Out-of-Memory: co dzieje się w środku](https://phpsos.de/pl/php/out-of-memory/)

**OWASP CRS**: OWASP Core Rule Set (CRS) to swobodnie dostępny zestaw reguł dla ModSecurity i zgodnych zapór WAF. Rozpoznaje typowe klasy ataków, takie jak SQL injection czy command injection. Reguły trzeba dopasować do aplikacji, w przeciwnym razie blokują także prawidłowe żądania. Więcej: [Stosowanie ModSecurity i OWASP Core Rule Set](https://phpsos.de/pl/blog/modsecurity-owasp-crs/)

**OWASP Top 10**: OWASP Top 10 to regularnie aktualizowana lista najważniejszych zagrożeń dla aplikacji internetowych, wydawana przez niekomercyjną organizację OWASP Foundation. Stanowi podstawę dla programowania, kontroli i szkoleń. Uzupełniająco OWASP oferuje Cheat Sheets z konkretnymi środkami zaradczymi.

**Oś czasu**: Oś czasu (timeline) porządkuje chronologicznie wszystkie ślady incydentu: wpisy w logach, zmiany w plikach, logowania, procesy. Pokazuje, kiedy atak się zaczął i co działo się w jakiej kolejności. Ważna jest jednolita strefa czasowa, najlepiej UTC. Więcej: [Przygotowanie osi czasu incydentu](https://phpsos.de/pl/blog/zeitleiste-eines-vorfalls/)

**PECL**: PECL (PHP Extension Community Library) to katalog rozszerzeń PHP napisanych w C, które nie należą do standardowego zakresu. Takie rozszerzenia muszą pasować do zainstalowanej wersji PHP. Po zmianie głównej wersji PHP trzeba je często zbudować od nowa lub zastąpić. Więcej: [Rozszerzenia PHP (extensions): jak je rozumieć](https://phpsos.de/pl/php/php-erweiterungen/)

**PHP**: PHP to język skryptowy, który działa głównie na serwerach WWW i generuje tam strony internetowe. Wiele popularnych systemów CMS i sklepów, takich jak WordPress, TYPO3 czy Shopware, jest napisanych w PHP. Luka w interpreterze PHP dotyczy więc wszystkich działających na nim aplikacji, niezależnie od stanu ich własnych aktualizacji. Więcej: [Czym jest PHP? Język programowania wyjaśniony](https://phpsos.de/pl/php/was-ist-php/)

**php-cgi**: php-cgi to program PHP do pracy przez CGI lub FastCGI. Według zespołu PHP należy do trybów pracy dotkniętych przez PHP2Shell. Tam, gdzie php-cgi jest jeszcze używane, warto sprawdzić, czy możliwe jest przejście na PHP-FPM. Więcej: [php-cgi: stare obciążenie z ryzykiem](https://phpsos.de/pl/server/php-cgi/)

**PHP-FPM**: PHP-FPM (FastCGI Process Manager) to osobna usługa, która zarządza procesami PHP w pulach i przyjmuje żądania od serwera WWW przez FastCGI. Jest dziś zwykłym trybem pracy z Nginx i na wielu serwerach Apache. Po aktualizacji PHP trzeba zrestartować PHP-FPM, aby nie działały dalej stare procesy. Więcej: [PHP-FPM wyjaśniony: menedżer procesów, pule i workery](https://phpsos.de/pl/php/php-fpm-erklaert/)

**php.ini**: Plik php.ini to centralny plik konfiguracyjny PHP. Określa limity oraz ustawienia bezpieczeństwa i błędów, na przykład memory_limit lub display_errors. Często dla każdej SAPI (FPM, CLI, Apache) istnieje osobny plik php.ini, który trzeba utrzymywać oddzielnie. Więcej: [php.ini wyjaśniony: budowa, poziomy i pierwszeństwo](https://phpsos.de/pl/php/php-ini-erklaert/)

**PHP2Shell**: PHP2Shell to nazwa dwóch krytycznych luk w samym PHP, CVE-2026-109618 i CVE-2026-109619, każda z oceną CVSS v4.0 9,2. Umożliwiają zdalne wykonanie złośliwego kodu bez logowania. Zostały usunięte w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, opublikowanych 21.10.2026. Więcej: [Czym jest PHP2Shell? Luka wyjaśniona prosto](https://phpsos.de/pl/php2shell/was-ist-php2shell/)

**php_admin_value**: php_admin_value ustawia opcję PHP w puli FPM lub w konfiguracji Apache w taki sposób, że aplikacje nie mogą jej nadpisać przez ini_set() ani .htaccess. Dla przełączników istnieje php_admin_flag. php.net zaleca tę drogę dla środków tymczasowych przeciw PHP2Shell, na przykład dla memory_limit. Więcej: [php_admin_value: blokowanie ustawień przed nadpisaniem](https://phpsos.de/pl/blog/php-admin-value-sperren/)

**Plan awaryjny**: Awaryjny plan IT określa, kto w razie incydentu co robi: kontakty, ścieżki decyzyjne, pierwsze kroki, wznowienie pracy. Musi być dostępny także offline na wypadek awarii systemów. Regularne ćwiczenia pokazują, czy w razie potrzeby zadziała. Więcej: [Tworzenie planu awaryjnego IT dla serwerów WWW](https://phpsos.de/pl/compliance/notfallplan-erstellen/)

**Plesk**: Plesk to popularny panel zarządzania serwerami WWW, w którym można ustawiać domeny, wersje PHP i handlery dla każdej strony. Ma własne pakiety PHP, ale może też używać pakietów PHP dystrybucji. Przy backportach Plesk może nadal pokazywać starszy numer, jak 8.2.34, mimo że system jest załatany. Więcej: [Serwer Plesk: kontrola wersji PHP i instalacja poprawek](https://phpsos.de/pl/server/plesk/)

**Poprawka (patch)**: Poprawka (patch) to korekta producenta, która zamyka lukę w kodzie programu. Działa dopiero po zainstalowaniu i po restarcie wszystkich działających procesów. Poprawka nie usuwa złośliwego oprogramowania, które zostało już wprowadzone, i nie dowodzi, że wcześniej nic się nie wydarzyło. Więcej: [Usługa łatania PHP: aktualizacja z restartem i dowodem](https://phpsos.de/pl/leistungen/php-patch-service/)

**post_max_size**: post_max_size określa, jak duża może być łącznie zawartość żądania POST; domyślnie jest to 8 MB. Jako środek tymczasowy przeciw PHP2Shell php.net podaje 8M dla stron bez przesyłania plików i 32M dla stron z przesyłaniem plików. upload_max_filesize musi być niższe. Więcej: [Rozsądne ograniczanie post_max_size i upload_max_filesize](https://phpsos.de/pl/blog/post-max-size-upload-limits/)

**Poziom ostrzeżenia**: BSI klasyfikuje zagrożenie przy ostrzeżeniach bezpieczeństwa w poziomach, oznaczonych także kolorami. Poziom 3 (pomarańczowy) oznacza sytuację krytyczną dla działalności firm, z możliwym poważnym zakłóceniem normalnej pracy. Dla PHP2Shell obowiązuje poziom ostrzeżenia 3 / pomarańczowy. Więcej: [Poziom pomarańczowy BSI: co oznacza ta klasyfikacja](https://phpsos.de/pl/blog/bsi-warnstufe-orange-erklaert/)

**Proof of Concept**: Proof of Concept (PoC) to dowód, że lukę da się wykorzystać, często w postaci prostego kodu demonstracyjnego. Służy producentom i badaczom do oceny, ale może też stanowić wzór dla atakujących. Opublikowany PoC zwykle zwiększa więc pilność instalacji poprawek.

**Pula FPM**: Pula to grupa procesów PHP-FPM z własną konfiguracją, własnym gniazdem i najlepiej własnym użytkownikiem systemowym. Oddzielna pula dla każdej strony rozdziela strony od siebie, tak aby włamanie na jedną stronę nie sięgało bezpośrednio plików innych. W puli można na stałe zadać ustawienia przez php_admin_value. Więcej: [Izolowanie pul PHP-FPM dla każdej strony](https://phpsos.de/pl/blog/php-fpm-pools-isolieren/)

**Ransomware**: Ransomware szyfruje dane i żąda okupu za ich odszyfrowanie, często z groźbą opublikowania wykradzionych danych. Skompromitowany serwer WWW może być do tego punktem wejścia. Najskuteczniejszą ochroną są oddzielne, przetestowane kopie zapasowe i plan awaryjny. Więcej: [Strategia backupu serwera: backupy według reguły 3-2-1](https://phpsos.de/pl/ratgeber/backups-3-2-1/)

**RCE**: RCE (Remote Code Execution) oznacza, że atakujący może zdalnie wykonać własny kod na cudzym systemie. Jeśli nie jest do tego potrzebne logowanie, mówi się o unauthenticated RCE, czyli najcięższej klasie luk serwerów WWW. Dzięki RCE atakujący może odczytywać dane, zakładać tylne furtki i dalej nadużywać serwera. Więcej: [Czym jest PHP2Shell? Luka wyjaśniona prosto](https://phpsos.de/pl/php2shell/was-ist-php2shell/)

**Reagowanie na incydenty**: Reagowanie na incydenty (incident response) to uporządkowana obsługa incydentu bezpieczeństwa: rozpoznanie, powstrzymanie, zabezpieczenie śladów, oczyszczenie, przywrócenie i omówienie. Ustalony przebieg zapobiega temu, by w pośpiechu zniszczyć dowody lub przeoczyć tylne furtki. Ważne są jasne odpowiedzialności i pełna dokumentacja. Więcej: [Incident Response przy atakach na serwery](https://phpsos.de/pl/leistungen/incident-response/)

**Reverse Proxy**: Reverse proxy przyjmuje żądania z internetu i przekazuje je do jednego lub kilku serwerów za nim. Może przejąć TLS, rozkładać obciążenie i służyć jako miejsce dla reguł filtrujących lub WAF. Chroni tylko wtedy, gdy serwery za nim nie są dodatkowo dostępne bezpośrednio. Więcej: [Filtrowanie żądań uploadu na brzegu: szanse i ryzyka](https://phpsos.de/pl/blog/upload-anfragen-am-rand-filtern/)

**RFI**: RFI (Remote File Inclusion) to odmiana, w której aplikacja doładowuje i wykonuje kod z obcego adresu. W PHP ustawienie allow_url_include=Off, od dawna domyślne, zapobiega włączaniu zdalnych plików. Stare aplikacje i konfiguracje należy pod tym kątem sprawdzić. Więcej: [Zapobieganie Local File Inclusion w PHP: LFI i RFI](https://phpsos.de/pl/ratgeber/lfi-rfi/)

**RODO art. 33**: Art. 33 RODO zobowiązuje administratorów do zgłoszenia naruszenia ochrony danych osobowych właściwemu organowi nadzorczemu, o ile to możliwe w ciągu 72 godzin od stwierdzenia naruszenia. Obowiązek odpada tylko wtedy, gdy prawdopodobnie nie ma ryzyka dla osób, których dane dotyczą. W konkretnym przypadku doradzają inspektorzy ochrony danych lub prawnicy. Więcej: [Obowiązek zgłoszenia z RODO: 72 godziny po incydencie](https://phpsos.de/pl/compliance/dsgvo-meldepflicht-72-stunden/)

**RODO art. 34**: Art. 34 RODO reguluje zawiadamianie samych osób, których dane dotyczą. Jest konieczne, gdy naruszenie ochrony danych prawdopodobnie powoduje wysokie ryzyko naruszenia ich praw lub wolności. To, czy tak jest, należy ocenić z inspektorami ochrony danych lub prawnikami. Więcej: [Obowiązek zgłoszenia z RODO: 72 godziny po incydencie](https://phpsos.de/pl/compliance/dsgvo-meldepflicht-72-stunden/)

**Rozszerzenie**: Rozszerzenie (extension) uzupełnia PHP o funkcje, na przykład do obsługi baz danych, obrazów lub szyfrowania. Rozszerzenia działają w tym samym procesie co PHP i mają takie same uprawnienia. Wyłączenie niepotrzebnych rozszerzeń zmniejsza powierzchnię ataku. Więcej: [Rozszerzenia PHP (extensions): jak je rozumieć](https://phpsos.de/pl/php/php-erweiterungen/)

**SAPI**: SAPI (Server Application Programming Interface) to interfejs, przez który PHP komunikuje się ze swoim otoczeniem, na przykład z Apache, PHP-FPM lub wierszem poleceń. To, która SAPI jest używana, decyduje o tym, jak procesy PHP są uruchamiane, ponownie wykorzystywane i restartowane. W przypadku PHP2Shell dotknięte są według zespołu PHP różne tryby pracy, a mod_php niesie najwyższe ryzyko. Więcej: [SAPI wyjaśnione: jak PHP rozmawia z serwerem WWW](https://phpsos.de/pl/php/sapi-erklaert/)

**SEO spam**: SEO spam to wprowadzone strony, linki lub przekierowania, którymi atakujący umieszczają obce oferty w wyszukiwarkach. Często zmanipulowane treści widzą tylko wyszukiwarki lub odwiedzający z Google. Oprócz oczyszczania konieczna jest potem kontrola w Google Search Console. Więcej: [SEO spam i obce strony w indeksie Google](https://phpsos.de/pl/blog/seo-spam-im-google-index/)

**serialize_handler**: session.serialize_handler określa, w jakim formacie PHP zapisuje dane sesji, na przykład php, php_binary lub php_serialize. Wskazówka dotycząca CVE-2026-115560 dotyczy wyłącznie nietypowej konfiguracji, w której ten format jest przełączany w czasie działania, a Session Upload Progress jest aktywny. Środkiem zaradczym do następnego wydania z poprawkami błędów jest session.upload_progress.enabled=0. Więcej: [CVE-2026-115560: wskazówka o session upload progress](https://phpsos.de/pl/php2shell/cve-2026-115560/)

**Serwer origin**: Serwer origin to właściwy serwer WWW za siecią CDN lub reverse proxy. Jeśli jest dostępny także bezpośrednio przez swój adres IP, atakujący mogą ominąć ochronę umieszczoną przed nim. Dlatego origin powinien przyjmować tylko połączenia od CDN lub proxy. Więcej: [Reguły ochronne Cloudflare przeciw PHP2Shell: co dają, a czego nie](https://phpsos.de/pl/blog/cloudflare-waf-php2shell/)

**Serwer root**: Serwer root to wynajmowany serwer, na którym klient ma pełne uprawnienia administratora. Tym samym pełna odpowiedzialność za aktualizacje, utwardzanie i nadzór spoczywa na kliencie. Dostawca zapewnia tylko sprzęt i sieć. Więcej: [Samodzielne zabezpieczenie serwera root i vServera](https://phpsos.de/pl/server/root-server-vserver/)

**Serwer zarządzany**: W przypadku serwera zarządzanego (managed server) dostawca udostępnia osobny serwer i przejmuje umownie określone części jego eksploatacji, często aktualizacje systemu operacyjnego i PHP. Co dokładnie do tego należy, wynika z umowy i bardzo różni się między dostawcami. W razie wątpliwości odpowiedzialność za poprawki należy potwierdzić na piśmie. Więcej: [Serwer zarządzany: wyjaśnienie odpowiedzialności](https://phpsos.de/pl/server/managed-server/)

**Sesja**: Sesja łączy kilka żądań tego samego odwiedzającego, na przykład przy logowaniu lub w koszyku. PHP zapisuje dane po stronie serwera i przekazuje przeglądarce identyfikator sesji, domyślnie w ciasteczku PHPSESSID. Kto zna cudzy identyfikator sesji, może w pewnych okolicznościach podszyć się pod tego użytkownika. Więcej: [Sesje i cookies w PHP](https://phpsos.de/pl/php/sessions-und-cookies/)

**session.upload_progress**: Session Upload Progress to funkcja PHP, która zapisuje w sesji postęp trwających przesyłań plików; domyślnie jest włączona. php.net zaleca tymczasowo session.upload_progress.enabled=0 w php.ini, puli FPM lub konfiguracji serwera, a następnie restart wszystkich procesów worker. Samo to ustawienie nie zamyka według raportów fachowych obu luk PHP2Shell; obowiązkowa pozostaje aktualizacja. Więcej: [Wyłączanie session.upload_progress: poprawnie i na stałe](https://phpsos.de/pl/blog/session-upload-progress-abschalten/)

**SIEM**: SIEM (Security Information and Event Management) zbiera centralnie dane logów z wielu systemów i ocenia je pod kątem zdarzeń bezpieczeństwa. Dzięki temu można rozpoznać powiązania, które giną w pojedynczych logach. SIEM wymaga utrzymywanych reguł i ludzi, którzy obsługują komunikaty. Więcej: [Monitoring bezpieczeństwa dla serwerów WWW](https://phpsos.de/pl/leistungen/security-monitoring/)

**Skimming**: Przy skimmingu w sklepach internetowych atakujący wprowadzają do kasy JavaScript, który podsłuchuje dane płatnicze i dane klientów i je wysyła. Kod często znajduje się w plikach motywu, skryptach śledzących lub wpisach w bazie danych. Klienci niczego nie zauważają, sprzedawca często dopiero dzięki informacjom od dostawców płatności. Więcej: [Sklep internetowy zhakowany? Bezpieczeństwo IT dla sprzedawców](https://phpsos.de/pl/branchen/onlineshops/)

**SQL injection**: Przy SQL injection atakujący wprowadza przez dane wejściowe własne polecenia bazodanowe do aplikacji. W ten sposób można odczytywać lub zmieniać dane. Ochronę zapewniają przygotowane zapytania (prepared statements) z symbolami zastępczymi zamiast sklejanych tekstów SQL. Więcej: [Jak zapobiegać SQL injection w PHP](https://phpsos.de/pl/ratgeber/sql-injection-php/)

**SSRF**: SSRF (Server-Side Request Forgery) skłania aplikację do wysyłania w imieniu atakującego żądań pod inne adresy, także do systemów wewnętrznych. W ten sposób stają się dostępne usługi, które z zewnątrz powinny być odizolowane. Ochronę zapewniają listy dozwolonych celów i blokowanie wewnętrznych zakresów adresów. Więcej: [Zapobieganie Server-Side Request Forgery (SSRF) w PHP](https://phpsos.de/pl/blog/ssrf-in-php/)

**Superglobals**: Superglobals to zmienne, które PHP udostępnia w każdym skrypcie, na przykład $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER i $_SESSION. Zawierają dane bieżącego żądania, które w dużej części pochodzą od odwiedzającego. Wszystko, co się w nich znajduje, trzeba traktować jako niegodne zaufania i sprawdzać. Więcej: [Superglobals: $_GET, $_POST, $_FILES i inne](https://phpsos.de/pl/php/superglobals/)

**sury.org**: sury.org to repozytorium pakietów Ondřeja Surýego z aktualnymi i starszymi wersjami PHP dla Debiana i Ubuntu. To oferta podmiotu trzeciego, a nie archiwum bezpieczeństwa Debiana. Według raportów udostępniono tam buildy dla wszystkich gałęzi od 5.6 do 8.5. Więcej: [Repozytorium sury.org: pakiety PHP z zewnętrznego źródła](https://phpsos.de/pl/blog/sury-repository-php/)

**Threat Hunting**: Threat hunting to aktywne poszukiwanie atakujących we własnej sieci, bez wcześniejszego ostrzeżenia. Punktem wyjścia są hipotezy, na przykład: czy proces serwera WWW uruchomił powłokę od 20.10.? W ten sposób wykrywa się włamania, które automatyczne narzędzia przeoczyły. Więcej: [Sygnał ostrzegawczy: serwer WWW uruchamia powłokę](https://phpsos.de/pl/blog/webserver-startet-shell/)

**TISAX**: TISAX to procedura kontroli i wymiany informacji dotyczących bezpieczeństwa informacji w przemyśle motoryzacyjnym. Opiera się na katalogu wymagań VDA (niemieckiego Verband der Automobilindustrie, stowarzyszenia przemysłu motoryzacyjnego) i jest prowadzona przez ENX Association. Dostawcy muszą za jej pomocą wykazać wobec producentów swój poziom bezpieczeństwa. Więcej: [ISO 27001 i TISAX: czego dotyczą serwery WWW](https://phpsos.de/pl/blog/iso-27001-tisax-webserver/)

**TLS**: TLS (Transport Layer Security) szyfruje połączenie między przeglądarką a serwerem; rozpoznać je można po HTTPS. Obecnie zalecane są TLS 1.2 i 1.3, starsze wersje protokołu powinny być wyłączone. TLS chroni dane w drodze, ale nie przed lukami na samym serwerze. Więcej: [Prawidłowa konfiguracja TLS i HTTPS](https://phpsos.de/pl/blog/tls-https-richtig-konfigurieren/)

**Type Juggling**: Type juggling to automatyczna konwersja typów w PHP, na przykład przy luźnym porównaniu za pomocą ==. Przez to wartości, które nie są takie same, mogą być uznane za równe, co staje się niebezpieczne przy sprawdzaniu haseł lub tokenów. Ochronę zapewniają ścisłe porównania za pomocą === oraz hash_equals() dla tajnych wartości. Więcej: [Type juggling w PHP: luźne porównania jako ryzyko bezpieczeństwa](https://phpsos.de/pl/blog/type-juggling-php/)

**Ubezpieczenie cyber**: Ubezpieczenie cyber pokrywa, zależnie od umowy, koszty po ataku, na przykład informatyki śledczej, odtworzenia lub przerwy w działalności. Wiele umów zawiera obowiązki ubezpieczonego, takie jak terminowe aktualizacje i natychmiastowe zgłoszenie szkody. Co obowiązuje w danym przypadku, należy ustalić z ubezpieczycielem. Więcej: [Cyberubezpieczenie: co liczy się w razie szkody](https://phpsos.de/pl/compliance/cyberversicherung/)

**Umowa powierzenia**: Umowa powierzenia przetwarzania danych (AVV) na podstawie art. 28 RODO jest potrzebna, gdy usługodawca przetwarza w imieniu zleceniodawcy dane osobowe lub może mieć do nich dostęp. Dotyczy to często także firm hostingowych, agencji i usługodawców IT z dostępem do serwera. Umowa reguluje między innymi polecenia, środki ochrony i ścieżki zgłaszania. Więcej: [Powierzenie przetwarzania danych, gdy dostawcy mają dostęp do serwerów](https://phpsos.de/pl/blog/auftragsverarbeitung-serverzugriff/)

**upload_max_filesize**: upload_max_filesize ogranicza rozmiar pojedynczego przesyłanego pliku; domyślnie jest to 2 MB. Wartość musi być mniejsza niż post_max_size, ponieważ plik jest częścią żądania POST. Zbyt hojne wartości zwiększają powierzchnię ataku bez żadnej korzyści. Więcej: [Rozsądne ograniczanie post_max_size i upload_max_filesize](https://phpsos.de/pl/blog/post-max-size-upload-limits/)

**.user.ini**: Pliki .user.ini to ustawienia PHP obowiązujące w poszczególnych katalogach, które odczytują PHP-FPM i CGI. Dzięki nim operatorzy stron mogą zmieniać pojedyncze wartości bez dostępu do serwera, ale tylko te, które PHP na to zezwala. Zgodnie z php.net ustawienia istotne dla bezpieczeństwa, takie jak session.upload_progress.enabled=0 przeciw PHP2Shell, nie powinny być zadawane przez .user.ini. Więcej: [php.ini wyjaśniony: budowa, poziomy i pierwszeństwo](https://phpsos.de/pl/php/php-ini-erklaert/)

**Utwardzanie**: Utwardzanie (hardening) oznacza takie ustawienie systemu, aby oferował jak najmniejszą powierzchnię ataku: tylko niezbędne usługi, skromne uprawnienia, bezpieczne ustawienia domyślne. W przypadku serwerów PHP należą do tego na przykład oddzielne pule, zablokowane funkcje i brak wykonywania PHP w katalogach przesyłanych plików. Utwardzanie ogranicza szkody, ale nie zastępuje aktualizacji. Więcej: [Utwardzanie serwerów WWW z PHP](https://phpsos.de/pl/leistungen/server-haertung/)

**VdS 10000**: VdS 10000 to wytyczna VdS Schadenverhütung (niemieckiej organizacji zajmującej się zapobieganiem szkodom) dotycząca bezpieczeństwa informacji w małych i średnich przedsiębiorstwach. Jest bardziej odchudzona niż ISO 27001 i dopasowana do możliwości MŚP. Możliwa jest certyfikacja według niej. Więcej: [VdS 10000: bezpieczeństwo informacji dla małych i średnich firm](https://phpsos.de/pl/blog/vds-10000-kmu/)

**vServer**: vServer (serwer wirtualny) to wirtualny komputer na współdzielonym sprzęcie, z własnym systemem operacyjnym i zwykle z dostępem root. Dla bezpieczeństwa obowiązuje to samo co przy serwerze root: aktualizacje i utwardzanie należą do klienta. Wiele vServerów działa z preinstalowanymi panelami, takimi jak Plesk. Więcej: [Samodzielne zabezpieczenie serwera root i vServera](https://phpsos.de/pl/server/root-server-vserver/)

**WAF**: WAF (Web Application Firewall) sprawdza żądania HTTP przed aplikacją i blokuje znane wzorce ataków. Może działać jako usługa w chmurze, jako proxy lub jako moduł serwera WWW. Daje czas, ale nie zastępuje aktualizacji i zostaje ominięty, jeśli serwer jest dostępny także bezpośrednio. Więcej: [WAF i wirtualne łatanie dla PHP](https://phpsos.de/pl/leistungen/waf-virtuelles-patching/)

**Webshell**: Webshell to skrypt, który atakujący umieszczają na serwerze WWW, aby zdalnie sterować nim przez przeglądarkę. Jest często mały, zaciemniony i ukryty w katalogach przesyłanych plików lub pamięci podręcznej. Webshell pozostaje także po aktualizacji PHP lub CMS i trzeba go szukać celowo. Więcej: [Jak wykryć i usunąć webshell](https://phpsos.de/pl/ratgeber/webshell-erkennen/)

**Wirtualne łatanie**: Wirtualne łatanie blokuje ataki na znaną lukę przed aplikacją, zwykle za pomocą WAF, bez zmiany podatnego kodu. Daje czas do momentu, gdy prawdziwa aktualizacja będzie możliwa. W przypadku PHP2Shell ostrzega na przykład Cloudflare, że same reguły oparte na danych żądania nie wystarczają; aktualizacja pozostaje obowiązkowa. Więcej: [WAF i wirtualne łatanie dla PHP](https://phpsos.de/pl/leistungen/waf-virtuelles-patching/)

**XSS**: XSS (Cross-Site Scripting) oznacza, że obcy JavaScript jest wykonywany przez stronę internetową w przeglądarce innych odwiedzających. W ten sposób można przejąć sesje lub podglądać dane wpisywane w formularzach. Ochronę zapewniają konsekwentne kodowanie wszystkich danych wyjściowych i Content Security Policy. Więcej: [Zapobieganie XSS w PHP: skuteczna obrona przed cross-site scripting](https://phpsos.de/pl/ratgeber/xss-php/)

**XXE**: XXE (XML External Entities) wykorzystuje to, że parsery XML mogą doładowywać zewnętrzne odwołania w dokumentach. W ten sposób można w pewnych okolicznościach odczytywać pliki z serwera lub wywoływać wewnętrzne żądania. Ochronę zapewnia wyłączenie ładowania zewnętrznych encji podczas przetwarzania niezaufanych danych XML. Więcej: [Zapobieganie XML External Entities (XXE) w PHP](https://phpsos.de/pl/blog/xxe-in-php/)

**Zabezpieczenie dowodów**: Zabezpieczenie dowodów oznacza zabezpieczenie śladów incydentu, zanim zostaną utracone przez oczyszczanie, restart lub ponowną instalację. Należą do tego pliki logów, obrazy nośników danych, a zależnie od przypadku pamięć operacyjna. Prasa fachowa radzi po PHP2Shell przechowywać logi serwera od 20.10.2026. Więcej: [Zabezpieczyć dowody, zanim zainstalują Państwo serwer od nowa](https://phpsos.de/pl/blog/beweise-sichern-vor-neuinstallation/)

**ZAC**: Zentrale Ansprechstellen Cybercrime (ZAC), czyli centralne punkty kontaktowe ds. cyberprzestępczości niemieckiej policji, to wyspecjalizowane punkty dla firm i urzędów, które padły ofiarą cyberataku. Istnieją we wszystkich niemieckich krajach związkowych oraz w BKA. Przyjmują zawiadomienia i doradzają w sprawie dalszego postępowania. Więcej: [Złożenie zawiadomienia: Zentrale Ansprechstellen Cybercrime](https://phpsos.de/pl/compliance/anzeige-polizei-zac/)

**Zend Engine**: Zend Engine to rdzeń interpretera PHP. Tłumaczy kod PHP na wewnętrzne polecenia (opcody), wykonuje je i zarządza pamięcią. Błędy w Zend Engine dotyczą każdej aplikacji PHP i można je usunąć wyłącznie aktualizacją PHP. Więcej: [Zend Engine: serce PHP](https://phpsos.de/pl/php/zend-engine/)

**Zero-Day**: Zero-day to luka, która jest wykorzystywana lub publicznie znana, zanim producent udostępni poprawkę. Operatorzy mają wtedy zero dni zapasu. Do czasu poprawki pomagają tylko środki tymczasowe, odizolowanie i nadzór. Więcej: [Okno czasowe między poprawką a atakiem](https://phpsos.de/pl/blog/zeitfenster-patch-angriff/)