DOS vulnerability in bearer token parsing

I stumbled upon this vulnerability when I accidentaly copied the following shortened Base64 bearer token from Firefox console (notice the "…" character):

eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIyZ3RYd0FMb2h6ekNYTkFaYjBLbGFDVUtnQ01xMi0wUlFiNkVRYWFSeGE0In0.eyJleHAiOjE2MTc3MTA3MDgsImlhdCI6MTYxNzcxMDQwOCwiYXV0aF90aW1lIjoxNjE3NzEwNDA2LCJqdGkiOiJlMjEzZjY2Ni00Y2ZjLTQ4ZWItOTcxZi03NzEyMzA5YWYyZjYiLCJpc3MiOiJodHRwczovL3BnZGV2LnNlZmlyYS5jei9hdXRoL3JlYWxtcy9kZWZhdWx0IiwiYXVkIjpbIm9iZWxpc2stc3AtYXBpIiwiYWNjb3VudCJdLCJzdWIiOiI3NDYxYWUzNy05ODAxLTQ2MGQtODkwYS1lMTY0ZjUyM2Y4NzIiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJvYmVsaXNrLXNwLWd1aSIsIm5vbmNlIjoiYTIwZmM1ZTUtZTVmZ…hbCIsInByZWZlcnJlZF91c2VybmFtZSI6InRlc3QiLCJnaXZlbl9uYW1lIjoiS2F6aXN2xJt0IE9zbcO9IiwiZmFtaWx5X25hbWUiOiJ6IEJvxb7DrSB2xa9sZSBrcsOhbCIsImVtYWlsIjoidGVzdEBzZWZpcmEuY3p4In0.oyOijY0OluxSzqsaZtTwH3_kl327jCziXQcFRpsoPpCqTXbwQmn4s4_75ov83iwVVi_tohaVniof_Y80IaMz62jzzJvr5HZNzFPjXbHMO4W4Wgp2HwtRJBDIIfpMvhyR6OYQfSmNl7Ie-1X5ij7PTeMO5qUH_U725NdzSLwz3A8DC7JAgpWdUJxJHbAUYtqoyOHHM8IYpzq0yGU0Zq3LS7EqN-mH3s4OqzTgcgXL7T7bpybTyjOF7e3GLQt9tn9E9Ch3ZPP9MtsVRQ8sJZRo1q-kZBQDSPkiCw0o-pOeVxzXy5LvSkFPLTp73ab2H0V08xKzQSKpjYOx9XKc8yzqkA

Invoking a service secured by OAuthRequestFilter results in the thread getting stuck in an infinite loop, consuming CPU indefinitely. This seems to be a result of lenient parsing of both Base64 and JSON. I put together a minimal Maven project which can be used to reproduce the behavior by invoking the following cURL:

curl -v -H "Authorization: Bearer [token above]" http://localhost:8080/services/myapp/hello

I also attach the stack trace of the thread getting stuck.