Wysoki Odebrany

CVE-2026-84170

opublikowano: 02.11.2026, 00:17

modyfikacja: 02.11.2026, 00:17

Ocena CVSS

8.3

Wysoki · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Alokacja zasobów bez limitów i throttlingu w Apache Wicket.

org.apache.wicket.markup.html.form.upload.resource.AbstractFileUploadResource to serwerowa strona przesyłania bezformularzowego oferowana przez FileUploadToResourceField, która wysyła wybrane pliki do oddzielnie zamontowanego zasobu, a nie za pośrednictwem formularza. Zasób jest singletonem obejmującym całą aplikację i nie ma żadnego komponentu do sprawdzenia, dlatego funkcja newResourceResponse() pobiera trzy ograniczenia ograniczające przesyłanie — całkowity rozmiar żądania, maksymalny rozmiar pojedynczej części i maksymalną liczbę części — z parametrów żądania maxSize, fileMaxSize i fileCountMax i przekazuje je do parsera wieloczęściowego po ich nadejściu. Nic nie wiąże tych liczb z polem, które ma zostać przesłane. Żądanie nazywające bardzo duży maxSize jest zatem analizowane bez efektywnego pułapu całkowitego rozmiaru, a pominięcie fileMaxSize i fileCountMax pozostawia również nieskonfigurowane limity na część i liczbę części. Wartości skonfigurowane przez aplikację za pomocą FileUploadToResourceField#setMaxSize(), #setFileMaxSize() i #setFileCountMax() są sprawdzane tylko wtedy, gdy klient pominie odpowiedni parametr, więc w przypadku klienta, który go dostarcza, nie mają one żadnego efektu.

Części powyżej progu pamięci parsera są buforowane do katalogu tymczasowego kontenera, a części plików są następnie kopiowane do folderu, którego właścicielem jest IUploadsFileManager aplikacji, w podfolderze z nazwami żądań, gdzie pozostają. Część niebędąca plikiem jest w całości wczytywana do sterty podczas analizowania żądania. Jedno żądanie, powtarzalne, może zatem zająć tyle dysku lub tyle sterty, ile klient zdecyduje się wysłać. Zasób nie zawiera adnotacji autoryzacyjnej, a domyślna strategia autoryzacji zezwala na każde żądanie zasobu, więc jeśli aplikacja sama nie autoryzuje zasobu, żądanie nie wymaga uwierzytelnienia, sesji, wcześniejszego wyświetlenia strony ani interakcji użytkownika.

Aplikacja ma na to wpływ, gdy używa FileUploadToResourceField lub montuje samo FileUploadResourceReference. To nie jest zwykła ścieżka przesyłania: zasób to singleton, który należy utworzyć i zamontować celowo. Aplikacja, która nie konfiguruje żadnego limitu wysyłania, nic nie traci, ponieważ Wicket domyślnie nie stosuje własnego limitu całkowitego rozmiaru; to, co wada usuwa, to ograniczenie ustawionej aplikacji. Nie ma to wpływu na przesyłanie za pośrednictwem formularza za pomocą FileUploadField i AjaxFileDropBehavior, ponieważ oba odczytują swoje limity z komponentu, a nie z żądania. Zasób przesyłania nie istnieje w wierszu 8.x.

Ten problem dotyczy Apache Wicket: od 9.14.0 do 9.24.0, od 10.0.0 do 10.9.1. Użytkownikom zaleca się aktualizację do wersji 9.25.0 lub 10.12.0, która rozwiązuje problem.

Allocation of resources without limits or throttling in Apache Wicket.

org.apache.wicket.markup.html.form.upload.resource.AbstractFileUploadResource is the server side of the form-less upload offered by FileUploadToResourceField, which posts the selected files to a separately mounted resource rather than through a Form. The resource is an application-wide singleton with no component to consult, so newResourceResponse() takes the three limits that bound the upload - the total request size, the maximum size of a single part and the maximum number of parts - from the request parameters maxSize, fileMaxSize and fileCountMax, and hands them to the multipart parser as they arrive. Nothing binds those numbers to the field that is supposed to be uploading. A request naming a very large maxSize is therefore parsed with no effective ceiling on the total size, and omitting fileMaxSize and fileCountMax leaves the per-part and part-count limits unset as well. The values the application configured through FileUploadToResourceField#setMaxSize(), #setFileMaxSize() and #setFileCountMax() are consulted only when the client omits the corresponding parameter, so against a client that supplies one they have no effect at all.

Parts above the parser's in-memory threshold are spooled to the container's temporary directory, and the file parts are then copied into the folder the application's IUploadsFileManager owns, under a sub-folder the request names, where they remain. A part that is not a file is read into the heap in full while the request is parsed. One request, repeatable, can therefore consume as much disk or as much heap as the client chooses to send. The resource carries no authorization annotation and the default authorization strategy permits every resource request, so unless the application authorizes the resource itself the request needs no authentication, no session, no prior page view and no user interaction.

An application is affected where it uses FileUploadToResourceField, or mounts FileUploadResourceReference itself. This is not the ordinary upload path: the resource is a singleton that has to be created and mounted deliberately. An application that configures no upload limit at all loses nothing, because Wicket applies no total-size limit of its own by default; what the defect removes is a limit the application set. Uploads through Form with FileUploadField, and through AjaxFileDropBehavior, are not affected, because both read their limits from the component rather than from the request. The upload resource does not exist in the 8.x line.

This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.9.1. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.

>_ Słabości (CWE)

CWE-770

>_ Referencje

https://lists.apache.org/thread.html/bw3hn5cch3q7yrsl05m8mvmgyx4m98y7

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve