CVE-2026-54508

Received Received - Intake

TREK Travel Planner Server-Side Request Forgery via Redirect

Publication date: 2026-08-20

Last updated on: 2026-08-20

Assigner: GitHub, Inc.

Description

TREK is a collaborative travel planner. Prior to 3.1.0, TREK validates only the initial URL before native redirect following in importGoogleList() and importNaverList() in server/src/services/placeService.ts and resolveGoogleMapsUrl() in server/src/services/mapsService.ts. The affected sinks call checkSsrf() from server/src/utils/ssrfGuard.ts and then use fetch() with redirect: 'follow' instead of the DNS-pinned safeFetch() path, so a public attacker-controlled URL can redirect the server to loopback, RFC 1918, or cloud metadata addresses without revalidation. An authenticated trip member can reach the list-import routes, and any authenticated user can reach /api/maps/resolve-url, allowing blind GET requests to internal services without response-body reflection. This issue is fixed in version 3.1.0.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-08-20

Last Modified

2026-08-20

Generated

2026-08-21

AI Q&A

2026-08-21

EPSS Evaluated

N/A

NVD

CVE-2026-54508

Affected Vendors & Products

Vendor	Product	Version / Range
trek	trek	3.1.0

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-918	The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Attack-Flow Graph

Executive Summary

This vulnerability in TREK, a collaborative travel planner, involves improper URL validation before redirects. The application fails to validate URLs after initial checks in specific functions, allowing attackers to redirect server requests to internal or restricted addresses like loopback or cloud metadata services. This occurs because the app uses fetch() with redirect: follow instead of a safer DNS-pinned method.

Detection Guidance

This vulnerability involves improper URL validation leading to SSRF risks. To detect it, monitor network traffic for outbound requests to internal or cloud metadata addresses from the TREK application. Check server logs for requests to /api/maps/resolve-url or list-import routes with redirect parameters. Ensure the application uses safeFetch() instead of fetch() with redirect: 'follow'.

Impact Analysis

An authenticated attacker could exploit this to send blind GET requests to internal services without seeing responses. This could lead to unauthorized access to sensitive data, internal service manipulation, or potential data exfiltration from internal systems.

Compliance Impact

This vulnerability could lead to unauthorized access to sensitive data, which may violate GDPR's data protection requirements or HIPAA's safeguards for protected health information. It undermines security controls needed for compliance.

Mitigation Strategies

Upgrade TREK to version 3.1.0 or later to address the SSRF vulnerability in URL handling and redirect logic.

Hi! I’m here to help you understand CVE-2026-54508. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70