Preface: To mitigate this without code upgrades, teams must enforce strict multi-part file size configurations at the underlying application server/framework layer (such as setting spring[.]servlet[.]multipart[.]max-file-size in Spring Boot) rather than relying on application framework variables.

Background: Modern enterprise Java applications increasingly leverage Large Language Models (LLMs) to provide automated features such as intelligent text parsing, automated document classification, and context-aware virtual assistance. To achieve this, development teams frequently integrate Spring AI into legacy or component-oriented front-end frameworks like Apache Wicket.

Architectural Design and Intent

In a standard hybrid architecture—as detailed in the accompanying technical flow—the system is designed to seamlessly process user-provided source materials alongside conversational prompts:

1. The Presentation Layer (Apache Wicket): The application relies on standard Wicket multi-part form components (e.g., Form<Void> containing a FileUploadField) to receive multi-part HTTP requests containing files from user browsers. Wicket is explicitly configured with file-size constraints (form[.]setFileMaxSize(Bytes[.]megabytes(10))) to enforce strict application-level boundary protection and prevent resource-exhaustion vectors.
2. The Intelligence Layer (Spring AI Core): The Wicket web page injects a managed Spring service bean (@SpringBean private Assistant assistant;). This bean acts as an abstraction bridge to an LLM provider. Its role is to process user payloads and send tokenized text data via an orchestration method, such as:

java

aiResponse = assistant.analyzeDocument(fileBytes, userPrompt);

Vulnerability details:

Interception: Spring Boot’s multipart resolver parses a 50MB file before Wicket sees it.

The Bypass: Wicket detects an empty stream, falls back to HttpServletRequest#getParts(), and ignores all size constraints.

The Crash: The application runs .getBytes(), forcing massive payloads entirely into JVM memory, triggering an instant OutOfMemoryError (DoS).

Additional: Refer to infographic point 5 and 6

While technically true for individual arrays, but multiple concurrent requests compound this allocation rapidly because large byte arrays bypass short-lived garbage collection spaces (Eden) and are promoted or allocated directly where they can cause rapid heap exhaustion.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2026-71257