PHP2Shell: კოდი იყო სწორი, ძრავა — არა

გამარჯობა, მე ვარ მანეშვარი და ვქმნი LiveReview-ს — AI კოდის რევიუს, რომელიც გავლენის რადიუსს ითვალისწინებს და შექმნილია თქვენი ბიზნესისთვის კრიტიკული სისტემებისთვის. მოგვცით ვარსკვლავი, რომ დეველოპერებმა პროექტი აღმოაჩინონ, სცადონ და უკუკავშირით დაგვეხმარონ პროდუქტის გაუმჯობესებაში.

წარმოიდგინეთ, რომ ყველაფერს სწორად აკეთებთ.

ამოწმებთ შეყვანილ მონაცემებს. იყენებთ მომზადებულ შეკითხვებს (prepared statements). ეკრანირებთ გამოტანილ მონაცემებს. გაქვთ ლინტერი, კოდის რევიუს პროცესი და ოდნავ თვითკმაყოფილი Slack არხი სახელად #security-wins.

შემდეგ ვიღაცა თქვენს სერვერს ერთ უცნაურ HTTP მოთხოვნას უგზავნის, და ის თქვენი კოდის ნაცვლად მათ კოდს უშვებს.

არა იმიტომ, რომ რაიმე თქვენ დაწერეთ.

არამედ იმიტომ, რომ PHP-მ საკუთარი თავის დალაგებისას რაღაც გააკეთა.

2026 წლის 21 ოქტომბერს PHP-ის პროექტმა გამოუშვა უსაფრთხოების განახლება ორი კრიტიკული ხარვეზისთვის, CVE-2026-109618 და CVE-2026-109619.

ინტერნეტმა ამ წყვილს უკვე PHP2Shell შეარქვა, რაც შესანიშნავი სახელია და საშინელი ოთხშაბათი.

გავიაროთ, რა სინამდვილეში გატყდა და რატომ არის ეს უფრო დიდი საქმე, ვიდრე „კიდევ ერთი CVE“, და ასევე ის, სად უსწრებს საშინელი სათაურები ფაქტებს.

რატომ განსხვავდება ეს შემთხვევა

PHP ნიშურ ენას არ წარმოადგენს. W3Techs-ის მონაცემით, სერვერულ ენად ამოცნობადი ვებსაიტების 69.3% PHP-ზე მუშაობს.

WordPress, Laravel, Drupal, Magento და ის 2014 წლის ინვოისების პორტალი, რომელსაც ვერავინ ბედავს შეხება.

PHP-ის უმეტესი დაუცველობა აპლიკაციაში ან პლაგინში ცხოვრობს. ასწორებთ პლაგინს და გრძელდებით.

ეს ორი კი ძრავაში ცხოვრობს.

ძრავა არის ის, რაც თქვენს კოდს ქვემოთ უდევს. ეს არის C პროგრამა, რომელიც ამუშავებს თქვენს PHP-ს, გამოყოფს თქვენთვის მეხსიერებას და ყოველი მოთხოვნის შემდეგ ანგრევს.

შეგიძლიათ დაწეროთ თქვენი ცხოვრების ყველაზე მოსაწყენი, სწორი PHP, და მის ქვეშ მაინც შეიძლება იყოს ხვრელი.

[DIAGRAM PLACEHOLDER] სტეკი, ქვემოდან ზემოთ: ვებ სერვერი (Apache ან nginx), SAPI (mod_php ან PHP-FPM), PHP ძრავა, შემდეგ თქვენი აპლიკაციის კოდი ზემოთ. ძრავის ფენა მონიშნეთ წითლად წარწერით „ორივე ხარვეზი აქ ცხოვრობს, თქვენ მიერ დაწერილის ქვემოთ“. აჩვენეთ, რომ თავდამსხმელის მოთხოვნა ძრავაში უნდა გაიაროს, სანამ თქვენი კოდი მას დაინახავს.

ორივე ხარვეზი ერთ, არც თუ ისე ბრწყინვალე რამეს ეხება: მეხსიერების მართვას მოთხოვნის არასწორად დასრულების დროს.

იმის გასაგებად, რატომ, უნდა იცოდეთ, როგორ ატარებს PHP თავის ცხოვრებას.

PHP-ის ცხოვრება ერთი მოთხოვნის სიგრძისაა

PHP-ის მოდელი ცნობილია როგორც „არაფერს არ იზიარებს“.

მოთხოვნა შემოდის, PHP მისთვის ახალ პატარა სამყაროს ქმნის, უშვებს თქვენს სკრიპტს და შემდეგ მთელ ამ სამყაროს აგდებს.

სამუშაო პროცესი რჩება, მაგრამ მოთხოვნის მდგომარეობა მოთხოვნასთან ერთად უნდა მოკვდეს.

სწორედ ამიტომ არის PHP ასეთი მიმტევებელი. სკრიპტში მეხსიერება გაჟონა? არავის არ ადარდებს, მოთხოვნა სრულდება და მეხსიერება უბრუნდება სისტემას.

აი, ნორმალური მიმდინარეობა:

flowchart LR
    A([Request arrives]):::start --> B[Request startup<br/>build per-request state]:::engine
    B --> C[Run your script]:::app
    C --> D[Request shutdown<br/>cleanup and free]:::engine
    D --> E([Worker waits for the next request]):::start
    E --> A

    classDef start fill:#e9ecef,stroke:#6c757d,color:#1a1a1a
    classDef engine fill:#9d8cff,stroke:#5b4bcc,color:#1a1a1a
    classDef app fill:#5ee6c8,stroke:#1f9c86,color:#1a1a1a

შეამჩნევთ, რომ იისფერი ყუთები, დაწყება და დასრულება, ძრავის საქმეა.

თქვენი კოდი მხოლოდ შუაში მდებარე ცისფერს ეკუთვნის.

ორივე ხარვეზი იმაზეა, რა ხდება, როცა რამე არასწორად მიდის ამ იისფერ ყუთებს შორის, და ძრავის დამლაგებელი კოდი იმ მდგომარეობას ეყრდნობა, რომელიც აღარ არსებობს.

PHP-ს აქვს მკაცრი ზღვარი, რამდენი მეხსიერება შეუძლია ერთ მოთხოვნას, memory_limit. როცა მას მიაღწევს, PHP მოთხოვნას მაშინვე წყვეტს.

„მაშინვე წყვეტს“ არის ის ადგილი, სადაც პრობლემა იწყება.

ხარვეზი 1: სახლის დანგრევა, რომელიც არასდროს აშენებულა

CVE-2026-109618, მეხსიერების ამოწურვის შემთხვევა.

აი სცენარი, გადმოცემული PHP Foundation-ის წერილიდან და Rapid7-ის ანალიზიდან.

PHP მოთხოვნის დაწყების შუაში იმყოფება. ის ამ მოთხოვნაზე მდგომარეობას ნაწილ-ნაწილ აგებს.

მეხსიერების გამოყოფა ვერ ხერხდება. PHP მოთხოვნას მოულოდნელად წყვეტს.

მაგრამ მდგომარეობა მხოლოდ ნახევრადაა აგებული. ზოგი ველი დაყენებულია, ზოგი კი იმ ბაიტებს შეიცავს, რომლებიც მეხსიერებაში შემთხვევით იყო.

შემდეგ მუშაობს დამლაგებელი კოდი და აკეთებს იმას, რასაც დამლაგებელი კოდი აკეთებს: ენდობა მდგომარეობას, რომელიც მას გადაეცა.

ის მიჰყვება მაჩვენებლებს, რომლებიც არასდროს ინიციალიზებულა. ათავისუფლებს იმას, რაც არასდროს გამოყოფილა. ნაგვს სტრუქტურად აღიქვამს.

ჩემი საყვარელი მოდელი ასეთია: დემონტაჟის ბრიგადა შენობის დასანგრევად იგზავნება.

შენობა არასდროს დამთავრებულა, ხოლო ნახაზი შემთხვევითი ნაკაწრებით დაფარული სალფეტკაა.

ბრიგადა მაინც სალფეტკას მიჰყვება და ანგრევს იმას, რასაც ნაკაწრები ანიშნებს.

აი ხარვეზის ფორმა, განზრახ გამარტივებული ესკიზით. ეს არ არის PHP-ის რეალური წყარო, მხოლოდ შაბლონია:

// simplified illustration of the bug class, not actual PHP code
int request_startup(request *r) {
    r->headers = alloc_table();     // ok
    r->uploads = alloc_table();     // out of memory! bail out...
    if (!r->uploads) return FAILURE;
    r->hooks   = alloc_table();     // never reached, r->hooks is junk
    return SUCCESS;
}

void request_shutdown(request *r) {
    free_table(r->headers);
    free_table(r->uploads);
    free_table(r->hooks);           // frees a pointer nobody ever set
}

შეცდომა არც ერთ ფუნქციაში ცალკე არ არის. ის იმ დაშვებაშია, რომ დასრულება მხოლოდ სრულად დაწყებულ მოთხოვნაზე ხდება.

ახლა კი ის ნაწილი, რომელიც ამას ცუდს ხდის.

როგორ გააკეთოთ, რომ სერვერს მეხსიერება განზრახ ამოეწუროს? არაფერი გატეხოთ არ გჭირდებათ, უბრალოდ არასწორად და ზედმეტად ითხოვეთ.

Rapid7 აღნიშნავს, რომ სპეციალურად შედგენილ multipart მოთხოვნებს შეუძლიათ მეხსიერების ამოწურვა მაშინაც, როცა მათი ზომა კონფიგურირებულ ლიმიტებში ჩანს.

ხოლო Apache-ზე mod_php-ით, ნაჩვენები შეტევა თქვენი აპლიკაციის კოდის გაშვებამდე ხდება.

სწორედ ამიტომაა სიმართლე ფრაზა „ავტორიზაციის გარეშე“. არ არსებობს შესვლა, რომლის გვერდის ავლაც საჭიროა. თქვენმა კოდმა უარის თქმის შანსიც კი ვერ მიიღო.

მეხსიერების კორუფცია, რომლის გამოწვევა მოთხოვნით შეიძლება იმ ადგილას, რომელსაც თქვენი აპლიკაცია ვერ იცავს, არის ის, რაც სათაურში „9.2 კრიტიკული“ გხვდებათ.

ხარვეზი 2: წარსული მოთხოვნების აჩრდილი

CVE-2026-109619, მოძველებული მდგომარეობის შემთხვევა.

იგივე ოჯახი, სხვა ვარიანტი.

გახსოვდეთ, რომ სამუშაო პროცესი მოთხოვნას მოთხოვნის მიყოლებით ამუშავებს. ზოგი სააღრიცხვო მდგომარეობა გლობალურია სამუშაო პროცესისთვის და მოთხოვნებს შორის უნდა განულდეს.

ახლა წარმოიდგინეთ ეს მიმდევრობა:

sequenceDiagram
    participant A as Request A
    participant W as PHP worker
    participant B as Request B
    A->>W: runs, global state points at memory M
    W->>W: fatal error interrupts cleanup
    W-->>W: M is freed, but the pointer to M is not cleared
    B->>W: arrives on the same worker
    W->>W: reads the old pointer before init resets it
    Note over W: use-after-free: B is reading memory it does not own

ფატალურმა შეცდომამ, მაგალითად მეხსიერების ამოწურვამ ან დროის ლიმიტმა, შეიძლება დამლაგებლის შუაში შეაწყვიტოს მუშაობა.

მეხსიერება თავისუფლდება, მაგრამ მასზე მაჩვენებელი რჩება. შემდეგი მოთხოვნა იმავე სამუშაო პროცესზე მოდის, და რაღაც ამ მაჩვენებელს კითხულობს, სანამ ნორმალური ინიციალიზაცია მას გაასუფთავებს.

ეს კლასიკური use-after-free არის. სახელი საუკეთესო ნაწილია, რადგან ის, რასაც თავისუფლების შემდეგ იყენებთ, სინამდვილეში არ არის თავისუფალი, ის ძალიან ძვირია.

წარმოიდგინეთ სასტუმროს ოთახი, რომელიც დაინგრა, მაგრამ საკეტის ბარათი მაინც აღებს კარს.

ვინც შემდეგ იქ დადგება, გადაწყვეტს, რა არის შიგნით.

Rapid7 აღწერს ორ კონკრეტულ გზას, რომლითაც ამასთან მისვლა შეიძლება.

ერთი არის PHP 8.5-ის ფატალური შეცდომის backtrace ფუნქცია, რომელიც ნაგულისხმევად ჩართულია და mod_php-ზე დადასტურდა. მეორე არის სესიის ატვირთვის პროგრესის გზა, რომელიც PHP-FPM-ზე მუშაობს და საჭიროებს, რომ აპლიკაციის ოპერაციამ წინასწარ დატოვოს მდგომარეობა.

ყურადღება მიაქციეთ შაბლონს. არც ერთი ხარვეზი არ ეხება დაკარგულ საზღვრების შემოწმებას რომელიმე პარსერში. ორივე შეცდომის გზებს ეხება.

PHP-ის ნორმალურ გზას ათწლეულების განმავლობაში ატესტებდნენ. გზა, სადაც მოთხოვნა ყველაზე ცუდ მომენტში კვდება, ის არის, რომელსაც ნაკლებად უყურებენ.

ასე ვინმეს შეუძლია ინტერნეტის 70% გატეხვა?

მოკლე პასუხი: არა, და ღირს სიზუსტე, რადგან ამ ისტორიის სათაურებიანი ვერსია უფრო მეტს ჰპირდება, ვიდრე აძლევს.

რა არის მტკიცე:

ორივე ხარვეზი რეალურია და შეფასებულია 9.2-ით (CVSS 4.0). ორივე შეიძლება გამოიწვიოს კოდის შესრულება ვებ სამუშაო პროცესის მომხმარებლის სახელით, ავტორიზაციის გარეშე.

RCE დემონსტრირებული იქნა მკვლევარების მიერ, რეალურ კონფიგურაციებზე, და არა მხოლოდ კრაშებზე.

mod_php ყველაზე მაღალი რისკის მქონეა. Rapid7 აღნიშნავს, რომ OOM ხარვეზისთვის mod_php დამლაგებელს მაშინაც უშვებს, როცა დაწყება ჩავარდა. PHP-FPM კლავს სამუშაო პროცესს, როცა დაწყება ჩავარდება, რაც ამ კონკრეტულ მიმდევრობას ბლოკავს.

რა არის უფრო ნიუანსირებული:

„ნებისმიერი PHP სერვერი“ ზედმეტად ძლიერი გამოთქმაა. Rapid7-მა გადახედა რამდენიმე საჯარო proof of concept-ს, და თითოეული მუშაობს მხოლოდ OS-ის, PHP-ის ვერსიის და ვებ სერვერის კონკრეტულ კომბინაციაზე. არცერთი ჯერ ფართოდ სანდო არ არის.

შეტევის სირთულე შეფასებულია როგორც მაღალი. მეხსიერების კორუფციის ექსპლოიტები დელიკატურია. ეს სიჩქარის ბარიერია, კედელი არა.

ექსპლუატაციის შესახებ ცნობები არაერთგვაროვანია. watchTowr ამბობს, რომ მათმა honeypot-ებმა ველურ პირობებში ექსპლუატაცია დააფიქსირეს, ხოლო Rapid7-მა მცდელობები ნახა, მაგრამ ველურ პირობებში კომპრომეტაცია არ დაუდასტურებია.

როგორც არ უნდა დასრულდეს ეს, Rapid7 ასევე აფრთხილებს, რომ უფრო პორტაბელური ტექნიკა შეიძლება მალე გამოჩნდეს.

და დაუცველი ზედაპირი პატარა არ არის. Palo Alto-ს Unit 42-ის მოკლე მიმოხილვა ციტირებს ტელემეტრიას, რომელიც ითვლის 22 მილიონზე მეტ პოტენციურად დაუცველ, ინტერნეტთან დაკავშირებულ ინსტანციას. ეს მწარმოებლის რიცხვია, ასე რომ ეჭვით მიუდექით, მაგრამ „ბევრის“ სწორი რიგის სიდიდეა.

თუ შევაჯამებ: ეს არ არის ვების დასასრული, მაგრამ არც წვრთნაა.

ის ნაწილი, რომელიც რეალურად შეუწუხებელი არ არის

აი ისტორია პატჩის მიღმა, და ეს მთელი ამბის ყველაზე ადამიანური ნაწილია.

flowchart LR
    A[2024<br/>Quarkslab audit,<br/>first signs of the OOM issue]:::early --> B[Fix stalls<br/>competing patches,<br/>each with trade-offs]:::slow
    B --> C[Aug 2026<br/>Calif, OpenAI and Wiz<br/>report it, RCE shown]:::report
    C --> D[Oct 20<br/>CVE IDs leak<br/>2 days early]:::bad
    D --> E[Oct 21<br/>Chainguard images<br/>break the embargo]:::bad
    E --> F[Oct 21, 14:00 UTC<br/>patched releases ship]:::good

    classDef early fill:#6ea8ff,stroke:#3a6fcc,color:#1a1a1a
    classDef slow fill:#f4d35e,stroke:#b8991f,color:#1a1a1a
    classDef report fill:#9d8cff,stroke:#5b4bcc,color:#1a1a1a
    classDef bad fill:#ff9a5c,stroke:#cc6a2a,color:#1a1a1a
    classDef good fill:#5ee6c8,stroke:#1f9c86,color:#1a1a1a

PHP Foundation-ის თანახმად, 2024 წელს Quarkslab-ის გარე აუდიტმა ერთ ძირითად დეველოპერს OOM პრობლემის პირველი ნიშნები შეამჩნევინა, სხვა რამის გასწორებისას.

იმ დროს ექსპლოიტის გზა არ იყო ცნობილი.

შემდეგ შესწორება შეფერხდა. კონკურენტ პატჩებს თითოეულს თავისი ფასი ჰქონდა: თავსებადობის გატეხვა, ახალი სერვისის უარყოფის კუთხეები ან ბევრი მესამე მხარის გაფართოების შეხება.

Foundation-ის საკუთარი სიტყვები გულწრფელად პირდაპირია: დაგვიანება იყო „სტრუქტურული წარუმატებლობა, რომელიც გამოიწვია როგორც უსაფრთხოების გუნდის გადაწყვეტილების პროცესმა, ასევე რესურსების ნაკლებობამ“.

შემდეგ 2026 წლის აგვისტოში ხარვეზი ხელახლა შეატყობინეს, მუშა უპირობო RCE-ით. CVE ID-ები გამოშვებამდე ონლაინ გაჟონა. ემბარგო მეორედ გატყდა, როცა ერთმა მწარმოებელმა უკვე შესწორებული სურათები გამოაქვეყნა.

მე ეს საოცრად დამამშვიდებლად და ღრმად გამაბრაზებლად მიმაჩნია ერთდროულად.

დამამშვიდებელია, რადგან ღია კოდის პროექტმა ეს წინადადება საკუთარ თავზე საჯაროდ დაწერა და თავის პროცესს ცვლის: უმრავლესობის გადაწყვეტილებები, ეკოსისტემის უსაფრთხოების გუნდი, მეტი პერსონალი.

გამაბრაზებელია, რადგან „ყველა, ვინც კრიტიკულ ინფრასტრუქტურას ამუშავებს, რესურსებით ნაკლებია“ ახალი გაკვეთილი არ არის, და PHP ვების დიდ ნაწილს ზურგზე ატარებს.

AI-ის კუთხე და სად გავაპროტესტებდი

ამ გამოშვების გარშემო ბევრი კომენტარი ერთ რამეზე მიუთითებს: AI ცვლის იმას, ვინ შეუძლია ამის ექსპლუატაცია.

არგუმენტი ასეთია. ფაქიზი მეხსიერების კორუფციის ხარვეზის სამუშაო შეტევად გადაქცევას ადრე იშვიათი უნარები სჭირდებოდა. ახლა ვილაცას ლეპტოპით და ღია წონების მოდელით შეუძლია აგენტი ინტერნეტზე გაუშვას, მიაწოდოს რეკომენდაცია და უთხრას „იპოვე ის, რომლებიც ჯერ კიდევ დაუცველია“.

ვფიქრობ, მიმართულება სწორია, დეტალები კი გაზვიადებულია.

რაც სწორია: რეკომენდაციიდან მცდელობამდე გადასვლის ღირებულება სწრაფად ეცემა. თავად პატჩი დიფია. დიფი მოდელს ზუსტად ეუბნება, სად შეხედოს. და სკანირება იაფია, როცა სკანერი არ იღლება.

რაც გაზვიადებულია: ამ ხარვეზის რთული ნაწილი სამიზნეების პოვნა არ არის, არამედ ექსპლოიტის სანდოობაა. Rapid7 ამბობს, რომ საჯარო PoC-ები მყიფეა. მეხსიერების კორუფცია ხელოსნობაა, და მოდელები ჯერ კი არ არიან ჯადოსნური იმაში, რომ თქვენი კონკრეტული დისტრიბუციისთვის heap განლაგება შექმნან.

და არის ისტორიის მხარე, რომელსაც ნაკლები ყურადღება ექცევა: დამცველებს იგივე ინსტრუმენტები აქვთ.

Foundation ამბობს, რომ უსაფრთხოების სამუშაოს ნაწილად იყენებს AI-ზე დაფუძნებულ სკანირებას და ვალიდაციას, იმ ფრაზით, რომ „ყოველ გადაწყვეტილებას პირი იღებს და ყოველ პატჩზე მუშაობს ადამიანი“.

ამიტომ რეალისტური შეჯამება არ არის „თავდამსხმელებმა სუპერძალა მიიღეს“. ის ასეთია:

ფანჯარა „პატჩი გამოქვეყნდა“ და „ვიღაც თქვენს სერვერზე მას ცდილობს“ შორის მცირდება.

თქვენი პატჩის სიჩქარე ახლა უსაფრთხოების კონტროლია, და არა IT-ის რუტინული საქმე.

რა გავაკეთოთ

ჯერ მოსაწყენი პასუხი: განაახლეთ.

შესწორებული ვერსიებია PHP 8.5.12, 8.4.27, 8.3.36 და 8.2.35.

თუ 8.1 ან უფრო ძველი გაქვთ, რეგულარული ზემოდან გამოშვებები აღარ არსებობს. Rapid7 აღნიშნავს, რომ 7.4, 8.0 და 8.1-ისთვის ზოგი შეზღუდული წყაროს backport არსებობს, ამიტომ დაეყრდნოთ თქვენს დისტრიბუციას ან LTS მომწოდებელს, ან საბოლოოდ გააკეთეთ განახლება, რომელსაც 2022 წლიდან აგვიანებთ.

ორი ხაფანგი, რომელშიც ხალხი ჩავარდება:

დისკზე პატჩირებული პაკეტი არ ნიშნავს მეხსიერებაში პატჩირებულ პროცესს. გაშვებული სამუშაო პროცესები ძველ კოდს ინახავენ, სანამ არ გადაიტვირთებიან. Qualys ამას კონკრეტულად აღნიშნავს, ამიტომ განახლების შემდეგ გადატვირთეთ ან სათანადოდ გადატვირთეთ თქვენი PHP სერვისები.

კონტეინერები მოძველებული ბაზური image-ებისგან არ გიცავთ. თუ თქვენი image გასულ კვირას აშენდა, ის ჯერ კიდევ გასულ კვირის PHP-ს ატარებს.

სწრაფი შემოწმება:

php -v                       # compare against 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35

# then make sure the running workers are the new ones
sudo systemctl reload php8.3-fpm     # or: apachectl graceful

თუ ახლავე ვერ პატჩავთ, მოწყობილობების ანგარიში ჩამოთვლის დროებით შემარბილებელ ზომებს. ისინი ამცირებენ ზემოქმედებას, მაგრამ არ ასწორებენ:

; php.ini or FPM pool config, NOT ini_set() or .user.ini (too late for these)
session.upload_progress.enabled = 0   ; closes the known session path
fatal_error_backtraces = 0            ; PHP 8.5 only
post_max_size = 8M                    ; and cap multipart size at the frontend too

ასევე ნახავთ შემოთავაზებას memory_limit=-1-ზე, და აქ უნდა აღვიარო, რომ Roll Safe მემი რეალურ სამუშაოს ასრულებს:

ის რეალურად ჩანს საკონსულტაციო ცნობებში, ადმინისტრაციულად დაყენებული, რომ აპლიკაციებმა ვერ გადალახონ. მაგრამ Rapid7 მკაფიოა: მეხსიერების გამოყოფის შეცდომამ მაინც შეიძლება მიაღწიოს დაუცველ გზას, ასე რომ ის ფანჯარას ამცირებს, მაგრამ არ ხურავს.

ასევე, სერვერს მეხსიერების ლიმიტის გარეშე თავისი ხასიათი აქვს. მას ჰქვია „გათიშვა“.

და ორი რამ, რასაც არ უნდა სწვდეთ. Rapid7 აფრთხილებს, რომ RLIMIT_AS და RLIMIT_DATA თავად შეიძლება გამოიწვიონ დაუცველი მეხსიერების გამოყოფის შეცდომის გზა, ხოლო კონტეინერის ან cgroup-ის მეხსიერების ლიმიტები არასრული პასუხია და მთელი სამუშაო პროცესების აუზი შეიძლება მოკლას.

და არ დამალოთ მტკიცებულებებიც. შეცდომების ჩუმად დაყენება display_errors-ით ან @-ით არ ხელს უშლის მოძველებული მდგომარეობის წაკითხვას, და ჩუმი ლოგი არ არის დასტური, რომ ყველაფერი რიგზეა.

და ეს მთელი გადაწყვეტილება ნაკადის დიაგრამად, იმ ადამიანისთვის, ვისაც პატჩის ფანჯარა და მენეჯერი ჰყავს:

flowchart TD
    A([Do you run PHP on a web server?]):::start --> B{Is it on 8.2.35, 8.3.36,<br/>8.4.27 or 8.5.12 or newer?}:::decision
    B -- yes --> C{Did you restart or reload<br/>workers after upgrading?}:::decision
    C -- yes --> D([You are patched. Go touch grass.]):::good
    C -- no --> E[Restart workers now]:::action
    B -- no --> F{Is it 8.1 or older?}:::decision
    F -- yes --> G[Distro or LTS backport,<br/>or plan the upgrade]:::action
    F -- no --> H[Upgrade to a fixed release]:::action
    G --> I[Apply interim mitigations<br/>until it lands]:::warn
    H --> E

    classDef decision fill:#f4d35e,stroke:#b8991f,color:#1a1a1a
    classDef start fill:#e9ecef,stroke:#6c757d,color:#1a1a1a
    classDef good fill:#5ee6c8,stroke:#1f9c86,color:#1a1a1a
    classDef action fill:#6ea8ff,stroke:#3a6fcc,color:#1a1a1a
    classDef warn fill:#ff9a5c,stroke:#cc6a2a,color:#1a1a1a

რა უნდა წაიღოთ თან

პატჩი არის გადაუდებელი გაკვეთილი. მუდმივი კი უფრო ჩუმია.

თქვენი უსაფრთხოების პოზიცია მოიცავს ფენებს, რომლებიც თქვენ არ დაგიწერიათ და არასდროს წაგიკითხავთ.

თქვენი კოდი შეიძლება იდეალური იყოს, და მის ქვეშ მყოფი გარემო მაინც გამოუშვებდეს ხარვეზს, რომელიც ორი წლის წინ პირველად შეამჩნიეს.

ეს არ არის PHP-ზე კონკრეტულად პანიკის მიზეზი. ყველა გარემოს აქვს შეცდომის გზები, რომლებსაც არავინ უყვარს, და მომავალი მსგავსი ხარვეზი სხვა გარემოში იქნება.

ეს არის მიზეზი, რომ გარემოს და ბაზური image-ების განახლება პირველი კლასის სამუშაოდ მოეკიდოთ, იცოდეთ რომელი ვერსია რეალურად მუშაობს წარმოებაში და შეინარჩუნოთ უფსკრული „შეტყობინებასა“ და „განლაგებას“ შორის რაც შეიძლება მცირე.

დამლაგებელი კოდი, როგორც გამოდის, ისიც კოდია.

ალბათ ყველაზე მეტად ღირს გადახედვა.

თქვენი გუნდის ყურადღება შეზღუდულია, და AI-ით გენერირებული კოდის ნაკადი ართულებს წარმოების უსაფრთხოებისა და საიმედოობის შენარჩუნებას შენელების გარეშე.

მე ვქმნი LiveReview-ს, AI კოდის რევიუს, რომელიც გავლენის რადიუსს ითვალისწინებს და შექმნილია თქვენი ბიზნესისთვის კრიტიკული სისტემებისთვის.

ყველა დიფის ერთნაირად გამოტანის ნაცვლად, LiveReview თითოეულ ცვლილებას აფასებს გავლენის რადიუსით — იმით, თუ რამდენად შორს აღწევს მისი გავლენა თქვენს call graph-ში — რათა ყურადღება იქ მიმართოთ, სადაც ეს მართლა მნიშვნელოვანია.

კოდის რევიუს ძალისხმევა დახარჯეთ იქ, სადაც ბიზნესის რისკი ყველაზე მაღალია — და არა თანაბრად ყველა დიფზე.

⭐ მოგვცით ვარსკვლავი GitHub-ზე:

HexmosTech / LiveReview

Risk-Aware AI Code Review for Business-Critical Systems

LiveReview შექმნილია ინჟინერი გუნდებისთვის, რომლებიც ხშირად აგზავნიან ცვლილებებს, მაგრამ ასევე ზრუნავენ წარმოების სტაბილურობაზე მომხმარებლებისთვის. ის ავტომატურად ამტკიცებს დაახლოებით 40-50% დაბალი რისკის ცვლილებებს და თქვენს გუნდს აძლევს ინსტრუმენტებს დანარჩენის დასამუშავებლად:

Auto-Approve: უსაფრთხო 50% ადამიანის გარეშე

ავტომატურად დაამტკიცეთ Pull Request-ების 50%-მდე, უსაფრთხოდ. რისკის შეფასება წყვეტს, რომელი MR/PR არის საკმარისად უსაფრთხო ადამიანის გარეშე გასაშვებად, ისე რომ თქვენი გუნდი რევიუს დროს მხოლოდ რისკიან და კრიტიკულ ცვლილებებს უთმობს.

LiveReview ავტომატურად ამტკიცებს დაბალი რისკის ცვლილებას, სანამ…

დააჭირეთ ქვემოთ, რომ LiveReview თქვენს კოდბაზაზე სცადოთ: