CVE-2026-87821 in Lara Dashboardinfo

Summary

by MITRE • 09/09/2026

Lara Dashboard through 1.3.1 contains a server-side request forgery vulnerability in the POST /api/admin/builder/markdown/fetch endpoint that allows any authenticated user to fetch arbitrary URLs and read the response body. Attackers can read internal HTTP services and cloud metadata including IAM credentials by supplying malicious URLs without host validation or redirect restrictions.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 09/09/2026

The Lara Dashboard software, specifically versions up through 1.3.1, contains a critical server-side request forgery vulnerability located within the POST /api/admin/builder/markdown/fetch endpoint. This flaw stems from insufficient input validation and the absence of proper host verification mechanisms when processing user-supplied URLs. The application allows authenticated users to specify arbitrary destination addresses for HTTP requests initiated by the backend server. Because there are no restrictions on which hosts can be contacted, nor any safeguards against following redirects to malicious or internal destinations, an attacker can manipulate this endpoint to force the server to communicate with unintended targets. This lack of validation is a fundamental design error that transforms a standard API function into a powerful tool for network reconnaissance and data exfiltration within trusted environments.

The operational impact of this vulnerability is severe due to its ability to bypass internal security boundaries. By supplying malicious URLs, an attacker can target services running on localhost or other private IP addresses that are not exposed to the public internet but remain accessible from the server hosting Lara Dashboard. This includes accessing cloud metadata endpoints such as AWS Instance Metadata Service (IMDS) or Azure Managed Identity endpoints. These metadata services often contain sensitive configuration details and temporary security credentials, including IAM access keys and secret tokens. The ability to read these responses allows an attacker to escalate privileges significantly, potentially gaining full control over associated cloud infrastructure by stealing the identities of running instances or containers.

From a classification perspective, this vulnerability aligns with CWE-918, which defines Server-Side Request Forgery (SSRF). It also relates closely to CWE-20, Improper Input Validation, as the root cause is the failure to sanitize and validate user-controlled input before use in backend processes. In terms of offensive security tactics, this exploit maps directly to MITRE ATT&CK technique T1571, which covers Non-Standard Ports, although more broadly it fits under T1098, Account Manipulation, if used to steal credentials for persistent access, or generally within the initial compromise and discovery phases where attackers leverage SSRF to map internal networks. The specific capability to read cloud metadata places this in a high-risk category often associated with lateral movement and privilege escalation scenarios in modern cloud-native architectures.

Mitigation strategies must focus on implementing strict allow-listing of permitted hostnames for outbound requests from the backend server. Developers should validate that any URL provided by the user resolves only to explicitly trusted domains, rejecting all others at the application layer before a connection is attempted. Additionally, network-level controls such as firewall rules or security groups can be configured to block the web server’s IP address from accessing internal metadata endpoints and private subnets where sensitive services reside. It is also recommended to disable HTTP redirects in client libraries used for fetching external content, preventing attackers from chaining requests to bypass initial host checks. For organizations currently running affected versions of Lara Dashboard, immediate patching to a version that addresses this flaw is the most effective remediation step until these architectural controls are fully implemented and tested.

Responsible

VulnCheck

Reservation

09/09/2026

Disclosure

09/09/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!