CVE-2024-43707 - Sensitive Information Disclosure in Kibana's Elastic Agent Policies

---

In June 2024, a new vulnerability was disclosed in Kibana, tracked as CVE-2024-43707. This security issue enables users _without_ proper Fleet access to view Elastic Agent policies, which could contain sensitive information depending on the installed integrations and their configuration. Here’s an exclusive, easy-to-understand breakdown of the vulnerability, how it works, and what you can do about it.

What Is CVE-2024-43707?

CVE-2024-43707 is categorized as an information disclosure vulnerability. The bug lies in Kibana, the web UI for the Elastic Stack. Usually, only users with the Fleet privilege (a part of the Elastic Security management system) should be able to access Agent policies that can potentially house secrets like credentials or API keys.

Due to this flaw, users who do NOT have Fleet permissions could still access and view these Agent policies. The sensitivity of the leaked information depends on the integrations applied to Elastic Agents, such as cloud credentials, internal network addresses, or tokens, depending on how organizations use the tool.

Why Is This a Big Deal?

- Unauthorized Access: Users outside the security/ops teams could see sensitive operational data.
- Wider Attack Surface: Leaked credentials or tokens might be reused across systems, amplifying the impact.
- Compliance Risk: Organizations under regulations like HIPAA, GDPR, or PCI could face legal and regulatory exposure.

Example: How the Issue Works

Let’s illustrate the issue with a simplified example. Assume your company uses Elastic Agent for collecting logs, and the agent’s configuration stores an AWS API key for integration with AWS CloudWatch.

This API key is normally hidden from users without Fleet access. However, due to CVE-2024-43707, a standard Kibana user (with no Fleet privileges) could fetch and read the entire policy, including the sensitive AWS key.

Step 1: Authenticate to Kibana

Login to Kibana using a low-privileged account, one without Fleet access.

Step 2: Access the Agent Policies API

curl -X GET \
  -H "kbn-xsrf: true" \
  -H "Authorization: Bearer YOUR_LOW_PRIVILEGE_TOKEN" \
  "https://your-kibana-instance/api/fleet/agent_policies";

The response might look like this (simplified for clarity)

{
  "items": [
    {
      "id": "policy-123",
      "name": "Production Agent Policy",
      "package_policies": [
        {
          "name": "aws-cloudwatch",
          "inputs": [
            {
              "config": {
                "access_key": "AKIA...REDACTED",
                "secret_key": "wJalr...REDACTED"
              }
            }
          ]
        }
      ]
    }
  ]
}

> Notice the access_key and secret_key are visible.

References & Original Sources

- Elastic Security Advisory - CVE-2024-43707
- CVE Page at MITRE
- Kibana Documentation – Fleet and Agent Policies

You are vulnerable if

- You're running an affected version of Kibana (check Elastic advisories for exact version ranges).
- You use Fleet/Elastic Agents with any sensitive integrations.

Elastic has released patched versions for affected branches. Upgrade as soon as possible

- Elastic Stack 8.13.4 or later
- Other relevant versions as per [Elastic's advisory]

Mitigation:

Rotate any secrets you've configured in Agent policies.

3. Monitor access logs for unusual queries to /api/fleet/agent_policies.

Final Thoughts

CVE-2024-43707 is another reminder of the importance of strong internal access controls and software hygiene. If you're managing an Elastic Stack with Fleet and Elastic Agents, patch now and review your configurations. Always keep your stack updated, and periodically audit internal permissions.

- Elastic Agent Security
- How to rotate AWS keys

*(All content above is original and tailored for this post.)*

Timeline

Published on: 01/23/2025 06:15:27 UTC