Session lock leak on an invalid UI id allows DoS in Vaadin 8

A single request carrying a non-numeric v-uiId parameter leaves a Vaadin Framework 8 session locked for good. Every later request to that session blocks, and repeating the request exhausts the servlet container's thread pool, which takes the application down. No authentication is needed.

VaadinService.requestEnd() locks the session and then reads the v-uiId request parameter outside the block that releases the lock. When the value is not an integer, Integer.parseInt throws while the lock is held, the unlock is skipped, and the container thread returns to its pool still owning the session's lock.

From that point every request to the session that runs on another thread waits forever in VaadinService.lockSession(). Repeating the malformed request leaks more locks, and two threads each holding a leaked lock can deadlock. The application does not recover on its own: the locks are released only by restarting it.

The request needs nothing but a session cookie, which any client obtains with one ordinary request, so the attack is available to anyone who can reach the application. It also happens by accident: the report that led to this advisory came from a production node that stopped responding while an automated security scanner was fuzzing the parameter, with all 200 container threads blocked on session locks.

The behaviour exists in two shapes. From 8.16.1 the parameter is read inline in requestEnd before the try block. In 8.16.0 it is read one call deeper, in findUI(), which requestEnd calls inside its finally block before unlocking. Both skip the unlock when the value is not an integer.

Vaadin Framework 7 is not affected, and neither is Vaadin 10 or later: in Flow the lock is released in a finally block and the UI id is not read there.

Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include:

Product version	Mitigation
Vaadin Framework 8.16.0 - 8.32.1	Upgrade to 8.32.2

Vaadin Framework 7 and Vaadin 10 and later do not carry this behaviour and need no upgrade for this issue.

Workaround for applications that cannot upgrade yet: reject requests whose v-uiId parameter is not an integer before Vaadin handles them, by overriding VaadinServlet.service() and answering 400 for those requests. Locks that have already leaked are released only by restarting the application.

Maven coordinates	Vulnerable version	Fixed version
com.vaadin:vaadin-server	8.16.0 - 8.32.1	≥8.32.2
com.vaadin:vaadin-server-mpr-jakarta	8.18.0 - 8.32.1	≥8.32.2

The MPR Jakarta artifact carries the same class and its 8 line begins at 8.18.0, which is why its range starts there. Its 7.7.x releases are not affected.

Michal Legocki, Finago