[netomi]

Problem

GitHub login fails with:

[invalid_token_response] ... I/O error on POST request for "https://github.com/login/oauth/access_token": Maximum line length limit exceeded

httpcore5 5.4.3 and later reject header lines over 8192 bytes (older versions had no limit); 5.4.3 came in with the CVE-2026-54428 fix (#1977). GitHub's successful token response now carries a Content-Security-Policy header longer than that, so the code exchange fails. The wire log shows the status line and the first headers parse fine and the failure is on that header. The same code fails on commits before the Spring Boot 4.0.9 bump and before the TanStack migration, so it is not a regression from those.

Change

• TokenResponseClients builds the authorization-code token client on an HttpClient 5 connection manager with maxLineLength raised to 64 KiB. It uses the same converters and error handler as the client Spring Security builds by default, and honours system properties (proxy settings).
• SecurityConfig passes it to oauth2Login via tokenEndpoint(...).

There is no configuration route: the limit can only be set on Http1Config, and Spring Security's token client builds its own RestClient, so Spring Boot spring.http.client.* settings do not reach it. Pinning httpcore5 back below 5.4.3 would reintroduce the CVE.

Testing

TokenResponseClientsTest serves a token response with a 20 KB header from a local server. With the limit at 8192 it fails with the exact error above (MessageConstraintException: Maximum line length limit exceeded); with the fix it passes. spotlessCheck and the org.eclipse.openvsx.security.* tests pass. The full ./gradlew test suite and a login against real GitHub were not run.

Notes

• Neither the new client nor Spring's default sets connect or read timeouts.
• Other HttpClient 5 callers (RestTemplateConfig, scanning, trusted publishing) keep the 8192 default; none of them has been seen to fail.

🤖 Generated with Claude Code