# Blog: PHP2Shell, securitatea serverelor și asistență de urgență

> Blog despre PHP2Shell și securitatea serverelor: situație, hosting, detectare, securizare, dezvoltare sigură, management și ajutoare de decizie.

Sursa: https://phpsos.de/ro/blog/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

Încadrarea situației, instrucțiuni pentru administratori și ajutoare de decizie pentru conducere. Sortate pe teme, fiecare articol cu surse.

- [PHP2Shell: ce este dovedit și ce nu](https://phpsos.de/ro/blog/php2shell-was-belegt-ist/): O verificare a faptelor despre PHP2Shell: ce afirmații provin din surse primare, ce provin din relatări din presă și ce afirmații nu rezistă.
- [De ce a devenit cunoscută vulnerabilitatea PHP înainte de patch](https://phpsos.de/ro/blog/php-luecke-vorzeitig-bekannt/): Potrivit relatărilor, detalii despre PHP2Shell au devenit publice înainte de expirarea embargoului. Explicăm desfășurarea și ce înseamnă aceasta pentru planificarea patchurilor.
- [Autoritățile scot site-uri din rețea: ce învață companiile de aici](https://phpsos.de/ro/blog/behoerden-webseiten-offline/): Mainz, guvernul landului Hessa și BKA au scos preventiv site-uri din rețea. Ce pot învăța companiile de aici pentru propria decizie.
- [Nivelul de alertă portocaliu BSI: ce înseamnă încadrarea](https://phpsos.de/ro/blog/bsi-warnstufe-orange-erklaert/): BSI încadrează PHP2Shell la 3 / portocaliu. Ce spune scara, ce nu spune și cum transformă companiile încadrarea în decizii.
- [Ce recomandă CERT-EU și CERT-Bund pentru PHP2Shell](https://phpsos.de/ro/blog/cert-eu-empfehlungen-php/): Instituțiile oficiale sunt de acord: actualizați imediat, altfel izolați. Comparăm recomandările și arătăm cum arată izolarea în practică.
- [Regulile de protecție Cloudflare împotriva PHP2Shell: ce oferă și ce nu](https://phpsos.de/ro/blog/cloudflare-waf-php2shell/): Cloudflare a lansat devreme reguli de protecție împotriva PHP2Shell. De ce ajută, de ce nu înlocuiesc totuși actualizarea PHP și ce setări ar trebui să verificați.
- [22,6 milioane de instanțe expuse: încadrarea corectă a cifrelor](https://phpsos.de/ro/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel și alții indică cifre foarte diferite despre PHP2Shell. Explicăm ce a fost numărat și ce cifră contează cu adevărat pentru dumneavoastră.
- [PHP2Shell în cinci minute: briefing pentru conducere](https://phpsos.de/ro/blog/php2shell-briefing-geschaeftsfuehrung/): Vulnerabilitatea PHP2Shell pe o pagină pentru factorii de decizie: situația, riscul, cinci întrebări pentru IT și deciziile pentru astăzi.
- [Vulnerabilitatea de securitate PHP explicată simplu](https://phpsos.de/ro/blog/php-luecke-einfach-erklaert/): PHP2Shell pentru netehnicieni: cu imagini din viața de zi cu zi, un mic glosar și trei situații tipice de plecare, ce ar trebui să faceți ca proprietar de site.
- [PHP2Shell: 15 întrebări ale clienților de hosting](https://phpsos.de/ro/blog/fragen-von-hosting-kunden/): Site-ul dumneavoastră se află la un furnizor de hosting și vreți să știți ce trebuie să faceți singur la PHP2Shell? Iată cele 15 întrebări cele mai frecvente, cu răspunsuri scurte.
- [De ce o actualizare WordPress nu ajută împotriva PHP2Shell](https://phpsos.de/ro/blog/warum-wordpress-update-nicht-hilft/): După titluri, mulți operatori au actualizat WordPress și se simt în siguranță. De ce acest lucru nu duce la nimic la PHP2Shell și ce contează în schimb.
- [PHP2Shell și Log4Shell: ce au în comun vulnerabilitățile](https://phpsos.de/ro/blog/php2shell-und-log4shell/): Mulți compară PHP2Shell cu Log4Shell din 2021. Ce susține comparația, unde șchiopătează și ce lecții de atunci ajută astăzi.
- [Scanări în masă după PHP fără patch: cum decurg atacurile automatizate](https://phpsos.de/ro/blog/automatisierte-massenscans/): După PHP2Shell, atacatorii scanează automatizat internetul după servere vulnerabile. Cum decurge, de ce dimensiunea nu contează și ce vă protejează.
- [Fereastra de timp dintre patch și atac](https://phpsos.de/ro/blog/zeitfenster-patch-angriff/): La PHP2Shell au existat încercări de atac încă dinaintea patchului. Explicăm fazele ferestrei de timp, cum o măsurați pe a dumneavoastră și cum o scurtați.
- [După PHP2Shell: de ce sunt probabile alte anunțuri](https://phpsos.de/ro/blog/weitere-php-meldungen/): PHP2Shell nu este încheiat odată cu patchul din 21 octombrie. De ce sunt de așteptat anunțuri ulterioare și cum vă pregătiți echipa.
- [PHP2Shell: imaginea situației din prima săptămână](https://phpsos.de/ro/blog/lagebild-erste-woche/): La o săptămână după prima încercare de atac observată: starea patchurilor, avertismentele autorităților, atacurile și opririle, separat curat pe surse.
- [Sfaturi false periculoase despre PHP2Shell care circulă acum](https://phpsos.de/ro/blog/gefaehrliche-falschtipps/): Blocarea cookie-urilor, ascunderea mesajelor de eroare, actualizarea doar a CMS-ului: nouă sfaturi despre PHP2Shell care creează o falsă siguranță și ce contează cu adevărat.
- [Schimbarea versiunii PHP în zona clientului de hosting](https://phpsos.de/ro/blog/php-version-hosting-aendern/): Cum schimbați versiunea PHP în zona clientului furnizorului dumneavoastră de hosting, ce versiune alegeți și ce verificați înainte și după.
- [Debian și Ubuntu: este pachetul meu PHP actualizat?](https://phpsos.de/ro/blog/debian-ubuntu-paket-gepatcht/): Ce pachete PHP au corectat Debian și Ubuntu împotriva PHP2Shell, cum comparați exact starea instalată și unde eșuează dovada.
- [RHEL, AlmaLinux și Rocky Linux: verificarea patchului PHP](https://phpsos.de/ro/blog/rhel-almalinux-rocky-php/): Ce a publicat Red Hat despre PHP2Shell, cum dovediți nivelul pachetelor pe RHEL și pe clone și de ce o reîncărcare nu este suficientă.
- [Depozitul sury.org: pachete PHP dintr-o sursă terță](https://phpsos.de/ro/blog/sury-repository-php/): Multe servere Debian și Ubuntu obțin PHP din depozitul sury. Ce înseamnă aceasta pentru actualizări, dovezi și versiuni PHP vechi după PHP2Shell.
- [Depozitul Remi: PHP la zi pe sisteme RHEL](https://phpsos.de/ro/blog/remi-repository-php/): Remi livrează versiuni PHP actuale pentru familia RHEL, ca modul sau instalabile în paralel. Cum verificați starea după PHP2Shell și evitați ramurile uitate.
- [De ce php -v arată după actualizare același număr](https://phpsos.de/ro/blog/php-v-zeigt-alte-nummer/): Actualizarea s-a făcut, dar php -v indică versiunea veche. De regulă este un backport și nu o eroare. Cum deosebiți inofensivul de problemele reale.
- [Dovedirea numerelor CVE în changelog-ul pachetului](https://phpsos.de/ro/blog/cve-im-changelog-nachweisen/): Cine trebuie să dovedească un patch PHP conducerii, auditorilor sau asigurătorilor are nevoie de mai mult decât un număr de versiune. Așa devine intrarea din changelog o dovadă.
- [Schimbarea furnizorului de hosting după un incident de securitate: la ce să fiți atenți?](https://phpsos.de/ro/blog/hoster-wechseln-nach-vorfall/): După un incident, dorința de a schimba furnizorul de hosting este de înțeles. Pentru ca mutarea să nu ducă atacatorul cu ea, contează ordinea și alegerea.
- [Mai multe versiuni PHP pe un server: patch separat pentru fiecare](https://phpsos.de/ro/blog/mehrere-php-versionen-server/): Pe multe servere rulează în paralel trei, patru sau mai multe instalări PHP. După PHP2Shell, fiecare trebuie găsită, actualizată și repornită.
- [Dezactivarea versiunilor PHP vechi în panoul de hosting](https://phpsos.de/ro/blog/alte-php-versionen-abschalten/): PHP2Shell este un bun prilej de a scăpa de versiunile PHP vechi. Procedați în trei faze, pentru ca niciun site și niciun cronjob să nu cedeze neobservat.
- [Plesk: înțelegerea handlerilor PHP (FPM, FastCGI, modul Apache)](https://phpsos.de/ro/blog/plesk-php-handler/): Ce handler PHP folosește Plesk pentru un site decide izolarea, configurarea și riscul. O comparație cu privire la PHP2Shell.
- [CloudLinux și alt-php: ce ar trebui să știe clienții de hosting](https://phpsos.de/ro/blog/cloudlinux-alt-php/): Pe serverele CloudLinux, site-urile rulează adesea cu pachete proprii alt-php. Fiecare dintre aceste versiuni are nevoie de propriul patch, iar acesta poate fi aplicat doar de operatorul serverului.
- [PHP pe NAS, firewall-uri și appliance-uri: sistemele uitate](https://phpsos.de/ro/blog/php-auf-nas-und-appliances/): Nu doar serverele web folosesc PHP. Pot fi afectate și sistemele NAS, firewall-urile și dispozitivele specializate cu interfață web. Patchul îl poate aplica acolo de regulă doar producătorul, accesibilitatea o reglați dumneavoastră.
- [PHP la furnizori cloud și PaaS: cine actualizează runtime-ul?](https://phpsos.de/ro/blog/paas-php-laufzeit/): La serviciile de platformă, patchul PHP depinde de modelul de operare. Decisiv este runtime-ul care livrează efectiv, nu mediul local sau codul aplicației.
- [Imagini Docker PHP oficiale: taguri, digest-uri și reconstruire](https://phpsos.de/ro/blog/offizielle-php-docker-images/): Un tag al imaginii PHP oficiale este un pointer care se mută în timp spre niveluri noi. Cine știe ce înseamnă tag, variantă și digest alege imaginea potrivită și poate dovedi nivelul de patch.
- [CI/CD: reconstruirea automată a imaginilor PHP](https://phpsos.de/ro/blog/php-images-in-ci-neu-bauen/): O imagine se depășește și fără modificări de cod. Cu build-uri programate, o verificare a versiunii și un rollout prin digest, patchurile PHP ajung sigur în producție.
- [Suport pe termen lung pentru versiunile PHP vechi: opțiuni și limite](https://phpsos.de/ro/blog/langzeitsupport-alte-php-versionen/): Cine nu poate renunța imediat la PHP 8.1 sau mai vechi găsește suport pe termen lung la distribuții, la furnizori terți și la servicii comerciale. Ce oferă aceste căi, ce vă trebuie în scris și unde sunt limitele.
- [Actualizarea PHP pe Windows](https://phpsos.de/ro/blog/php-unter-windows-aktualisieren/): Pe Windows nu există actualizare automată PHP. Cine alege varianta corectă, verifică descărcarea și repornește toate procesele aduce curat patchul PHP2Shell pe fiecare calculator.
- [Semnal de alarmă: serverul web pornește un shell](https://phpsos.de/ro/blog/webserver-startet-shell/): Dacă un proces PHP-FPM sau al serverului web pornește un shell, este unul dintre cele mai puternice semnale de alarmă pentru o intruziune. Cum verificați arborele de procese, cum încadrați excepțiile și cum monitorizați permanent tiparul.
- [Găsirea proceselor suspecte pe serverele Linux](https://phpsos.de/ro/blog/verdaechtige-prozesse-linux/): Procesele malițioase se deghizează cu nume inofensive, rulează din directoare temporare sau de la fișiere șterse. Cu câteva comenzi de citire găsiți anomaliile și le încadrați.
- [Recunoașterea cronjob-urilor ascunse ca ușă din spate](https://phpsos.de/ro/blog/cronjobs-als-hintertuer/): Atacatorii folosesc sarcini programate pentru a reveni după o curățare. Cum verificați complet crontab-urile, directoarele cron, timerele systemd și sarcinile at și cum recunoașteți intrările suspecte.
- [Găsirea fișierelor modificate recent pe serverul web](https://phpsos.de/ro/blog/geaenderte-dateien-finden/): După o posibilă intruziune contează ce s-a schimbat pe server. Cum căutați după intervale de timp, folosiți corect mtime și ctime și comparați cu pachetele, Git și backupurile.
- [Fișiere PHP în directorul de upload: interpretarea corectă a constatărilor](https://phpsos.de/ro/blog/php-dateien-im-upload-ordner/): Un fișier PHP în directorul de upload este aproape întotdeauna un semn de alarmă, dar nu orice fișier este cod malițios. Cum evaluați constatarea fără a distruge urme și cum clarificați dacă l-a apelat cineva.
- [Recunoașterea codului PHP ofuscat](https://phpsos.de/ro/blog/verschleierter-php-code/): Codul PHP ilizibil cu eval și base64_decode este un semn clasic de cod malițios introdus. Ce tipare căutați, cum le găsiți fără risc și când ofuscarea este legitimă.
- [Verificarea conexiunilor de ieșire ale unui server](https://phpsos.de/ro/blog/ausgehende-verbindungen-pruefen/): Un server web răspunde în primul rând la cereri. Dacă el însuși stabilește conexiuni către ținte necunoscute, aceasta poate însemna control de către atacatori sau scurgere de date. Cum verificați și limitați traficul de ieșire.
- [Găsirea conturilor de administrator străine în CMS și server](https://phpsos.de/ro/blog/fremde-admin-konten-finden/): Un administrator necunoscut este adesea cea mai simplă ușă din spate. Cum căutați, nivel cu nivel, conturi străine, inclusiv pe cele pe care interfața le ascunde.
- [Găsirea și eliminarea cheilor SSH necunoscute](https://phpsos.de/ro/blog/ssh-schluessel-pruefen/): O cheie SSH introdusă deschide atacatorilor ușa chiar dacă toate parolele au fost schimbate. Cum găsiți fiecare fișier authorized_keys și verificați fiecare intrare.
- [Criptominer pe serverul web: semne și mod de lucru](https://phpsos.de/ro/blog/kryptominer-auf-dem-server/): CPU plin permanent, fără ca să vină mai mulți vizitatori: poate fi un criptominer. Cum verificați încărcarea, găsiți procesul și mecanismele lui de repornire și procedați ordonat.
- [Serverul trimite spam: găsirea cauzelor](https://phpsos.de/ro/blog/server-verschickt-spam/): E-mailuri nelivrabile, liste de blocare, reclamații: când propriul server trimite spam, în spate se află de obicei un script sau o căsuță poștală deturnată. Cum găsiți sursa.
- [Spam SEO și pagini străine în indexul Google](https://phpsos.de/ro/blog/seo-spam-im-google-index/): Brusc, sub domeniul dumneavoastră se clasează pagini despre medicamente sau mărfuri de marcă. Cum aflați de unde vine spamul SEO și cum îl scoateți din nou din index.
- [Site-ul redirecționează către pagini străine](https://phpsos.de/ro/blog/website-leitet-um/): Vizitatorii ajung pe site-uri cu premii sau în magazine dubioase, iar dumneavoastră nu vedeți nimic? Cum găsiți stratul în care se ascunde redirecționarea și o eliminați.
- [Salvați probele înainte de a reinstala serverul](https://phpsos.de/ro/blog/beweise-sichern-vor-neuinstallation/): O reconstruire elimină atacatorul, dar și toate urmele. Cine investește mai întâi o oră în conservarea probelor poate spune ulterior ce s-a întâmplat.
- [Întocmirea cronologiei unui incident](https://phpsos.de/ro/blog/zeitleiste-eines-vorfalls/): Când a venit atacatorul, ce a făcut, când a fost observat? O cronologie curată răspunde la aceste întrebări și este baza pentru notificări, asigurare și raport.
- [Compararea fișierelor de bază ale CMS-ului cu originalul](https://phpsos.de/ro/blog/cms-kerndateien-vergleichen/): Comparația cu un original curat arată fiecare fișier modificat, indiferent dacă un scanner îl cunoaște. Cum construiți comparația pentru WordPress, proiecte Composer și pachete de sistem.
- [Verificarea bazei de date pentru cod introdus](https://phpsos.de/ro/blog/datenbank-auf-schadcode-pruefen/): Cine verifică doar fișierele ratează jumătate. Cum căutați în conținutul, setările, trigger-ele și conturile bazei de date cod introdus, doar în citire și pe o copie.
- [Scannere de malware pentru site-uri: ce găsesc și ce nu](https://phpsos.de/ro/blog/grenzen-von-malware-scannern/): Scannerul nu raportează nimic, deci totul e în regulă? Nu neapărat. Ce tipuri de scannere de site-uri există, ce vede fiecare și ce nu poate vedea, în principiu.
- [Izolarea pool-urilor PHP-FPM pentru fiecare site](https://phpsos.de/ro/blog/php-fpm-pools-isolieren/): Un pool propriu pentru fiecare site este începutul, nu sfârșitul. Cum verificați pool-urile existente și securizați socketurile, extensiile, paginile de stare, resursele și jurnalele.
- [Setarea corectă a memory_limit](https://phpsos.de/ro/blog/memory-limit-richtig-setzen/): memory_limit limitează memoria pentru fiecare cerere PHP. După PHP2Shell, php.net recomandă provizoriu contrariul. Ce se aplică în funcționarea normală, în perioada de tranziție și după actualizare.
- [Limitarea rezonabilă a post_max_size și upload_max_filesize](https://phpsos.de/ro/blog/post-max-size-upload-limits/): Limitele de upload acționează în trei locuri: în serverul web, în PHP și în aplicație. Cum stabiliți valorile coerent, inclusiv cu valorile provizorii de la php.net pentru PHP2Shell.
- [Dezactivarea session.upload_progress: corect și durabil](https://phpsos.de/ro/blog/session-upload-progress-abschalten/): Remediul pentru CVE-2026-115560 și una dintre măsurile provizorii PHP2Shell se stabilește repede. Ca să reziste, trebuie să fie la locul potrivit, blocat și reverificat după fiecare actualizare.
- [expose_php și antetele Server: ascunderea indicațiilor de versiune](https://phpsos.de/ro/blog/expose-php-versionsangaben/): PHP, Nginx și Apache își indică implicit numărul versiunii în fiecare răspuns. Asta nu protejează de atacuri, dar oferă scannerelor o listă de ținte la îndemână. Cum opriți asta și păstrați totuși privirea de ansamblu.
- [display_errors off: dezactivarea ieșirilor de erori în producție](https://phpsos.de/ro/blog/display-errors-produktion/): Mesajele de eroare PHP vizibile dezvăluie căi, nume de baze de date și versiuni. Cum le dezactivați în PHP, în framework și în serverul web, fără a pierde erorile din vedere.
- [php_admin_value: blocarea setărilor împotriva suprascrierii](https://phpsos.de/ro/blog/php-admin-value-sperren/): O setare de securitate folosește puțin dacă aplicația o schimbă la loc cu un singur rând de cod. Cu php_admin_value și php_admin_flag fixați obligatoriu valorile pentru PHP-FPM și Apache.
- [Stabilirea limitelor de memorie cu systemd și cgroups](https://phpsos.de/ro/blog/speichergrenzen-systemd-cgroups/): Ca măsură provizorie PHP2Shell, php.net recomandă memory_limit=-1 și o limită de memorie în afara PHP. Cum stabiliți această limită cu systemd și cgroups, fără ca un singur worker să tragă după el întregul serviciu.
- [Configurarea sigură a Nginx pentru PHP](https://phpsos.de/ro/blog/nginx-fuer-php-absichern/): Cele mai multe vulnerabilități din configurațiile Nginx pentru PHP nu se află în Nginx, ci în câteva rânduri din location-ul PHP. Cum configurați transmiterea către PHP-FPM astfel încât să fie executate doar scripturile dorite.
- [Configurarea sigură a Apache pentru PHP](https://phpsos.de/ro/blog/apache-fuer-php-absichern/): Apache este flexibil, iar tocmai de aceea este vulnerabil la configurări greșite. Cum conectați PHP prin PHP-FPM, închideți .htaccess ca ușă dosnică și setați sigur cele mai importante opțiuni de bază.
- [Interzicerea execuției PHP în dosarele de upload](https://phpsos.de/ro/blog/php-in-uploads-verbieten/): Un webshell are nevoie de două lucruri: un dosar în care poate fi scris și un server care îl execută. Cum îi luați al doilea element, în fiecare dosar scriibil, nu doar în uploads.
- [Filtrarea cererilor de upload la margine: oportunități și riscuri](https://phpsos.de/ro/blog/upload-anfragen-am-rand-filtern/): Autori de specialitate propun blocarea la proxy a cererilor de upload în afara căilor reale de upload, până când PHP este patchuit. Asta poate ajuta, dar poate paraliza și formulare și comenzi. Cum procedați controlat.
- [Utilizarea ModSecurity și a OWASP Core Rule Set](https://phpsos.de/ro/blog/modsecurity-owasp-crs/): Un Web Application Firewall propriu, cu ModSecurity și OWASP Core Rule Set, este gratuit și puternic, dar nu merge de la sine. Cum alegeți motorul, porniți fără căderi și reglați regulile.
- [Configurarea Fail2ban pentru servere web](https://phpsos.de/ro/blog/fail2ban-fuer-webserver/): Fail2ban blochează adresele care apar repetat în jurnale. Pentru servere web vine cu filtre gata făcute, iar cu câteva rânduri se adaugă filtre proprii. Cum îl configurați fără a vă bloca pe dumneavoastră sau pe clienți.
- [Firewall pentru servere web: deschideți doar porturile necesare](https://phpsos.de/ro/blog/firewall-fuer-webserver/): Un server web are nevoie spre exterior, de obicei, doar de două porturi. Totuși, pe multe servere ascultă în internet baze de date, PHP-FPM sau interfețe de administrare. Cum găsiți serviciile deschise și închideți ce nu este necesar.
- [Actualizări de securitate automate pe servere Linux](https://phpsos.de/ro/blog/automatische-sicherheitsupdates/): Potrivit rapoartelor, distribuțiile au livrat backporturile PHP parțial chiar la 21 octombrie 2026, ziua patchurilor. Cine folosește actualizări automate de securitate le-a avut repede pe server. Ca să și acționeze, sunt necesare reporniri, surse terțe și control.
- [Least Privilege: drepturile utilizatorului serverului web](https://phpsos.de/ro/blog/rechte-des-webserver-benutzers/): Codul introdus pe ascuns rulează cu drepturile utilizatorului serverului web. Ce are voie să facă acest cont stabilește cât de departe ajunge un atacator. Iată cum limitați shell-ul, sudo, cron, baza de date și sistemul de fișiere la strictul necesar.
- [Izolarea zonelor de administrare prin IP, VPN sau protecție suplimentară](https://phpsos.de/ro/blog/admin-bereiche-abschirmen/): De ce backend-ul unui site nu trebuie să fie accesibil pentru toată lumea și cum îl izolați prin lista de IP-uri permise, VPN sau autentificare prealabilă, fără să vă blocați singuri accesul.
- [Configurarea corectă a TLS și HTTPS](https://phpsos.de/ro/blog/tls-https-richtig-konfigurieren/): Ce versiuni TLS și cipher suites ar trebui să ofere astăzi un server web, după ce se orientează recomandările și cum verificați Nginx, Apache și conexiunile PHP de ieșire.
- [Benchmark-uri CIS și module BSI pentru servere web](https://phpsos.de/ro/blog/cis-benchmarks-bsi-bausteine/): Ce standarde de întărire există pentru serverele web Linux, prin ce se deosebesc benchmark-urile CIS de modulele IT-Grundschutz și cum faceți din ele o cerință verificabilă pentru serverele dumneavoastră PHP.
- [Stocarea sigură a parolelor în PHP: folosirea corectă a password_hash](https://phpsos.de/ro/blog/passwoerter-in-php-speichern/): Cum stochează dezvoltatorii parolele în PHP cu password_hash și password_verify, cum aleg procedeul potrivit și cum înlocuiesc hash-urile MD5 sau SHA-1 vechi fără resetarea parolei pentru toți utilizatorii.
- [Protecția CSRF în aplicațiile PHP](https://phpsos.de/ro/blog/csrf-schutz-php/): Cum previn dezvoltatorii Cross-Site Request Forgery în aplicațiile PHP: token-uri pentru fiecare cerere care modifică ceva, verificarea originii în antet și cookie-uri SameSite ca strat suplimentar.
- [Validarea și filtrarea intrărilor în PHP cu filter_var](https://phpsos.de/ro/blog/eingaben-validieren-php/): Cum verifică dezvoltatorii intrările în PHP cu filter_var, filter_input_array și liste de permisiuni, ce filtre sunt depășite și de ce validarea nu înlocuiește prepared statements și codarea la ieșire.
- [Prevenirea Command Injection în PHP](https://phpsos.de/ro/blog/command-injection-php/): Cum evită dezvoltatorii Command Injection în PHP: înlocuirea comenzilor de sistem cu funcții PHP, folosirea proc_open fără shell, verificarea argumentelor și găsirea locurilor periculoase din codul existent.
- [Prevenirea Server-Side Request Forgery (SSRF) în PHP](https://phpsos.de/ro/blog/ssrf-in-php/): Cum împiedică dezvoltatorii ca o aplicație PHP să interogheze sisteme interne în numele unor terți: liste de permisiuni, restricționarea protocolului, verificarea adresei rezolvate și limite în rețea.
- [Prevenirea XML External Entities (XXE) în PHP](https://phpsos.de/ro/blog/xxe-in-php/): Cum procesează dezvoltatorii XML în siguranță în PHP: comportamentul implicit al libxml, opțiuni riscante precum LIBXML_NOENT, protecția cu entity loader și LIBXML_NO_XXE și intrările XML ascunse tipice.
- [Type Juggling în PHP: comparațiile lejere ca risc de securitate](https://phpsos.de/ro/blog/type-juggling-php/): De ce comparațiile lejere cu == în PHP pot duce la vulnerabilități, ce s-a schimbat cu PHP 8.0 și cum scrieți robust comparațiile în autentificări, token-uri și permisiuni.
- [Numere aleatorii și token-uri sigure în PHP cu random_bytes](https://phpsos.de/ro/blog/sichere-tokens-php/): Cum generează dezvoltatorii în PHP token-uri pentru linkuri de parolă, chei API și coduri unice: surse sigure criptografic, lungime suficientă, stocare ca hash și valabilitate limitată.
- [Protejarea corectă a datelor de acces și a fișierelor .env](https://phpsos.de/ro/blog/env-dateien-schuetzen/): Cum protejați parolele de baze de date, cheile API și alte secrete în proiectele PHP: fișiere .env în afara webroot-ului, blocări în serverul web, drepturi restrânse și înlocuire ordonată după un incident.
- [Director .git public: o scurgere de date subestimată](https://phpsos.de/ro/blog/git-ordner-oeffentlich/): De ce un webroot distribuit prin Git poate dezvălui întregul cod sursă împreună cu istoricul, cum verificați acest lucru, îl blocați imediat și construiți durabil deployment-ul fără directorul .git.
- [Fișiere de backup în webroot: .zip, .sql și .bak](https://phpsos.de/ro/blog/backup-dateien-im-webroot/): De ce dump-urile de baze de date, arhivele și copiile de siguranță din directorul public se numără printre cele mai frecvente scurgeri de date, cum le găsiți, le blocați și clarificați dacă au fost accesate.
- [Fișiere phpinfo(): de ce trebuie să dispară](https://phpsos.de/ro/blog/phpinfo-dateien-entfernen/): După PHP2Shell, mulți administratori creează repede un info.php. De ce astfel de fișiere sunt o scurgere de date, cum le găsiți și ce căi de verificare sunt mai bune.
- [Dependențe la zi: Composer, npm și pluginuri](https://phpsos.de/ro/blog/abhaengigkeiten-aktuell-halten/): Un proiect constă din trei lumi de pachete: Composer, npm și pluginuri CMS. Cum le țineți la zi pe toate trei, cu un ritm fix, responsabilitate clară și teste.
- [Code review de securitate pentru proiecte PHP](https://phpsos.de/ro/blog/sicherheits-code-review-php/): Cum parcurg echipele țintit codul PHP propriu în căutarea vulnerabilităților: tipuri de review, funcții critice, instrumente utile și o listă de verificare.
- [Jurnalizare sigură: înregistrarea erorilor fără scurgeri de date](https://phpsos.de/ro/blog/sicher-loggen-php/): Jurnalele ajută la depanare și la analiza criminalistică, dar devin ele însele rapid o scurgere de date. Ce ar trebui să înregistreze aplicațiile PHP, ce niciodată și cum se protejează jurnalele.
- [Securizarea API-urilor REST în PHP](https://phpsos.de/ro/blog/rest-api-php-absichern/): Interfețele sunt adesea mai prost protejate decât site-ul din fața lor. Cele mai importante reguli pentru API-urile REST în PHP, de la autorizarea pe obiect până la limitarea ratei.
- [Contracte cu furnizorii IT: reglementarea clară a obligațiilor de securitate](https://phpsos.de/ro/blog/dienstleistervertrag-sicherheit/): PHP2Shell a arătat cât de des nu este clar cine trebuie să aplice patch-urile. Ce obligații de securitate aparțin în contractele cu agenția, furnizorul de hosting și furnizorul IT.
- [Prelucrarea datelor în numele operatorului, când furnizorii accesează serverele](https://phpsos.de/ro/blog/auftragsverarbeitung-serverzugriff/): Cine lasă terți să acceseze servere cu date ale clienților are de regulă nevoie de un acord de prelucrare. Ce cere art. 28 RGPD și cum organizați accesele în caz de urgență conform protecției datelor.
- [Managementul vulnerabilităților în întreprinderile mijlocii](https://phpsos.de/ro/blog/schwachstellenmanagement-mittelstand/): Nicio întreprindere mijlocie nu poate trata imediat fiecare avertizare. Un ciclu simplu de înregistrare, evaluare, decizie și dovadă face ca lucrurile importante să se întâmple primele.
- [Să știți ce rulează: inventarul tuturor site-urilor și serverelor](https://phpsos.de/ro/blog/inventar-websites-server/): La PHP2Shell, mulți nu au eșuat la patch, ci la întrebarea unde rulează de fapt PHP. Iată cum alcătuiți un inventar al tuturor site-urilor și serverelor.
- [Patch management ca proces, nu ca intervenție de urgență](https://phpsos.de/ro/blog/patch-management-prozess/): Cine aplică patchuri doar când arde pierde timp în caz de urgență. Cum leagă un proces de patch management, cu clase, ferestre și dovezi fixe, rutina de urgență.
- [Contacte de urgență: cine trebuie informat și când?](https://phpsos.de/ro/blog/notfallkontakte-liste/): În caz de urgență contează pe cine reușiți să contactați și când. Cum alcătuiți o listă a contactelor IT de urgență, cu declanșatori, înlocuitori și datele de care are nevoie fiecare apel.
- [Cât costă un server spart: posturile de cost](https://phpsos.de/ro/blog/kostenposten-eines-hacks/): Un server web spart generează mai multe costuri decât repararea. Ce posturi de cost apar și cum justificați cu cifre proprii un buget pentru prevenție.
- [Informarea clienților după un incident](https://phpsos.de/ro/blog/kunden-nach-vorfall-informieren/): Obligație sau decizie voluntară: cum stabiliți după un incident pe cine informați, ce canale sunt sigure și cum este pregătit serviciul dumneavoastră pentru clienți.
- [Lanțul de aprovizionare web: agenție, furnizor de hosting, furnizori de pluginuri](https://phpsos.de/ro/blog/lieferkette-agentur-hoster/): PHP2Shell a arătat câte verigi se află între un patch și site-ul dumneavoastră. Cum cunoașteți și securizați lanțul site-ului și cum preluați căderea unor verigi.
- [Conștientizarea securității pentru administratori și redactori: security awareness în echipa web](https://phpsos.de/ro/blog/sicherheitsbewusstsein-redaktion/): Cine întreține site-uri decide zilnic asupra securității, adesea fără să observe. Iată cum instruiți administratorii și redactorii pe roluri și fără avalanșă de prezentări.
- [Exercițiu de urgență la masă: simularea unui incident pe serverul web](https://phpsos.de/ro/blog/notfalluebung-am-tisch/): Un exercițiu la masă costă o după-amiază și arată dacă planul dumneavoastră de urgență rezistă. Aici găsiți un scenariu gata făcut pentru un incident pe un server web PHP.
- [ISO 27001 și TISAX: ce privește serverele web](https://phpsos.de/ro/blog/iso-27001-tisax-webserver/): Cine operează un SMSI conform ISO 27001 sau deține o etichetă TISAX trebuie să ia în calcul și serverele web. Iată ce cerințe le ating și ce dovezi contează după PHP2Shell.
- [VdS 10000: securitatea informațiilor pentru întreprinderile mici și mijlocii](https://phpsos.de/ro/blog/vds-10000-kmu/): VdS 10000 este un cadru suplu pentru securitatea informațiilor în întreprinderile mijlocii. Ce cere, ce a fost nou în 2025 și ce înseamnă pentru site-uri și servere web.
- [Lessons learned: cum deveniți mai buni după incident](https://phpsos.de/ro/blog/lessons-learned-nach-vorfall/): După incident este înainte de următorul. O discuție structurată de final, fără acuzații, transformă o săptămână proastă într-un progres măsurabil.
- [Actualizăm, oprim sau așteptăm? Un ajutor de decizie pentru breșa PHP](https://phpsos.de/ro/blog/patchen-abschalten-abwarten/): La o breșă critică în PHP, responsabilii trebuie să decidă rapid. Acest ajutor ordonează cele trei opțiuni, enumeră criterii și arată când așteptarea este justificabilă.
- [WAF sau actualizare: de ce aveți nevoie de ambele](https://phpsos.de/ro/blog/waf-oder-update/): Un Web Application Firewall poate opri atacuri, dar nu închide o breșă din interpretorul PHP. Când ajută un WAF, unde se oprește și cum le combinați sensibil pe ambele.
- [Reinstalăm serverul sau îl curățăm? Decizia după o infectare](https://phpsos.de/ro/blog/neu-aufsetzen-oder-bereinigen/): După o intruziune sunt deschise două căi: curățați serverul sau îl reconstruiți. Ce criterii decid și de ce ordinea contează mai mult decât alegerea.
- [Remediați singuri sau apelați la un furnizor? O cântărire sinceră](https://phpsos.de/ro/blog/selbst-beheben-oder-dienstleister/): Nu orice situație de securitate necesită ajutor extern. Cu aceste criterii și un scurt autotest decideți dacă echipa dumneavoastră se descurcă singură cu PHP2Shell sau are nevoie de sprijin.
- [Alegerea unui furnizor de servicii de securitate IT: 12 întrebări înainte de comandă](https://phpsos.de/ro/blog/sicherheitsdienstleister-auswaehlen/): Să găsești sub presiunea timpului un furnizor bun de securitate este greu. Aceste douăsprezece întrebări ajută la compararea obiectivă a ofertelor, fără a cădea în promisiuni publicitare.
- [Hosting administrat sau server propriu? Comparația de securitate](https://phpsos.de/ro/blog/managed-oder-eigener-server/): PHP2Shell a fost un test de stres pentru fiecare model de operare. Comparația arată când hostingul administrat este mai sigur, când serverul propriu și ce forme mixte s-au dovedit utile.
- [Upgrade PHP sau backport? Decizia pentru sistemele vechi](https://phpsos.de/ro/blog/php-upgrade-oder-backport/): Pentru versiunile PHP vechi există după PHP2Shell mai multe căi: backport al distribuției, sursă terță, patch din sursă, suport pe termen lung sau upgrade. Cât valorează fiecare cale și cât durează.
- [Schimbăm CMS-ul după atac? Când ajută și când nu](https://phpsos.de/ro/blog/cms-wechsel-nach-hack/): După o intruziune, încrederea în CMS dispare adesea. Dar un sistem nou rezolvă rareori cauza reală. Când este sensibilă schimbarea și cum reușește ea curat.
- [Site-uri statice: mai puțin PHP, mai puțină suprafață de atac](https://phpsos.de/ro/blog/statische-website-alternative/): Un site static livrează fișiere HTML gata făcute și nu are nevoie de PHP pe server. Aceasta reduce clar suprafața de atac, dar aduce limite și obligații proprii.
- [Pentest, bug bounty sau scanare de vulnerabilități? Alegerea procedurii potrivite](https://phpsos.de/ro/blog/pentest-bugbounty-scan/): Scanarea, testul de penetrare și bug bounty verifică site-urile în moduri foarte diferite. Ce oferă fiecare procedură, unde dă greș și ce ordine se potrivește companiei dumneavoastră.