CVE-2021-41277 (Metabase GeoJSON API Local File Inclusion)

What this vulnerability means in practice

A local file inclusion flaw in an API means the application can be induced to read files from the server filesystem rather than only the GeoJSON content it was meant to serve. In a web application, that can turn a map feature into a path for sensitive file disclosure, environment reconnaissance, or a foothold for follow-on exploitation if exposed files reveal secrets or internal paths.

This pattern belongs to the broader class of file inclusion and path handling failures. The core security issue is not GeoJSON itself, but the trust the application places in user-controlled or attacker-influenced file references, which can collapse the boundary between intended application data and host files.

Why it is dangerous in an exposed product

When an application exposes a file-read primitive through an API, the attacker often needs little more than network access to the vulnerable endpoint. That makes this kind of flaw especially valuable for reconnaissance, because even a successful read of non-secret files can reveal configuration structure, deployment details, or other inputs that support later compromise.

Because the vulnerability sits in API logic, it can be reachable without a browser session or interactive workflow. For defenders, that means the attack surface is tied to whatever can reach the API, including reverse proxies, internet-facing application instances, and any deployment where the feature is enabled by default.

If the vulnerable path is used for custom map support, the danger is amplified by the tendency for such features to accept externally supplied content and file references. That combination can make a single request enough to expose data that was never meant to be accessible through the application layer.

How organisations assess exposure and contain it

Exposure assessment starts with asset inventory and service discovery: identify every Metabase instance, confirm whether the GeoJSON or custom map functionality is enabled, and determine whether the API is reachable from untrusted networks. Vendor advisories and the CISA KEV catalogue should be treated as the authoritative sources for version and remediation guidance.

Containment focuses on reducing reachability and limiting the blast radius of the file-read path. Network restrictions, reverse-proxy access controls, and tighter application permissions all help, especially where patching is delayed or operationally difficult. The practical goal is to make the vulnerable API harder to reach and less able to read anything valuable if it is reached.

Where file inclusion is suspected, organisations should also assume that adjacent configuration files or deployment metadata may have been exposed. That matters because the security consequence is often not only disclosure of a file, but disclosure of information that changes the attacker’s next move.

Detection and post-exploitation review

Detection should look for unusual requests to the GeoJSON or custom map API, especially requests that vary file paths, traverse directories, or target clearly non-map file names. Web access logs, reverse proxy telemetry, and application logs are the main starting points, with attention to repeated requests from the same source or short bursts that look like path probing.

After patching, organisations should review for evidence that the flaw was already used before remediation. If the exposed files could include configuration material, session material, API keys, or service credentials, those secrets should be treated as potentially compromised and rotated where applicable. A clean patch does not prove the environment stayed clean before the fix.

When review confirms exposure, the response should extend beyond the application itself. Any sensitive file that could have been read through the vulnerability becomes part of the incident scope, because file disclosure often creates identity and access follow-on risk even when the initial issue was only local file inclusion.

Risk and Threat Considerations

This vulnerability is dangerous because a file inclusion flaw can turn a normal application endpoint into a read primitive against the host. That creates disclosure risk, supports reconnaissance, and can expose material that enables deeper compromise if the retrieved files contain secrets or operational details.

Failure mechanism: An attacker supplies or influences a path that escapes the intended GeoJSON context, causing the server to return local files instead of only approved map data.

Impact: The attacker may recover sensitive configuration, internal paths, or secret material, then use that information to expand access, persist, or target additional systems.

Practitioner Guidance

Why practitioners should care: Treat this as more than a patching item, because file inclusion flaws often become disclosure incidents before they become obvious service outages. The operational question is whether the vulnerable endpoint can read anything that would be damaging if exposed.

What to watch for: Investigate any request patterns that suggest path manipulation, especially in APIs that were only meant to serve static or structured data. If the application can read host files at all, assume attackers will test whether the read scope extends to secrets, configuration, or credential-bearing material.

Related resources from NHI Mgmt Group

• What happens when a third-party file conversion API can be abused for SSRF and local file inclusion?
• CVE-2018-19410 (Paessler PRTG Network Monitor Local File Inclusion)
• What breaks when SQL injection and local file inclusion are not controlled?
• What is the difference between path traversal and local file inclusion in web application attacks?