fix(kubernetes-client): parse Basic proxy credentials on first colon - #7947
Open
GrosQuildu wants to merge 2 commits into
Open
fix(kubernetes-client): parse Basic proxy credentials on first colon#7947GrosQuildu wants to merge 2 commits into
GrosQuildu wants to merge 2 commits into
Conversation
GrosQuildu
requested review from
ash-thakur-rh,
manusa and
shawkins
as code owners
June 26, 2026 13:20
GrosQuildu
added a commit
to GrosQuildu/kubernetes-client
that referenced
this pull request
Jun 26, 2026
GrosQuildu
force-pushed
the
issue-80-proxy-password-colon
branch
from
June 26, 2026 17:14
87e0349 to
0e0648c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fabric8 decodes configured
Proxy-Authorizationcredentials by base64-decoding the Basic value and splitting the decoded string on every colon. A proxy password such aspa:ssdecodes toproxy-user:pa:ss, so the decoder returns three fields instead of the expected username/password pair. Jetty, Vert.x 4, and Vert.x 5 then treat the valid credential as undecodable and fall back to an interceptor that addsProxy-Authorizationto the Kubernetes API request itself. For HTTPS API requests through an HTTP proxy, this sends the proxy credential inside the CONNECT tunnel to the API origin, not to the proxy.The affected decoder is in
HttpClientUtils.decodeBasicCredentials:The Basic authentication format uses the first colon as the separator between the username and password; text after the first colon is part of the password. This is different from URI userinfo syntax. Users may percent-encode a colon as
%3Awhen placing a password in a proxy URL, but after URL parsing the Basic credential is stillusername:password-with-colon. For Fabric8'sConfig.proxyPasswordfield, percent-encoding the colon would change the literal password topa%3Assand would not representpa:ss.The affected backends call
decodeBasicCredentialsand useaddProxyAuthInterceptorwhen it returnsnull:Jetty proxy-auth fallback path (
JettyHttpClientBuilder.java).Vert.x 4 proxy-auth fallback path (
VertxHttpClientBuilder.java).Vert.x 5 proxy-auth fallback path (
Vertx5HttpClientBuilder.java).The fallback interceptor writes the proxy credential into the application request headers:
Proxy-auth request-header fallback (
StandardHttpClientBuilder.java).Exploit Scenario
An attacker controls a kubeconfig, cluster profile, or integration setting that selects the Kubernetes API endpoint for an application that uses Fabric8 behind an HTTP proxy. The application has proxy credentials configured through
Config.proxyUsernameandConfig.proxyPassword, and the proxy password contains a colon because it was generated by a password manager or secret manager. When the application connects to the attacker's HTTPS endpoint through the Jetty, Vert.x 4, or Vert.x 5 backend, Fabric8 misparses the valid Basic credential and addsProxy-Authorizationto the tunneled Kubernetes API request. The attacker receives the proxy credential from the HTTPS origin request and can attempt to use it against the victim's proxy.The following Java PoC starts a local HTTPS origin and a raw HTTP CONNECT proxy, configures Fabric8 with
proxyUsername=proxy-userandproxyPassword=pa:ss, and records whether the CONNECT request or the HTTPS origin receivesProxy-Authorization.PoC Maven project.
PoC Java harness.
Run the PoC with:
On the unpatched client, the proxy receives no CONNECT credential, while the HTTPS origin receives the proxy credential:
The base64 value decodes to
proxy-user:pa:ss.We also validated a broader harness against JDK, OkHttp, Jetty, Vert.x 4, and Vert.x 5. The relevant unpatched output was:
Threat Model
This seems like a technical bug.
Fix
Split decoded Basic credentials on the first colon only. This preserves valid passwords that contain colons and prevents Jetty, Vert.x 4, and Vert.x 5 from falling back to the generic request-header interceptor.
We validated the patch in a fresh local clone from the target repository's
mainbranch:The focused regression test passed:
The full directly changed module test suite also passed:
./mvnw -B -ntp -pl kubernetes-client-api testThe module test run emitted existing JVM dynamic-agent, class-data-sharing, and test logger warnings, but it completed successfully.
Running the compact PoC with the patched
kubernetes-client-api/target/classesplaced before the unpatched snapshot dependency makes the origin leak disappear:The broader patched backend validation also stopped sending
Proxy-Authorizationto HTTPS origins:Paweł Płatek from Trail of Bits in collaboration with OpenAI.