Профиль: Аноним (вход | регистрация)
OpenNET

[ новости /+++ | форум | теги |    ]

форумы
правила/FAQ
поиск
регистрация
вход/выход
слежка
RSS


"Уязвимость в PHP, потенциально позволяющая скомпрометировать любой PHP-сайт"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимость в PHP, потенциально позволяющая скомпрометировать любой PHP-сайт"  +/–
Сообщение от opennews (?), 21-Окт-26, 09:11 
Разработчики PHP анонсировали публикации сегодня в 17:00 (MSK) экстренных корректирующих выпусков (8.5.12, 8.4.27, 8.3.36 и 8.2.35), в которых будут устранены две критические уязвимости. Всем администраторам серверов с PHP рекомендовано незамедлительно установить исправления на своих системах, сразу после их публикации. Официально детали будут раскрыты только после появления исправлений, но судя по появившейся в открытом доступе информации, речь про уязвимости CVE-2026-109618 и CVE-2026-109619, потенциально позволяющие удалённо выполнить свой код на любом web-сервере, выполняющем PHP-скрипты в конфигурации по умолчанию. Проблемы проявляются во всех версиях, начиная с PHP 5.4...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66516

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +3 +/–
Сообщение от Анониматор (?), 21-Окт-26, 09:11 
Непонятно, это только у тех у кого функционал загрузки файлов есть, или вообще на просто хелловроте тоже сработает эксплойт?
Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +10 +/–
Сообщение от Ятыаноним (?), 21-Окт-26, 09:15 
ну в новости прямо пишут что ой "Наличие на сайте функциональности для загрузки файлов для совершения атаки не требуется"
Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (17), 21-Окт-26, 10:02 
а сработает ли если в настройках нгинкса разрешен только GET. По идее ничто не мешает сформировать get-запрос с телом и multipart-data, и насколько тупым или умным окажется php в этом случае?
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (17), 21-Окт-26, 10:11 
эксплоит по ссылке 1 делает POST, второй не смотрел
Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –7 +/–
Сообщение от Ilya Indigo (ok), 21-Окт-26, 12:43 
У GET запроса нет и не может быть тела!
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

66. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +5 +/–
Сообщение от Аноним (17), 21-Окт-26, 13:37 
зайди в postman и сделай, кто тебе запретил?
Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (89), 21-Окт-26, 15:14 
прочитай для начала спеки.
Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

101. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Ан0нимус (?), 21-Окт-26, 16:04 
ну по спекам нельзя. и что?

в реальности работает.

Ответить | Правка | Наверх | Cообщить модератору

144. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от Аноним (89), 21-Окт-26, 19:05 
> по спекам нельзя

Может, ты сможешь показать то место в спеках, где это "нельзя"?

Ответить | Правка | Наверх | Cообщить модератору

148. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (89), 21-Окт-26, 19:41 
P.S.

A server SHOULD read and forward a message-body on any request;

Ответить | Правка | Наверх | Cообщить модератору

145. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +4 +/–
Сообщение от Аноним (89), 21-Окт-26, 19:24 
Я даже подскажу тебе: RFC 2616

Request = Request-Line ... CRLF [ message-body ]

Request-Line = Method SP ...

Method = "OPTIONS" | "GET" | "HEAD" | "POST" ...

Видишь, по синтаксису все методы касательно тела равноправны.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

174. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от Ilya Indigo (ok), 22-Окт-26, 07:25 
> прочитай для начала спеки.

Признаю, был НЕ прав!
Я в шоке со спецификаций HTTP, не желательно, но можно (запрета как такового нет)!.

curl -X GET "https://test" -F "file=@/tmp/test.txt" -F "username=johndoe" -v

Даже 400 нет, 200 как не в чём не бывало...

$_SERVER['CONTENT_LENGTH'] = 319
$_SERVER['CONTENT_TYPE'] = multipart/form-data; boundary=------------------------OkHDQEbTsl02pRyCq8CBSk
$_SERVER['REQUEST_METHOD'] = GET

Я в шоке!

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

176. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Ilya Indigo (ok), 22-Окт-26, 08:04 
curl -X GET "https://test" -F "file=@/tmp/test.txt" -F "username=johndoe" -v

$_SERVER['CONTENT_LENGTH'] = 319
$_SERVER['CONTENT_TYPE'] = multipart/form-data; boundary=------------------------OkHDQEbTsl02pRyCq8CBSk
$_SERVER['REQUEST_METHOD'] = GET

Теоретически, сработает.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

184. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (17), 22-Окт-26, 17:07 
жесть, теперь понятно почему закрылись сайты со статическим контентом
Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –8 +/–
Сообщение от жавамэн (?), 21-Окт-26, 09:27 
Это очередная уязвимость в вакууме, практическая реализация которой невозможна. Что-то типа отсутствия проверки на возврат printf.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

13. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Colorado_House_of_Representatives (?), 21-Окт-26, 09:47 
Как раз наоборот. Практическая реализация 100%. Новость перечитайте.
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от Боевой Петух (?), 21-Окт-26, 10:05 
> Практическая реализация 100%

В тепличных специально созданных условиях.

Ответить | Правка | Наверх | Cообщить модератору

81. Скрыто модератором  +2 +/–
Сообщение от Аноним (81), 21-Окт-26, 14:56 
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Боевой Петух (?), 21-Окт-26, 10:13 
Так и есть. Иначе где повальнве взломы всего и вся. В тайне такие сурьезные дыры не удержать, и в даркнете инфа бы 100500 раз успела разлететься.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

113. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (113), 21-Окт-26, 17:24 
Практическая реализация это загрузка файла на любой сайт на PHP где есть загрузка файла! Как будто в 2000-е вернулся.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

65. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Мохнонос (?), 21-Окт-26, 13:30 
Мужики! Как в lighttpd зарубить multipart загрузки?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

67. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +3 +/–
Сообщение от kuroneko (?), 21-Окт-26, 13:50 
Вот так https://ma.ttias.be/php-cve-2026-109618-early-mitigation/#li...
Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от FSA (ok), 21-Окт-26, 15:08 
> Мужики! Как в lighttpd зарубить multipart загрузки?

Во ты кремень! Я не вытерпел и перешёл на nginx много лет назад. Я не видел в lighttpd чего-то такого, ради чего стоило его использовать. Кстати, а для чего он в 2026 году нужен?

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

92. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Гость (??), 21-Окт-26, 15:27 
своеобразный формат конфига, некоторое позволяет сделать легко и красиво, на чём-нибудь не нагруженном и не требующем новейшие протоколы, вполне можно держать
Ответить | Правка | Наверх | Cообщить модератору

115. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –2 +/–
Сообщение от Аноним (115), 21-Окт-26, 17:27 
Запрос в Claude Code: "как в lighttpd заблокировать Content-Type multipart"
Ответ ИИ:
Вариант 1: запрет через mod_access, ответ 403
server.modules += ( "mod_access" )
$REQUEST_HEADER["Content-Type"] =~ "(?i)^\s*multipart/" {
    url.access-deny = ( "" )
}
Вариант 2: ответ 415 через mod_magnet (Lua)
server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/etc/lighttpd/deny-multipart.lua" )
-- /etc/lighttpd/deny-multipart.lua
local r = lighty.r
local ct = r.req_header["Content-Type"]
if ct and ct:lower():match("^%s*multipart/") then
  return 415
end
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

123. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (115), 21-Окт-26, 18:02 
Проверено NextCloud на lighttpd с заблокированным Multipart/Form-Data нормально РАБОТАЕТ

$REQUEST_HEADER["Content-Type"] =~ "(?i)^\s*multipart/form-data" {
    url.access-deny = ( "" )
}

Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –28 +/–
Сообщение от Аноним (3), 21-Окт-26, 09:22 
Будет ли это последним гвоздем в гробы ПыХи?
Он и так уже мало где используется, а если попрут взломы...
Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +6 +/–
Сообщение от Аноним (5), 21-Окт-26, 09:25 
70% web-сайтов это "мало где используется"?
WorldPress остаётся самой популярной CMS.
Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (5), 21-Окт-26, 09:26 
в догонку статистика https://w3techs.com/technologies/overview/programming_language
Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +3 +/–
Сообщение от жавамэн (?), 21-Окт-26, 09:32 
ПХП это далеко не только WordPress.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

118. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (118), 21-Окт-26, 17:31 
Тысячи форумов на phpBB
Ответить | Правка | Наверх | Cообщить модератору

189. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от _ (??), 23-Окт-26, 20:21 
> ПХП это далеко не только WordPress.

А песец! это делеко не только мех! ;-DDDDDD

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

90. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (89), 21-Окт-26, 15:16 
Пора возвращаться на перл. Там таких проблем, как у php, нету.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

188. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (188), 23-Окт-26, 09:46 
Просто плохо искали
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (17), 21-Окт-26, 09:58 
вся мелкая торгашня до повального переезда на Озон на Битриксе сидели, наверно по инерции так и сидят
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

42. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 11:51 
> вся мелкая торгашня до повального переезда на Озон на Битриксе сидели, наверно по инерции так и сидят

С этого давно протухшего продукта крайне сложно слезать. Видел уже статьи на Хабре о том, как к нему незаметно пристраивают нормальный фреймворк, отвечающий за реальную работу, и оставляют Битрикс только как фасад. Но это штучное решение.

На Озоне, кстати, тоже намазано отнюдь не медом. Свой магазин, если он сколько-нибудь жив, Озон не отменяет.

Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +8 +/–
Сообщение от Жироватт (ok), 21-Окт-26, 10:06 
Хоронили Пых, порвали два состава составов баянов, но мертвец, вопреки прогнозам анонимных и не очень Отстрадамусов, жив, доволен собой и жизнью и помирать не собирается.
Если язык хочет жить и его активно пользуют, то медицина тут бессильна.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

4. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +9 +/–
Сообщение от Дони (?), 21-Окт-26, 09:23 
А могли бы сидеть на PHP 4, после которого язык превратился в bloated помойку, и уже сложнее java.
Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Tron is Whistling (?), 21-Окт-26, 09:38 
Ну как-то да, последней вменяемой версией были 8.0/8.1, где нужные и важные JIT и Fiber добавили. А дальше понёсся какой-то полусахар для совсем уж обезьянок.
Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 09:53 
При написании на примитиве вроде РНР 4 хоть сколько-нибудь сложной системы неизбежно получится копролит типа Битрикса.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –6 +/–
Сообщение от Боевой Петух (?), 21-Окт-26, 10:08 
Битрикс отличная система, насколько я помню, в отличие от современнвх оверинжиниред монстров.
Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +4 +/–
Сообщение от фывыфв (?), 21-Окт-26, 13:03 
> Битрикс отличная система

Имел опыт работы. На столько хватило этого, что уволился из конторы, которая при мне стала официальным дистрибьютором, с неплохой зп кстати.
Долго отмывался потом. Все еще помню привкус Битрикса.

Ответить | Правка | Наверх | Cообщить модератору

108. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Bitrix.dev (?), 21-Окт-26, 17:08 
Битрикс -- это отличная от нормальных система. Со знанием дела пишу.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

16. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –2 +/–
Сообщение от Аноним (16), 21-Окт-26, 09:59 
Это там, где magic quotes и прочие радости жизни? Лол.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

102. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Ан0нимус (?), 21-Окт-26, 16:05 
magic quotes вроде в php3 отменили. или уже в php4?
Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (16), 21-Окт-26, 16:24 
Суть такова:

> This feature was officially deprecated as of PHP 5.3.0 and removed in PHP 5.4, due to security concerns.

Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Боевой Петух (?), 21-Окт-26, 10:07 
Согласен. 4 пыха первая и последня +/- адекватная версия, далее они свернули куда-то не туда.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

59. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +3 +/–
Сообщение от фывыфв (?), 21-Окт-26, 13:06 
Интересно, все кто нахваливает PHP4, хоть раз в жизни создавали какой-то продукт на PHP более менее пользующийся спросом?

Я да, причем писал на PHP4 до выхода PHP5. PHP4 - это убожество. Веха PHP это версия 5.6.

Ответить | Правка | Наверх | Cообщить модератору

74. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Tron is Whistling (?), 21-Окт-26, 14:32 
Да, 5.6, и далее до 7.3 включительно ничего сильно не ломали.
В 7.4 что-то пошло не так, но не сильно. 8.0/8.1 - терпимо, за JIT можно потерпеть.
Но с 8.2 понеслась какая-то долбанина. И релиз цикл ещё сменился от стабильного к вечно рушащемуся блидингэджу.
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Pahanivo (ok), 21-Окт-26, 10:37 
Да фиг с ней с помойкой ... ломание совместимости при смене мажорной версии зачем?
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

49. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +4 +/–
Сообщение от пох. (?), 21-Окт-26, 12:26 
мажорной?! Да вы, голубчик, родиться просто опоздали.
Это протухт ровно тех же ребят что в 2005м на ровном месте сломали foreach - вот ровненько между 5.2.1 и 5.2.2

Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Tron is Whistling (?), 21-Окт-26, 14:45 
Это когда для итераторов сломали поведение курсора на next внутри foreach, чтобы не плодить два инстанса итераторов?

Так то, что они сломали - уже UB само по себе, в здравом уме нормальный человек такое писать не будет. Потому что реально UB.

Ответить | Правка | Наверх | Cообщить модератору

79. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от пох. (?), 21-Окт-26, 14:53 
ну это ж именно то чего все ждут от третьей цифирки после точки - херак, вы слушаете маяк, у вас половина сайтов не работает. Точнее интересным образом глючат, поэтому ты далеко не сразу сообразишь в чем проблема.

Ответить | Правка | Наверх | Cообщить модератору

160. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Pahanivo (ok), 21-Окт-26, 22:04 
> мажорной?! Да вы, голубчик, родиться просто опоздали.

дату рега глянь чтоле ...


Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

48. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (48), 21-Окт-26, 12:16 
Подскажите пожалуйста не-bloated альтернативу. Только без совсем васянских поделок, т.к. для них очень скоро перестанут выходить фиксы багов или они в будущем станут такими же bloated помойками. Мне реально интересно.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

22. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –3 +/–
Сообщение от Аноним (22), 21-Окт-26, 10:09 
Вот тебе и ИИ =(
Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +4 +/–
Сообщение от Аноним (17), 21-Окт-26, 10:38 
php 5.4 вышел в 2012 году, это кожаные внесли, ИИ невиноунен
Ответить | Правка | Наверх | Cообщить модератору

93. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Bottle (?), 21-Окт-26, 15:36 
ИИ наоборот благодарить надо, что эту уязвимость закрыли.
Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Боевой Петух (?), 21-Окт-26, 10:11 
Если бы это была реальная уязвимость, пол инторнета уже бы крякнули.
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +6 +/–
Сообщение от Rev (ok), 21-Окт-26, 12:08 
А почему вы думаете, что их не крякнули?
Ответить | Правка | Наверх | Cообщить модератору

191. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (191), 25-Окт-26, 01:21 
Да кому это нужно. Энергию тратить на эти сайтики новостные.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

26. "Уязвимость в PHP, потенциально позволяющая скомпрометировать любой PHP-сайт"  +/–
Сообщение от Аноним (26), 21-Окт-26, 10:17 
> …CVE-2026-109618 и CVE-2026-109619…

https://security-tracker.debian.org/tracker/CVE-2026-109618
https://security-tracker.debian.org/tracker/CVE-2026-109619

Обе ссылки выдают 404. Возможно, скрыты в связи с эмбарго (хоть и слитым). Там хоть было что–нибудь?

Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от Аноним (115), 21-Окт-26, 10:56 
>для предотвращения атаки без применения патча требуется полная блокировка запросов с типом контента "multipart/form-data", которая приведёт к невозможности загрузки файлов через web-формы.

Т.е. полная остановка функциональности NextCloud.

Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от Аноним2 (?), 21-Окт-26, 11:14 
70% интернета к твоим услугам.
Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (40), 21-Окт-26, 11:19 
а дак что оно делает-то ? сервак вешает или прямо выполнение кода любого ?
Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (43), 21-Окт-26, 11:54 
и вешает и если нужно выполняет любой код по желанию
Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +3 +/–
Сообщение от Аноним (41), 21-Окт-26, 11:47 
> (проблема решается перебором в эксплоите смещений, заранее вычисленных для пакетов из разных дистрибутивов).

Практическое закрытие прблемы решается установкой из исходников.

Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (51), 21-Окт-26, 12:36 
Вот это мне тоже интересно стало.

Ведь есть некий ASLR (Address Space Layout Randomization), который аккурат не позволит однозначно вычислять эти смещения. Насколько понимаю, этот режим во множестве дистров активирован.

Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Жертва (?), 21-Окт-26, 12:42 
Речь о смещениях, а не об абсолютных адресах.
Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –5 +/–
Сообщение от DEF (?), 21-Окт-26, 11:57 
Вовремя я сбежал с Wordpress + PHP на Astro + Node.js.
Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +6 +/–
Сообщение от Rev (ok), 21-Окт-26, 12:10 
Node.js - это тоже большая дыра.
Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 12:13 
Да любая маргинальщина менее подвержена атакам, просто по принципу Неуловимого Джо.
Тот же Битрикс гордо кукарекал, какой он неуязвимый... до 2022. А потом тема "Взломаны сайты в честь дня конституции украины" на офсайте набрала сотню страниц...
Впрочем, велосипедам на ноде этот вариант не грозит.
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

55. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от menangen (?), 21-Окт-26, 12:51 
75% гошников это бывшие пыхеры
С пыха разбежалось огромное количество нубов ещё в 2010-2020, щас тока матерые и непробивные кабаны ещё что-то там на поддержке тянут всякие поделия
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

58. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +6 +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 13:05 
Нубам вообще свойственно метаться, они в реальном проде никакой роли не играют.
Ответить | Правка | Наверх | Cообщить модератору

143. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (143), 21-Окт-26, 19:01 
Так любые, в том числе крутейшие, специалисты вырастают только и исключительно из нубов. И если нубы разбежались, то специалистов больше не будет, и в итоге инфра PHP придёт к тому же состоянию что и инфра Perl. Типа релизы вроде выходят по расписанию, и модулей тысячи для люых задач, но на деле в релизах кроме бампа версии ничего по сути нет, а модули никто не поддерживает.
Ответить | Правка | Наверх | Cообщить модератору

162. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 22:28 
Люди - разные. Чем больше нуб скачет по модным языкам и фреймворкам, тем меньше у него шансов стать специалистом. Хотя он, конечно, воображает себе обратное.
См. эффект Даннинга-Крюгера.
Ответить | Правка | Наверх | Cообщить модератору

175. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от фывыфв (?), 22-Окт-26, 07:32 
> Чем больше нуб скачет по модным языкам и фреймворкам, тем меньше у него шансов стать специалистом.

Языки и фруймворки, это инструменты. Специалисты тем и отличаются, что они умеют правильно подбирать инструмент и архитектуру для задачи.

Ответить | Правка | Наверх | Cообщить модератору

177. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от тоже Анонимemail (ok), 22-Окт-26, 08:52 
> Языки и фруймворки, это инструменты. Специалисты тем и отличаются, что они умеют правильно подбирать инструмент и архитектуру для задачи.

Специалисты знают, что задачи имеют много решений и довольно часто решаются на чем угодно без критичных различий. Опыт и глубина знаний важнее, чем конкретный стек.

Ответить | Правка | Наверх | Cообщить модератору

96. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Инопланетянин (?), 21-Окт-26, 15:45 
> Astro is a JavaScript web framework that renders components on the server and sends lightweight HTML to the browser.

Что-то на хипстерском. Можно слать "lightweight HTML" без всяких фреймоврков.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

129. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от черпало (?), 21-Окт-26, 18:24 
каждый раз, как ты гордо показываешь, врываясь в оюсуждение любой темы, смеюсь.

ты прям карикатурно-классический спесалист высокого уровня и шырокого профиля. Хуже не придумаешь.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

54. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –3 +/–
Сообщение от menangen (?), 21-Окт-26, 12:48 
Большинство пыхеров уже и не пыхеры вовсе - там огромное лобби вайтишников было, которые на вордпрессе тупо мышкой ставили плагины, чтобы накрутить из этого г инетрент магазин по продаже ковриков и запчастей. Потом пощемились на руби с рельсами, там был бум магазинов на рельсах и кофескрипте, затем выстрелила нода и гоу и щас уже даже не понятно, кому эта пыха интересна - новых статей по ней нет, новых фреймворков - нет, новых orm - тока всплывают дыры и вся экосистема превращается в легаси как и чистая java, плюс из php сами разрабы пытались сделать что-то невменяемое уже лет 10 как
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 13:06 
На заимствовании из тех же рельс выросла и окрепла Ларавель, например.
Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от фывыфв (?), 21-Окт-26, 13:20 
yii тоже от рельсов пошла
Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от фывыфв (?), 21-Окт-26, 13:22 
>  php сами разрабы пытались сделать что-то невменяемое уже лет 10 как

Такое чувство, что они пытались (или все еще пытаются) сделать альтернативу java, только интерпретируюмую и обратной совместимостью, обильно посыпанная тоннами сахара.

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

134. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Ivan_83 (ok), 21-Окт-26, 18:32 
Давайте заменим пыху на С в вашем опусе и попробуем понять что изменится :)

В том плане что тот же С не нуждается в каком то развитии, там и так всего нужного более чем достаточно для решения любых задач.
Так же мне не понятно чего вам от пыхи надо, чего не хватает то?

Я не пыхо пограмист, но вижу что тот же некстклауд, мантис и руторрент (с чем я имею дела) прекрасно работают и не испытывают проблем с функционалом или изображением современного вида гуя, при этом как администратор и меинтейнер я опять же не вижу проблем с поддержкой этого.
(хотя некстклауд как для админа мне не нравится - сложная поддержка).

И я вижу как трудно тянуть проекты на питоне.

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

163. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 22:39 
С-то тут при чем? Сишка - язык, назначение которого - низкоуровневое программирование, в котором изменения скорее вредны, и внешние условия меняются редко.

Пых - язык эпохи роста, от примитивных одностраничников до порталов, для которых грамотная и сложная архитектура - единственный шанс справиться со сложностью.
Благодаря тому, что язык реально развивался, менялся, активно заимствовал и стал мультипарадигменным - он до сих пор остается мейнстримом, и естественно, работать в мейнстриме легче, чем в маргинальщине.

Бред про то, что РНР после четверки (или пятерки, или другой любимой цифры) испортился - откровенный тролличий помет, с ним даже спорить нет смысла.
Такой убогий язык в современном вебе просто на хрен не нужен - те сайтики, что скрипели на нем, сейчас всякие конструкторы позволяют клепать на автомате вообще без программирования.

Ответить | Правка | Наверх | Cообщить модератору

165. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Ivan_83 (ok), 22-Окт-26, 00:11 
Мне как бы не нравится тема того что если в язык не наваливают тонны всякого то вот он типа мёртвый.
Или если не запиливают 10005000 никому ненужных либ/фрейморков то тоже язык никому не нужен.
Или если прога 10 лет не обновлялась - то с чего бы ей переставать работать? (речь про тех у кого нет зависимостей)

С, пхп, перл - те немногие языки где удаётся соблюдать баланс как в самом языке не наваливая туда много так и в проектах где зависимостей мало/они все внутри.

Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Анонимemail (56), 21-Окт-26, 12:56 
Да уходить надо с этого PHP на питоновские Django и FastAPI.
Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от фывыфв (?), 21-Окт-26, 13:09 
Смысл? В экосистеме php сейчас есть все инструменты для нормальной разработки. Окружение позволяет поднять достаточно шустрые сервисы. Лучше работающие даже чем Python.
Ответить | Правка | Наверх | Cообщить модератору

75. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Dmitry (??), 21-Окт-26, 14:33 
Ага, конечно. Пишу на JS бэк, спека OpenAPI (ендпоинты, query, типы тел запросов, типы ответов) генерится автоматически на моем роуте /openapi, для этого я подключил лишь один плагин. Как же я долго ругался со всеми PHP разработчиками - ни в какую. Они походу его в вручную пишут, потому что он автоматически из кода у них не обновляется. Как хороша PHP экосистема. WEB-язык это JS.
Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –3 +/–
Сообщение от Tron is Whistling (?), 21-Окт-26, 14:36 
Ехал API через API...
А потом удивляются, что зашедшие полтора клиента опять положили все госуслуги.
Ответить | Правка | Наверх | Cообщить модератору

94. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –2 +/–
Сообщение от фывыфв (?), 21-Окт-26, 15:41 
Вы описываете чисто человеческий фактор. Уверен для пыхи генерилок OpenAPI тоже хватает.
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

99. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Dmitry (??), 21-Окт-26, 16:01 
Нет. Люди всегда слиты с экосистемой на которой они пишут. Это как связка пространство-время.
Ответить | Правка | Наверх | Cообщить модератору

70. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от Аноним (143), 21-Окт-26, 14:18 
Зачем, когда можно на языки програмирования уходить? И забыть как страшный сон тормозные, ждущие память и забагованные динамические язычки.
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

71. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Анонимemail (71), 21-Окт-26, 14:28 
Например?
Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от но (?), 21-Окт-26, 15:55 
rust конечно же.
Ответить | Правка | Наверх | Cообщить модератору

168. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от menangen (?), 22-Окт-26, 01:16 
Да пусть и дальше пишет на сишке или крестах форумы и чаты на вебсокетах
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

69. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Аноним (143), 21-Окт-26, 14:17 
Вполне ожидаемо.
Ответить | Правка | Наверх | Cообщить модератору

72. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +3 +/–
Сообщение от Tron is Whistling (?), 21-Окт-26, 14:29 
#####################
--- a/ext/session/session.c     2015-09-01 22:09:37.000000000 +0200
+++ b/ext/session/session.c     2026-10-21 12:31:35.206373687 +0200
@@ -2272,3 +2272,4 @@
        php_session_rfc1867_orig_callback = php_rfc1867_callback;
-       php_rfc1867_callback = php_session_rfc1867_callback;
+//      temporary mitigation for php2shell
+//     php_rfc1867_callback = php_session_rfc1867_callback;

#####################

Это для затравки, кому надо. Да, убьёт upload progress - но незаметно для клиента. Да, не факт, что это единственное место, где оно уязвимо. Но пока полной информации нет, для старых версий в самый раз.

Ответить | Правка | Наверх | Cообщить модератору

119. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Tron is Whistling (?), 21-Окт-26, 17:32 
Не, этой хернёй не обойдёшься.
Там 3.14ц.
Патчите по-нормальному.
Ответить | Правка | Наверх | Cообщить модератору

169. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от menangen (?), 22-Окт-26, 01:18 
Будет угарно, когда после его патча будет падать сервис только во время попыток хакнуть его сервис
Ответить | Правка | Наверх | Cообщить модератору

182. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Tron is Whistling (?), 22-Окт-26, 14:21 
Угарнее мне сейчас это бэкпортировать на 5.2-7.3.
Хостинг, сэр.
Ответить | Правка | Наверх | Cообщить модератору

183. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Tron is Whistling (?), 22-Окт-26, 14:22 
И обезьянки не сделают к сожалению, тут анализ нужен.
Нет, накорябать-то накорябают, но без концепта не накорябают.
Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

80. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (80), 21-Окт-26, 14:55 
Комментаторам выше - на похапе поныне работают такие незначительные сайты, как Фейсбук, ВК (вероятно до сих пор), Википедия, Хвиттер и другие. Его разрабам работы хватит.
Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от пох. (?), 21-Окт-26, 15:03 
И сегодня к вечеру им всем - ПЦ!

"а вторая новость еще лучше!" (c) советский анекдот

Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от но (?), 21-Окт-26, 15:21 
Свитер изначально был на руби, потом на жаву вроде перешел.
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

95. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от фывыфв (?), 21-Окт-26, 15:43 
у  Фейсбук и ВК были свои компилируемые пыхи. Есть в открытом доступе.
ВК же вроде ушел от него, хз куда, наверное на go.
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

106. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (51), 21-Окт-26, 16:48 
Эти-то пофиксят. Вполне вероятно, что у них и не дистрибутивные сборки (а значит и правильные смещения в эксплойте просто так не удастстя подобрать)

Вот куча всякого старья в сети (в том числе и локалках), с вэбмордами возможно на похапэ - она никуда не денется. Никто их фиксить не будет, или фиксов нет, или никому дела до этого нет, или никто даже не подозревает что это и где у них там это. Раздолье что для ботнетов, что для скайнета.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

86. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (81), 21-Окт-26, 15:03 
Совершенно случайная случайность. Жиа Тан не уиноват.
Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (87), 21-Окт-26, 15:05 
Почините новость кто-нибудь? ссылка на pastbin похоже уже проломлена и постоянно требует проверить что ты не робот:)
Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –3 +/–
Сообщение от Аноним (97), 21-Окт-26, 15:50 
Гугл предлагает в главном конфиге Nginx добавить конструкцию, чтобы работало для всех сайтов

map $http_content_type $block_multipart {
        default       0;
        ~*multipart   1;
    }

Рабочая тема?

Ответить | Правка | Наверх | Cообщить модератору

100. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Аноним (100), 21-Окт-26, 16:04 
Если панель ISP, то предлагает создать файл
/etc/nginx/vhosts-includes/multipart_protection.conf

if ($http_content_type ~* "^multipart") {
    return 403;
}

Она добавляется во все конфиги в Server.

Сломается часть функционала, которая построена на этом механизме. Например у Б24 уже отвалился встроенный почтовый клиент.

Ответить | Правка | Наверх | Cообщить модератору

190. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от пох.. (?), 24-Окт-26, 15:51 
да тут все нахрен сломается кроме хеловротов. Включая кажись сам ispmanage...а, собственно, уже ж и поломали.


впрочем, иди0ты пользующие (пользуемые!) isp того и достойны.

Ответить | Правка | Наверх | Cообщить модератору

104. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (104), 21-Окт-26, 16:30 
Стоит PHP 8.2.20, session.upload_progress.enabled на off в php.ini поставил.

Нормально ли обновится минорная версия пыхи на устаревших дистрибутивах по типу CentOS 7 ? Пробовал кто-нибудь?

Ответить | Правка | Наверх | Cообщить модератору

166. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от shurshur (?), 22-Окт-26, 00:46 
8.2.20 намекает что это remi-php, именно до этой версии Реми собирал пакеты под el7.

Инструкция как собрать 8.2.35 по спекам Реми под el7: https://gist.github.com/shurshur/5610fc58cf2d9a162a948fa84f3...

Ответить | Правка | Наверх | Cообщить модератору

180. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (104), 22-Окт-26, 11:40 
Спасибо тебе, человек! Сэкономил кучу времени на восстановлении работы сервера. Инструкция там не совсем полная, возникли проблемы с некоторыми devel, пакетами и openssl , но с нейронкой справился.

Счастья и удачи тебе, хорошего дня!

Ответить | Правка | Наверх | Cообщить модератору

186. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от shurshur (?), 22-Окт-26, 20:45 
Ну это было вполне ожидаемо, я писал буквально на коленке, собирал на живом сервере без полноценного теста в чистой среде.

Потом ещё я по запросу трудящихся написал для 7.4 и вот её пара человек реально попробовали и там потому были некоторые улучшения по их фидбэку.

https://gist.github.com/shurshur/ae3b1f525a26e10692a688cc367...

А сегодня ещё один дополнения к инструкции для 8.2 написал, переделка под свои условия плюс некоторые замечания

https://gist.github.com/kremit/94ebd5aa3d29d22192167c3486cd2826

Ответить | Правка | Наверх | Cообщить модератору

105. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (105), 21-Окт-26, 16:45 
Похоже что у уязвимости три условия для эксплуатации:

1. session.upload_progress=1 - это значение по-умолчанию, надо конечно выключать
2. post_max_size должен быть больше чем memory_limit - это отнюдь не везде так, надо проверять
3. RCE возможен только на Apache, а на nginx + php-fpm - только DDoS.

Я же правильно понял по описанию?

Ответить | Правка | Наверх | Cообщить модератору

121. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (113), 21-Окт-26, 17:39 
1. Нет, это лишь убирает простую версию. Для того чтобы избавиться от уязвимости нужно отключать multipart.
2. Тоже необязательно. Работает и на стандартных настройках, где наоборот. Более того post_max_size не гарантирует предотвращение OOM.
3. Нет, не возможен, а "продемонстрирован".
Ответить | Правка | Наверх | Cообщить модератору

126. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (126), 21-Окт-26, 18:15 
> 3. RCE возможен только на Apache, а на nginx + php-fpm - только DDoS.

FPM exits the child when request startup fails. This prevents consumption of the invalid state and removes the child from the pool. After normal startup, OOM may still be reached in a context failing to account for an early exit, with the invalid state being processed during request shutdown. Source analysis therefore supports FPM as a susceptible, though no complete FPM exploit has been demonstrated for this SAPI.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

130. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Ivan_83 (ok), 21-Окт-26, 18:25 
Если вас так волнует тема безопасности - надо думать по другому, как Тео или как безопасник или как атакующий.
Вот это перебирание вас к успеху не приведёт.

Нужно изначально считать что оно с кучей дыр и бэкдоров и выставляя это в инет вы даёте возможность к этим бэкдорам обращатся.
Следующий шаг состоит в том чтобы бэкдорами стало не возможно пользоватся.

Кто то идёт покупает WAF и подписку - обычно те кому некогда. (и надеется что вендор успеет раньше чем какер с PoC)
Кто то молится на патчи. (до первых зиродеев)

Кто то огораживает процессы так средствами ОС что даже будучи полностью подконтрольны атакующему они ничего плохого сделать не смогут, максимум покоцать/упереть те данные к которым этим процессам дали доступ для работы.
В том же андройде ровно так и сделано.
И на линухе вам никто не мешает сажать это в виртуалку/chroot и/или огораживать всякими аппармор и прочими механизмами коих в линухе до кучи.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

107. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (107), 21-Окт-26, 17:03 
Сайт php не открывается. Заблочили чтобы никто не мог обновиться и хакеры могли бы поломать наши сайты?
Ответить | Правка | Наверх | Cообщить модератору

109. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Гость (??), 21-Окт-26, 17:20 
открывается, только временами медленно, все ломанулись туда, вот и не держит нагрузку
Ответить | Правка | Наверх | Cообщить модератору

110. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (51), 21-Окт-26, 17:21 
вот она - слава !
Ответить | Правка | Наверх | Cообщить модератору

111. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (107), 21-Окт-26, 17:22 
У меня провайдер блокирует вместе с пакагистом.
Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

112. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от и че тут написать надо то (?), 21-Окт-26, 17:23 
так там или неудачная харакири или удачная сэппуку. Но результат - схож.
Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

116. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Инопланетянин (?), 21-Окт-26, 17:28 
Когда то давно посмотрев на php.ini понял, что сам яп лютый вайбкод, еще до того как это стало мейнстримом. Буквально поведение можно менять. И предлагается такое выставлять наружу. Собственно время только подвтерждает это.
Ответить | Правка | Наверх | Cообщить модератору

128. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Ivan_83 (ok), 21-Окт-26, 18:18 
Нормальный Язык Программирования делает то что от него хочет пользователь, даже если это стреляние в ногу через ухо.
Это у фриков с растом всё наоборот и ЯП за них решает как им жить.
Ответить | Правка | Наверх | Cообщить модератору

142. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +2 +/–
Сообщение от Аноним (-), 21-Окт-26, 18:53 
> Нормальный Язык Программирования делает то что от него хочет пользователь

Лол, оказывается сишка всего лишь делает то, что от неё хотят ее пользователи - дырявый ненадежный софт.

> Это у фриков с растом всё наоборот и ЯП за них решает как им жить.

Перестань в каждой теме напоминать, что ты не осилил Раст. Это твои skill issues.

Ответить | Правка | Наверх | Cообщить модератору

170. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Ivan_83 (ok), 22-Окт-26, 01:22 
Чтобы не осилить нужно захотеть, а я не хотел с самого начала и сейчас не хочу.

А насчёт хотений пользователей - это везде так: редко бывают те кто знает чего хочет и как это сделать правильно.

Ответить | Правка | Наверх | Cообщить модератору

117. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (113), 21-Окт-26, 17:31 
https://openai.com/index/coordinated-disclosure-of-critical-.../

Опять пришлось убирать за кожаными!

Ответить | Правка | Наверх | Cообщить модератору

125. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 18:11 
Прилетело в Минт обновление: php8.3-common версии 8.3_8.3.6-0ubuntu0.24.04.13
Говорит, на сайте чейнджлог есть - https://changelogs.ubuntu.com/changelogs/pool/main/p/php8.3/...
Хрен тебе, а не чейнджлог, говорит сайт. HTTP 404.
Даже интересно, это он пока не хочет детали открывать или как.
Ответить | Правка | Наверх | Cообщить модератору

135. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (135), 21-Окт-26, 18:33 
ChangeLog есть в самих пакетах. Открой в Synaptic список файлов, должен быть что-то типа /usr/share/doc/php8.3-common/changelog.Debian.gz
Ответить | Правка | Наверх | Cообщить модератору

127. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Ivan_83 (ok), 21-Окт-26, 18:17 
Удачи в обе гачи, как говорится, с эксплуатацией :)

У меня оно как сидело в chroot где никакого shell нет так и дальше сидит.
Не говоря о том, что докувики и некстклауд не дают грузить файлы тем кто не авторизовался, а регистрация закрыта.

Ответить | Правка | Наверх | Cообщить модератору

131. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от тоже Анонимemail (ok), 21-Окт-26, 18:25 
> Не говоря о том, что докувики и некстклауд не дают грузить файлы

Их никто и не спрашивает. Читайте внимательнее.

Ответить | Правка | Наверх | Cообщить модератору

138. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –2 +/–
Сообщение от Ivan_83 (ok), 21-Окт-26, 18:39 
Да ладно, тратить ещё на это время :)
Я его потратил на то, чтобы после удачной эксплутации атакующий получил ШИШ без масла :)
Ответить | Правка | Наверх | Cообщить модератору

133. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (133), 21-Окт-26, 18:27 
авторизация никак не защищает от уязвимости. сама уязвимость зарыта глубже.
Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

137. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (137), 21-Окт-26, 18:38 
Сидит в изоляции, но через него идут важные данные? Тебя оно не задевает, а твоих клиентов?
Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

140. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Ivan_83 (ok), 21-Окт-26, 18:45 
А ты для начала предложи способ рабочий что то сделать в окружении где почти ничего нельзя записать/выполнить и где ничего нет.

В данном случае я сам себе клиент и все влажные данные они мои.
В случае докувики - и так всё открыто, максимум что можно сделать - пакость уровня дефейса. И проживёт оно до момента когда я увижу и сделать восстановление с бэкапа через rsync или cp -f.
В случае некстклауда - там есть немного личных данных: жадный андройд не позволяет делать полноценные бэкапы никуда кроме как в облако анб. Так бы было больше.

Ответить | Правка | Наверх | Cообщить модератору

179. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от bublick (ok), 22-Окт-26, 10:01 
... и сервис выключен!
Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

136. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (137), 21-Окт-26, 18:37 
>Для успешной эксплуатации требуется определение раскладки структур в памяти процесса, которая специфична в каждой сборке (проблема решается перебором в эксплоите смещений, заранее вычисленных для пакетов из разных дистрибутивов).

После этого все ваши off в конфиге ни имеют значения. Обработчики прозрачны как на ладони. Любая интерфейсная прослойка должна быть на чём то подобном Rust.

Ответить | Правка | Наверх | Cообщить модератору

141. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Ivan_83 (ok), 21-Окт-26, 18:47 
А ещё на системах с ASLR она должна менятся при каждом запуске. Почему это никак не учитывается вопрос довольно интересный.
Ответить | Правка | Наверх | Cообщить модератору

146. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (146), 21-Окт-26, 19:36 
>Для успешной эксплуатации требуется определение раскладки структур в >памяти процесса, которая специфична в каждой сборке (проблема решается >перебором в эксплоите смещений, заранее вычисленных для пакетов из >разных дистрибутивов).

То есть самосборный пакет с неизвестным конфигом вызовет проблемы, по крайней мере массовые атаки не достигнут цели.

Ответить | Правка | Наверх | Cообщить модератору

147. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Нил Нонэниевич (?), 21-Окт-26, 19:39 
Деды бракоделы наплодили версий, поддерживать не хотят, и все - уязвимые. Классика.
Ответить | Правка | Наверх | Cообщить модератору

150. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (150), 21-Окт-26, 20:01 
Да вообще ужас. Столько версий наплодили и все с багами. То ли дело пых 5.3 - поставьте его и будет неуязвим (к этим конкретным уязвимостям) :D
Ответить | Правка | Наверх | Cообщить модератору

151. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от IdeaFix (ok), 21-Окт-26, 20:49 
Кто сказал CentOS 6?
Ответить | Правка | Наверх | Cообщить модератору

152. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  –1 +/–
Сообщение от Нил Нонэниевич (?), 21-Окт-26, 21:37 
Всё что нужно для разработки уже пристуствовало в 5.6. Всё что сделано дальше - один огромный поворот не туда. И вот результаты.
Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

164. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним (89), 21-Окт-26, 23:29 
> Деды бракоделы

PHP расшифровывается как Personal Home Page. Кто придумал использовать ЭТО в проде - загадка.

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

167. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Самсоныч (?), 22-Окт-26, 01:02 
Отгадка: Расмус
Ответить | Правка | Наверх | Cообщить модератору

171. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от menangen (?), 22-Окт-26, 01:28 
А вот переписали бы пыхц на расте - была бы уязвимость вообще найдена нейросеткой??
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

172. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Самсоныч (?), 22-Окт-26, 01:37 
Тогда уж на раст надо бэк переписывать, а не пых
Ответить | Правка | Наверх | Cообщить модератору

178. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Анонимemail (178), 22-Окт-26, 09:23 
не, лучше сразу интернеты переписать на rust
Ответить | Правка | Наверх | Cообщить модератору

173. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Толикemail (?), 22-Окт-26, 01:59 
WorldPress остаётся самой популярной CMS, а за ним Битрикс forever ♥
Ответить | Правка | Наверх | Cообщить модератору

181. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от Аноним21email (?), 22-Окт-26, 12:16 
Какие, интересно, первые известные сайты полетят? Нужно ли сильно беспокоиться, если пока нет возможности обновиться?
Ответить | Правка | Наверх | Cообщить модератору

187. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +/–
Сообщение от shurshur (?), 22-Окт-26, 21:04 
То, что ещё не сломали твой любимый сайт, вызвано тем, что уязвимость слишком сложна и её тяжело эксплуатировать. Пока нет доказательств, чтобы кто-то сделал что-то реально рабочее. Но и опровержений тоже нет.

В век нейронок нельзя полагаться, что такое не появится или что под какие-то старые версии не будет написан эксплойт. Надо обновляться или патчить. Сломать могут буквально в любой момент.

Я вчера накатил на все дебианоубунты пакеты от Ондрея, на старый Centos сам собрал нужную версию адаптацией спеки от remi, также накатил до свежей версии свой nextcloud в докере, который на 10 версий от стэбла отставал (nextcloud:35 вчера получил обнову с новым php). Сегодня только единственный сайтик на php 5.6 вылечил. Который и так был в докере - с нейронкой собрал контейнер с нужным php от Ондрея, потому что лечить старый контейнер, собранный 8 лет назад, было бы крайне больно.

Советую тоже не затягивать. Если надо deb - то от Ондрея с sury.org (но у него 5.6+). Если надо rpm - то от remi (но у него 7.4+), если надо rpm на el7 то для php 8.2 и 7.4 я выше кидал ссылки. А так уже есть патчи под все уязвимые версии, например в cloudlinux.

Ответить | Правка | Наверх | Cообщить модератору

185. "Уязвимость в PHP, потенциально позволяющая скомпрометировать..."  +1 +/–
Сообщение от Аноним (17), 22-Окт-26, 17:13 
Этот php придумал чувак из зависти что на линуксе нет ASP, буквально на коленке. И пошло поехало...
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




XSQUARE
Inferno Solutions
Hosting by Hoster.ru
Хоcтинг: