# Urgență PHP? Sunați sau scrieți pe WhatsApp: vă ajutăm

> Server PHP căzut, supraîncărcat sau suspect? Vorbiți direct cu un expert. Sunați-ne sau scrieți-ne pe WhatsApp, iar noi preluăm cazul la distanță.

Sursa: https://phpsos.de/ro/soforthilfe/php-notfall-hilfe/  
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

**Pe scurt:** Dacă serverul dumneavoastră PHP are probleme și vreți să vorbiți direct cu un expert, sunați-ne sau scrieți-ne pe WhatsApp. Sunteți afectat? Sunați-ne. Vă ajutăm. Clarificăm la distanță dacă în spate se află o defecțiune, o configurare greșită sau un atac și preluăm cazul de la primul mesaj, până când incidentul este încheiat și documentat.

> **Acționați imediat:**
> **Acum nu ștergeți nimic și nu reinstalați nimic.** Și o repornire sau un rollback poate șterge urme. Descrieți-ne mai întâi ce vedeți. [Anunțați urgența](https://phpsos.de/ro/notfall/), iar apoi stabilim următorul pas.

## Sunteți afectat? Aceste defecțiuni sunt cazul nostru

Nu fiecare defecțiune este un atac, dar în aceste zile merită să verificați. Contactați-ne dacă la sistemul dumneavoastră PHP apare ceva din cele de mai jos:

- Procesele PHP sau serverul web se întrerup, repornesc continuu sau sunt încheiate de sistem (cod de ieșire 137).
- Încărcarea crește fără un motiv vizibil sau memoria se umple.
- Paginile livrează răspunsuri goale, erori 500 sau mesaje de eroare care nu existau înainte.
- Sub serverul web sau PHP-FPM rulează procese care pornesc un shell.
- În dosarul de încărcare sau de cache se află fișiere PHP pe care nu le cunoașteți.
- După o actualizare PHP, o aplicație nu mai funcționează.
- Furnizorul dumneavoastră de hosting a blocat accesul sau a oprit pagina.

Diferența dintre o defecțiune și un atac se vede de obicei abia în loguri. Primele indicii despre ce contează descrie articolul [Serverul web pornește un shell](https://phpsos.de/ro/blog/webserver-startet-shell/).

## Ce faceți imediat

1. **Observați înainte de a interveni.** Notați ora, mesajele de eroare și ce s-a modificat ultima dată (actualizare, plugin, configurație).
2. **Salvați logurile.** Copiați jurnalele serverului web, ale PHP și ale sistemului înainte să fie rotite. Presa de specialitate recomandă păstrarea logurilor începând cu 20.10.2026.
3. **Nu reporniți pe orbește.** O repornire remediază unele defecțiuni, dar distruge urmele volatile. Reporniți dacă activitatea o impune și notați ce ați făcut.
4. **Cântăriți accesibilitatea.** Dacă bănuiți un atac, izolarea sau oprirea este adesea corectă. BSI o recomandă dacă actualizarea nu este posibilă imediat.
5. **Stabiliți versiunea PHP.** `php -v` arată versiunea, dar nu întotdeauna pe cea din mediul de execuție al serverului web.
6. **Sunați sau scrieți.** Cu cât puteți descrie mai exact situația, cu atât ajungem mai repede la miez.

## Cum ajută PHP SOS concret?

Lucrăm la distanță, fără deplasare, în toată Germania și Europa.

1. **Imaginea situației:** În prima discuție ascultăm și punem întrebări țintite: sisteme, modul de operare PHP, momentul, ultimele modificări. Apoi știți dacă vedem o defecțiune sau bănuiala unui atac.
2. **Salvare și închidere:** Salvăm starea, remediem cauza și, dacă este necesar, închidem vulnerabilitatea prin actualizare, repornire și măsuri provizorii.
3. **Verificare și curățare:** Dacă se arată o intruziune, eliminăm codul malițios, verificăm accesurile și secretele. Altfel documentăm cauza și lăsăm activitatea să ruleze curat.
4. **Securizare și raport:** Primiți un scurt raport și recomandări, pentru ca defecțiunea să nu se repete.

Dacă în spate se află mai mult, trecem la [ajutorul de urgență pentru site hackuit](https://phpsos.de/ro/leistungen/website-gehackt-notfallhilfe/) sau la [Incident Response](https://phpsos.de/ro/leistungen/incident-response/) structurat.

## Memorie, întreruperi și noua limită

De la versiunile de securitate din 21.10.2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35) există directiva `memory_hard_limit_percent`. De atunci, `memory_limit` este o limită moale. Fără o setare proprie, ca limită fermă se aplică dublul lui `memory_limit` până la 1G, peste aceasta `memory_limit` plus 1G. Dacă este depășită, procesul se încheie imediat cu codul de ieșire 137. O activitate care rula înainte de actualizare aproape de limită poate astfel arăta brusc întreruperi. Nu este un atac, ci o consecință a corecturii, iar soluția este adaptarea curată a aplicației sau a limitei, nu retragerea actualizării.

Invers se aplică: cine vede procese căzute și nu a aplicat încă patchul nu ar trebui să le considere o coincidență, pentru că vulnerabilitatea CVE-2026-109618 este legată de o stare Out-of-Memory. Dacă acest lucru contează la dumneavoastră arată logurile. Context despre gestionarea memoriei găsiți la [Out-of-Memory în PHP](https://phpsos.de/ro/php/out-of-memory/), iar posibile semne de intruziune la [Procese suspecte sub Linux](https://phpsos.de/ro/blog/verdaechtige-prozesse-linux/).

## Când intervine furnizorul de hosting

Unii furnizori blochează conturi sau scot paginile din rețea preventiv. Aceasta nu înseamnă automat că ați fost hackuit, dar poate fi o consecință a unor anomalii. Întrebați care este motivul și momentul, cereți logurile și notați ce cere furnizorul. Ne coordonăm cu furnizorul dumneavoastră de hosting dacă doriți. Este util să clarificați în prealabil cine poate lua decizii la furnizor și dacă acolo există jurnale ale serverului pe care dumneavoastră nu le puteți vedea. Astfel de date, de exemplu accesările la nivel de rețea, pot fi decisive mai târziu, când este vorba de a delimita momentul unei posibile intruziuni.

## Ce ar trebui să ne trimiteți

- scurtă descriere: ce a căzut sau este neobișnuit, de când?
- tipul sistemului (server propriu, pachet de hosting, container) și furnizorul de hosting
- rezultatul comenzii `php -v`, modul de operare și serverul web, în măsura în care le cunoașteți
- mesajele de eroare sau fragmente din loguri
- momentul ultimei actualizări PHP și al ultimelor modificări
- o persoană de contact cu competență de decizie pentru reporniri

## De ce PHP SOS

Lucrăm Made in Germany și suntem specializați în securitate IT de peste 25 de ani, împreună cu rețeaua noastră de parteneri din profesioniști cyber. Vorbiți cu un interlocutor stabil, nu cu un sistem de tichete. Lucrăm la distanță, documentăm ce vedem și ce facem și spunem deschis ce este dovedit și ce nu. Pentru cazurile acute legate de vulnerabilitate există, în plus, [ajutorul de urgență PHP2Shell](https://phpsos.de/ro/leistungen/php2shell-soforthilfe/).

## Sunteți afectat? Sunați-ne. Vă ajutăm.

Dacă serverul dumneavoastră PHP are probleme, nu așteptați următoarea cădere. Sunați-ne sau scrieți-ne pe WhatsApp. Preluăm cazul de la primul mesaj. [Anunțați acum urgența](https://phpsos.de/ro/notfall/).


## Întrebări frecvente

**Serverul meu PHP a devenit brusc lent sau se blochează: este un atac?**  
Nu neapărat. Defecțiunile au adesea cauze banale, precum memorie insuficientă, o actualizare defectuoasă sau o supraîncărcare. Abia o privire în loguri și procese arată dacă este un atac; semne de avertizare sunt, de exemplu, procesele shell sub serverul web sau fișierele PHP noi necunoscute.

**Ce înseamnă codul de ieșire 137 la procesele PHP?**  
Codul 137 indică un proces încheiat imediat. Potrivit manualului PHP, un proces se încheie cu 137 când depășește limita fermă de memorie a noii directive memory_hard_limit_percent; el poate fi însă încheiat și de sistem din cauza lipsei de memorie. Cauza o clarifică o privire în loguri.

**Pot vorbi la telefon cu un expert înainte de a schimba ceva?**  
Da, exact pentru aceasta există ajutorul de urgență. Sunați-ne sau scrieți-ne pe WhatsApp și descrieți ce observați. Vă spunem ce ar trebui să lăsați neatins și ce puteți face fără pericol.

**Ar trebui să repornesc pur și simplu serviciul PHP?**  
O repornire poate remedia o defecțiune, dar șterge indicii din memoria de lucru. Dacă o intruziune este posibilă, salvați mai întâi logurile și cereți sfaturi. După o actualizare PHP, în schimb, repornirea este obligatorie.

**Lucrați și dacă serverul meu se află la un furnizor de hosting?**  
Da, lucrăm la distanță cu accesul pe care îl aveți și ne coordonăm la nevoie cu furnizorul dumneavoastră de hosting. Ce verificări sunt posibile depinde de drepturile dumneavoastră.

## Surse

- [php.net: comunicate de securitate](https://www.php.net/)
- [Manualul PHP: configurația de bază (ini.core)](https://www.php.net/manual/en/ini.core.php)
- [BSI: Oficiul Federal German pentru Securitatea Informațiilor](https://www.bsi.bund.de/)