Zum Inhalt springen
← Zurück zum Cyberlagebild
Zuletzt aktualisiert 11.09.2026 16:13

CVE-2026-71257

CVSS 7.51 Quelle

Beschreibung

Apache Wicket erzwingt die Upload-Beschränkungen, die in einem Formular- oder Upload-Feld konfiguriert sind, während eine mehrteilige Anforderung mit Apache Commons FileUpload analysiert wird. Wenn der Anfragetext bereits von einer anderen Komponente verbraucht wurde, gibt Commons FileUpload keine Elemente zurück und Wicket greift auf das Lesen des Uploads über HttpServletRequest#getParts() zurück. Die Größenbegrenzung pro Datei (z. B. Form#setFileMaxSize) und die Dateianzahlgrenze (Form#setFileCountMax) werden nicht auf die auf diese Weise erhaltenen Teile angewendet, und es wird keine Ausnahme erhoben, so dass der Upload so verarbeitet wird, als ob diese Grenzen erfüllt wären. Ein Remote-Uploader kann daher Dateien einreichen, die größer oder zahlreicher sind, als es die Anwendung zulässt, bis zu dem, was die Komponente, die die Anforderung analysiert hat, zulässt. Ein Teil, der keinen Content-Type-Header trägt, wird während des Parsens zusätzlich vollständig in den Speicher eingelesen, so dass die Größe dieser Zuweisung durch die Anforderung bestimmt und nur durch dieselben externen Grenzen begrenzt wird. Die gesamte Upload-Größenbegrenzung (Form#setMaxSize) ist nicht betroffen. Commons FileUpload vergleicht die deklarierte Inhaltslänge vor dem Lesen des Körpers damit, so dass eine Anforderung, die eine übergroße Länge angibt, abgelehnt wird, bevor der Fallback erreicht wird. Der Fallback wird in Bereitstellungen erreicht, in denen ein Servlet oder Filter den Anforderungskörper bereits analysiert hat - zum Beispiel ein Servlet, das mit @MultipartConfig, dem mehrteiligen Resolver von Spring Boot oder einem Filter, der HttpServletRequest#getParameter() bei einer mehrteiligen Anforderung aufruft, kommentiert wurde. Es gilt für die Wicket-Komponenten, die Uploads auf diesem Pfad akzeptieren, einschließlich Formular mit FileUploadField, FileUploadToResourceField und AjaxFileDropBehavior. Anwendungen, die weder eine Datei- noch eine Dateizählgrenze konfigurieren, sind nicht betroffen, da Wicket standardmäßig auch nicht gilt. Dieses Problem betrifft Apache Wicket: von 8.0.0 bis 8.18.0, von 9.0.0 bis 9.23.0, von 10.0.0 bis 10.10.0. Benutzern wird empfohlen, auf Version 8.19.0, 9.24.0 oder 10.11.0 zu aktualisieren, die das Problem beheben. Benutzer von Apache Wicket 7.x oder älter, die nicht mehr unterstützt werden, sollten auf eine unterstützte Version upgraden. Als Workaround konfigurieren Sie äquivalente Grenzwerte in der Komponente, die die Anforderung analysiert – zum Beispiel spring.servlet.multipart.max-file-size und max-request-size oder maxFileSize und maxRequestSize in @MultipartConfig oder im web.xml-Element.

HerstellerApache Software Foundation
Produktwicket
ProduktfamilieKeine Angaben
Betroffene Versionen>=8.0.0 <8.19.0, >=9.0.0 <9.24.0, >=10.0.0 <10.11.0
Behobene VersionenKeine Angaben

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

PrioritätGelb
EinordnungZeitnah behandeln: hohes technisches Risiko.

Empfohlene Schritte

  • Betroffene Systeme identifizieren: Apache Software Foundation wicket.
  • Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
  • Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
  • Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

  • Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
  • WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
  • Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
  • Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.