You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0cbd1c8
Browse filesBrowse the repository at this point in the historyBrowse files
fix(elasticsearch): reject URL-special characters in decoded Cloud ID parts
The base64-alphabet check validated the encoded payload, not the decoded
components, so a Cloud ID could inject into the assembled origin. Elastic's own
decoder rejects #@?/ in the host and each UUID, with fixtures named inject-es,
inject-kb and inject-host.
An '@' is the serious one: it turns the UUID into userinfo and hands the origin
to the attacker, so the ApiKey header is sent to their host. The other three
truncate the authority to a bare label.
Guarded on the decoded component before assembly rather than on the finished
string, since checking the assembled URL means re-parsing the parse being
subverted. ':' is rejected too, beyond Elastic's set: the port split takes only
the last colon, so a second one produces a two-colon authority and a bare
Invalid URL -- the same unactionable failure the port fix removed. Both are
no-ops on a real hostname and a hex UUID.
The Kibana UUID is deliberately not checked: we only ever build the
Elasticsearch origin, so rejecting on a component that never reaches our URL
would refuse a Cloud ID that works fine for search.
0 commit comments