Krytyczny update PHP

[kankan]

"Upcoming Critical PHP Security Release"

https://www.php.net/archive/2026.php#2026-10-20-1

 

"ciekawie" się zapowiada...

[Gryzli]

Wersje PHP, dla których wydano już poprawki:

• PHP 8.2 → 8.2.35

• PHP 8.3 → 8.3.36

• PHP 8.4 → 8.4.27

• PHP 8.5 → 8.5.12

Starsze wersje, takie jak PHP 7.x i 8.1, nie otrzymują już oficjalnych aktualizacji od twórców PHP. W ich przypadku należy sprawdzić dostępność poprawek u dostawcy hostingu lub przejść na wspieraną wersję.

[theqkash]

Błąd jest w multipart w php więc w teorii wystarczy zablokować, o ile nie używane. Ale może lepiej o tym nie wspominać, bo muzea PHP powinny być generalnie likwidowane. 

[yLuno]

To jest chyba PHPokalipsa

[Tom X]

54 minuty temu, theqkash napisał(a):

bo muzea PHP powinny być generalnie likwidowane. 

Ale jak to zrobić nie likwidując klientów?

[l3szcz]

4 minuty temu, Tom X napisał(a):

Ale jak to zrobić nie likwidując klientów?

Przepisując Wordpressa na Django  

[theqkash]

7 minut temu, Tom X napisał(a):

Ale jak to zrobić nie likwidując klientów?

 

Wskazać klientom link do https://cert.europa.eu/publications/security-advisories/2026-018 gdzie jest wskazane jakie wersje PHP są objęte aktualizacją, a pozostałe że są niebezpieczne i na tej podsatwie wyłączyć stare wersje.

 

[Tom X]

@theqkash Logiczne z punktu widzenia admina. Właściciel/Prezes może posługiwać się nieco inną logiką: "Tak proszę pana, oczywiście proszę pana, PHP 7 może być i PHP 5 proszę pana  też się znajdzie"   

[l3szcz]

Jakby wam to powiedzieć:

 

PHP 8.5.12 - dalej podatne.

Edytowane Środa o 20:18 przez l3szcz

[kafi]

Cytat

 dalej podatne

Pytanie tylko... na co. 

 

Bo jakby to powiedzieć, zamiast przeklejać screen warto dobrać się najpierw do oryginalnej wypowiedzi,

w tym przypadku https://fedi.katze.sh/@elise/117479383739450605

w której po edycji sama autorka napisała

Cytat

edit: as it appears there is confusion, this is about the vuln I found, not the ones that got patched today

 

[Espen]

2 godziny temu, Tom X napisał(a):

3 godziny temu, theqkash napisał(a):

bo muzea PHP powinny być generalnie likwidowane. 

Ale jak to zrobić nie likwidując klientów?

Hmm, wdrażając płatności za obsługę naprawdę mocno archeologicznych wersji PHP?  .N i inne szlak przetarły, da się  

[darekm]

9 minut temu, Espen napisał(a):

Hmm, wdrażając płatności za obsługę naprawdę mocno archeologicznych wersji PHP?  .N i inne szlak przetarły, da się  

I zapłaca za to ludzie bo rachunki czytają księgowi i nie mają pojęcia za co płacą i dalej będzie stary php i baza

[Juvenito]

A jak oceniacie reakcje hostingów? Może info od firm? 
MyDevil zablokował wczoraj multipart/form-data. Klienci niezadowoleni, frustracja na ich mediach społecznościowych   

[Mion]

Ciekawe, czy te podatności wykryto białkowo, czy za pomocą Ej/Aj - 

[Juvenito]

Gdzieś czytałem, że z pomocą OpenAI 5,6 Sol i Gemini 4 Argon 

[home_pl]

Żyjemy w ciekawych czasach w kwestii cybersecurity  Tak czy inaczej - ostatnie godziny spędziliśmy na wytężonej pracy. 

https://pomoc.home.pl/komunikaty/komunikaty-home-pl/aktualizacja-zabezpieczen-php-w-home-pl-zakonczona

[Tom X]

@Espen Segment biznesowy/instytucjonalny jest dość odporny na argumenty finansowe. Może kwota 1000,- PLN netto/rok uruchamiałaby pewne procesy, ale mogłaby również uruchomić procesy niepożądane dla hostingodawcy.  

[yLuno]

No to chyba jak na razie największa dziura w tym roku jak nie 10cio latce - taka niezła bomba atomowa. Skala i zasięg to aż sobie trudno wyobrazić ale wcale bym się nie zdziwił jak znowu pociekną gdzie dane.
Ogólnie ten tydzień to masakra jakaś
PHP
Fortinet
eMudhra i 60mln certów podpisana "bardziewnymi" kluczami
a to nie wszystko 

 

[kankan]

4 godziny temu, Juvenito napisał(a):

A jak oceniacie reakcje hostingów? Może info od firm? 
MyDevil zablokował wczoraj multipart/form-data. Klienci niezadowoleni, frustracja na ich mediach społecznościowych   

niektóre hostingi w niemczech czy holandii po prostu wyłączyły wszystko na parę godzin, więc formularze nie są takie złe

 

3 godziny temu, Juvenito napisał(a):

Gdzieś czytałem, że z pomocą OpenAI 5,6 Sol i Gemini 4 Argon 

sam błąd był znany php od 2024 roku ale to po prostu olali: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ 

 

"Combined with the lack of a known path to remote code execution and the small team of core developers with the necessary deep knowledge of the engine occupied with many responsibilities, this decision process caused work on a fix to stall and restart repeatedly over months. We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."

[darekm]

1 minutę temu, kankan napisał(a):

niektóre hostingi w niemczech czy holandii po prostu wyłączyły wszystko na parę godzin, więc formularze nie są takie złe

 

sam błąd był znany php od 2024 roku ale to po prostu olali: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ 

 

"Combined with the lack of a known path to remote code execution and the small team of core developers with the necessary deep knowledge of the engine occupied with many responsibilities, this decision process caused work on a fix to stall and restart repeatedly over months. We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."

2004  

https://calif.io/php2shell/?fbclid=IwY2xjawVGxtFleHRuA2FlbQIxMQBwZG9mBXNydGMGYXBwX2lkEDIyMjAzOTE3ODgyMDA4OTIAAR6Zd82Kx2dnsHDSQE9dsibuT-zMZWfv3jKJUeF9ZMZQk0jm81YuU5pmBij2dA_aem_8jIxThWxyxHTFNloR8FPCA

 

[kankan]

w 2004 bug dostał się do kodu, ale od 2024 php było tego świadome

[Tom X]

Internetowe strony firmowe zazwyczaj nie są przesadnie często aktualizowane, zazwyczaj też nie są dynamiczne. Czy w takim przypadku wygenerowanie statycznego kodu HTML całego serwisu w oparciu o wordpressową wtyczkę WP Super Cache (tryb Expert) można uznać za pewną formę uniezależnienia się od podobnych sytuacji na przyszłość? 

[yLuno]

49 minut temu, Tom X napisał(a):

Internetowe strony firmowe zazwyczaj nie są przesadnie często aktualizowane, zazwyczaj też nie są dynamiczne. Czy w takim przypadku wygenerowanie statycznego kodu HTML całego serwisu w oparciu o wordpressową wtyczkę WP Super Cache (tryb Expert) można uznać za pewną formę uniezależnienia się od podobnych sytuacji na przyszłość? 

Jeżeli dałoby się zrobić sam HTML w 100% to tak, ten atak by nie zadziałał. Można też przy prostych stronach firmowych, informacyjnych etc. pobawić się w WordPress headless. 

[l3szcz]

Ale headless nie musi się czasem odwoływać do API?

[yLuno]

40 minut temu, l3szcz napisał(a):

Ale headless nie musi się czasem odwoływać do API?

No musi ale tylko przy "build" i można to robić na jednym serwerze więc localhost w zupełności wystarczy, no na różnych też to sobie można zabezpieczyć na kilka sposobów. Testowałem sobie ostatnio właśnie WP z Astro i drugą opcję po nowemu czyli sanity.io (to chyba już klasyczny SAAS)  i też Astro do budowania. Działa a czysty HTML to wiadomo, szybki jak błyskawica