CVE-2026-49093
Description
Server-Side Request Forgery (CWE-918) in Kibana can allow an authenticated user with connector management privileges to bypass the operator-configured connector allowlist, causing the Kibana server to issue outbound requests to destinations the egress controls were intended to block.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An authenticated Kibana user with connector management privileges can bypass the configured connector allowlist to perform SSRF and issue outbound requests to blocked destinations.
Vulnerability
CVE-2026-49093 is a Server-Side Request Forgery (SSRF) vulnerability in Kibana versions 9.3.0 up to and including 9.3.2 (the 9.x line) [1]. The bug occurs in the connector management functionality where an authenticated user with connector management privileges can bypass the operator-configured connector allowlist (xpack.actions.allowedHosts) [1]. This bypass causes the Kibana server to issue outbound requests to destinations that the egress controls were intended to block. Deployments that have xpack.actions.allowedHosts set to a non-wildcard value are affected; the default ["*"] setting does not enforce an allowlist and is not impacted [1].
Exploitation
An attacker must be an authenticated user with connector management privileges in Kibana [1]. The attacker needs to be on the network, but no special network position beyond authenticated access is required. The prerequisite is that the deployment must have xpack.actions.allowedHosts configured to a non-wildcard value (i.e., an explicit allowlist) [1]. The attacker can then craft requests through the connector functionality to bypass this allowlist, causing the Kibana server to issue outbound requests to arbitrary destinations [1].
Impact
Successful exploitation results in the Kibana server making outbound HTTP(S) requests to destinations that were meant to be blocked by the operator-configured egress controls [1]. The impact is primarily a breach of confidentiality (C) as the attacker can potentially access internal network resources or exfiltrate data, with high severity on confidentiality. The CVSSv3.1 score is 6.3 (Medium) [1]. The scope is changed (S) as the compromised component (Kibana) impacts resources beyond its original authorization (the allowed hosts list) [1].
Mitigation
The vulnerability is fixed in Kibana version 9.3.3, released on 2026-05-28 [1]. Users should upgrade to 9.3.3 or later. For users who cannot upgrade immediately, the advisory recommends restricting connector management privileges to limit the attack surface [1]. Elastic Cloud Serverless deployments have already been remediated through continuous deployment [1]. No workaround other than privilege restriction is documented, and there is no indication this CVE is on the KEV list.
AI Insight generated on May 28, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
1bf7be757e102[9.3] [Osquery] Fix `profile_uid` dropped in `getUserInfo` authc fallback (#258866) (#259258)
2 files changed · +98 −1
x-pack/platform/plugins/shared/osquery/server/lib/get_user_info.test.ts+97 −0 added@@ -0,0 +1,97 @@ +/* + * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one + * or more contributor license agreements. Licensed under the Elastic License + * 2.0; you may not use this file except in compliance with the Elastic License + * 2.0. + */ + +import { httpServerMock, loggingSystemMock } from '@kbn/core/server/mocks'; +import type { SecurityPluginStart } from '@kbn/security-plugin/server'; +import { getUserInfo } from './get_user_info'; + +describe('getUserInfo', () => { + const logger = loggingSystemMock.createLogger(); + const request = httpServerMock.createKibanaRequest(); + + it('returns undefined when security is unavailable', async () => { + const result = await getUserInfo({ request, logger }); + + expect(result).toBeUndefined(); + }); + + it('returns user profile info when available', async () => { + const security = { + userProfiles: { + getCurrent: jest.fn().mockResolvedValue({ + uid: 'profile-1', + user: { + username: 'user-name', + full_name: 'Full Name', + email: 'user@example.com', + }, + }), + }, + authc: { + getCurrentUser: jest.fn(), + }, + } as unknown as SecurityPluginStart; + + const result = await getUserInfo({ request, security, logger }); + + expect(result).toEqual({ + username: 'Full Name', + full_name: 'Full Name', + email: 'user@example.com', + profile_uid: 'profile-1', + }); + }); + + it('falls back to authc when user profile lookup fails', async () => { + const security = { + userProfiles: { + getCurrent: jest.fn().mockRejectedValue(new Error('failed')), + }, + authc: { + getCurrentUser: jest.fn().mockReturnValue({ + username: 'fallback-user', + full_name: null, + email: 'fallback@example.com', + }), + }, + } as unknown as SecurityPluginStart; + + const result = await getUserInfo({ request, security, logger }); + + expect(result).toEqual({ + username: 'fallback@example.com', + full_name: null, + email: 'fallback@example.com', + profile_uid: null, + }); + }); + + it('uses profile_uid from authc fallback when available', async () => { + const security = { + userProfiles: { + getCurrent: jest.fn().mockResolvedValue(null), + }, + authc: { + getCurrentUser: jest.fn().mockReturnValue({ + username: 'cloud-user', + full_name: null, + email: 'cloud-user@example.com', + profile_uid: 'u_cloud_profile_123', + }), + }, + } as unknown as SecurityPluginStart; + + const result = await getUserInfo({ request, security, logger }); + + expect(result).toEqual({ + username: 'cloud-user@example.com', + full_name: null, + email: 'cloud-user@example.com', + profile_uid: 'u_cloud_profile_123', + }); + }); +});
x-pack/platform/plugins/shared/osquery/server/lib/get_user_info.ts+1 −1 modified@@ -58,7 +58,7 @@ export const getUserInfo = async ({ username: displayName, full_name: user.full_name ?? null, email: user.email ?? null, - profile_uid: null, + profile_uid: user.profile_uid ?? null, }; } } catch (error) {
Vulnerability mechanics
No source-code context for this CVE — mechanics is only generated when we can read the actual fix diff. Without that, the four sections (root cause, attack vector, affected code, fix) would be speculation rather than analysis.
References
1News mentions
0No linked articles in our index yet.