Apache Wicket bis 9.24.0/10.9.1 erweiterte Rechte

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.3$5k-$25k2.60+

Zusammenfassunginfo

Es wurde eine Schwachstelle in Apache Wicket bis 9.24.0/10.9.1 entdeckt. Sie wurde als kritisch eingestuft. Dabei geht es um eine nicht genauer bekannte Funktion. Durch die Manipulation mit unbekannten Daten kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Die Verwundbarkeit wird als CVE-2026-84170 geführt. Der Angriff lässt sich über das Netzwerk starten. Es ist kein Exploit verfügbar.

Detailsinfo

Es wurde eine Schwachstelle in Apache Wicket bis 9.24.0/10.9.1 gefunden. Sie wurde als kritisch eingestuft. Es betrifft eine unbekannte Funktion. Durch Manipulieren mit einer unbekannten Eingabe kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-434 vorgenommen. Dies wirkt sich aus auf Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

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.

Auf lists.apache.org kann das Advisory eingesehen werden. Die Verwundbarkeit wird seit dem 01.09.2026 unter CVE-2026-84170 geführt. Sie ist leicht ausnutzbar. Der Angriff kann über das Netzwerk erfolgen. Nicht vorhanden sind sowohl technische Details als auch ein Exploit zur Schwachstelle. Als Preis für einen Exploit ist zur Zeit ungefähr mit USD $5k-$25k zu rechnen (Preisberechnung vom 01.11.2026). MITRE ATT&CK führt die Angriffstechnik T1608.002 für diese Schwachstelle.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Produktinfo

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CNA CVSS-B Score: 🔒
CNA CVSS-BT Score: 🔒
CNA Vector: 🔒

CVSSv3info

VulDB Meta Base Score: 6.3
VulDB Meta Temp Score: 6.3

VulDB Base Score: 6.3
VulDB Temp Score: 6.3
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Erweiterte Rechte
CWE: CWE-434 / CWE-284 / CWE-266
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: keine Massnahme bekannt
Status: 🔍

0-Day Time: 🔒

Timelineinfo

01.09.2026 CVE zugewiesen
01.11.2026 +61 Tage Advisory veröffentlicht
01.11.2026 +0 Tage VulDB Eintrag erstellt
01.11.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: apache.org

Advisory: lists.apache.org
Status: Bestätigt

CNA: apache
CVE: CVE-2026-84170 (🔒)

GCVE (CVE): GCVE-0-2026-84170
GCVE (VulDB): GCVE-100-429690

Eintraginfo

Erstellt: 01.11.2026 23:37
Anpassungen: 01.11.2026 23:37 (63)
Komplett: 🔍
Cache ID: 216::103

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Might our Artificial Intelligence support you?

Check our Alexa App!