MEDIUM 6.5

CVE-2026-47277: Runtipi Arbitrary File Read via Symlink in App Logo Endpoint

Runtipi, a personal homeserver orchestrator, contains a vulnerability that allows unauthenticated users to read arbitrary files from the host system through its app marketplace logo endpoint. When Runtipi clones third-party app repositories, an attacker can craft a malicious app store that includes a symbolic link disguised as a logo file. Since the logo endpoint doesn't properly validate symlink targets, requesting this logo causes Runtipi to follow the symlink and return sensitive files like environment variables, JWT secrets, or application logs to the requester. This affects Runtipi versions 4.9.1 through 4.9.3 and has been patched in version 4.10.0.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-22, CWE-59
Affected products
0 configuration(s)
Published / Modified
2026-06-17 / 2026-06-17

NVD description (verbatim)

Runtipi is a personal homeserver orchestrator. In versions 4.9.1 through 4.9.3, Runtipi serves marketplace app logos from files inside cloned app-store repositories through an unauthenticated endpoint, which leads to arbitrary file read through app-store logo symlinks. The path guard checks only the lexical path before Node reads the file, so a Git app store that contains metadata/logo.jpg as a symbolic link can cause Runtipi to read and return the symlink target. Because the endpoint is public and the symlink target may point outside the cloned repository, this can expose local files from the Runtipi container such as /data/.env, /data/state/seed, logs, or application files. This can disclose JWT secrets, service credentials, local configuration, and operational logs depending on the instance. The issue has been fixed in version 4.10.0.

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability stems from insufficient path traversal protection in the unauthenticated logo-serving endpoint. Runtipi performs a lexical (string-based) check of file paths before reading, but this validation occurs before the operating system resolves symbolic links. An attacker controlling a Git app-store repository can place a symlink at the expected logo location (e.g., metadata/logo.jpg) pointing to sensitive files. When a user or automated process requests the logo, Runtipi reads the symlink target without further validation, exposing files outside the intended repository directory. The flawed logic fails to account for post-validation symlink resolution, a common path-traversal mistake. Affected paths may include /data/.env, /data/state/seed, and application configuration files stored within the Runtipi container.

Business impact

This vulnerability poses a direct confidentiality risk to Runtipi deployments. Exposed .env files typically contain database credentials, API keys, and JWT signing secrets that could enable lateral movement or authentication bypass in broader infrastructure. Seed files and cryptographic material are especially valuable to attackers seeking persistent access or certificate forgery. For personal homeserver operators, exposure of operational logs could reveal system architecture, running services, or user activity patterns. If Runtipi is used in shared environments or integrated with organizational infrastructure, the credential leakage risk escalates significantly. The unauthenticated nature of the endpoint means no attacker capability assumptions are required beyond basic network access.

Affected systems

Runtipi versions 4.9.1, 4.9.2, and 4.9.3 are confirmed vulnerable. The vulnerability requires the targeted Runtipi instance to have cloned a malicious app-store repository and attempted to load logos from it; however, because Runtipi's marketplace functionality is a core feature, most active deployments are likely at risk if they interact with any third-party app stores. Version 4.10.0 and later contain the fix.

Exploitability

Exploitability is straightforward. An attacker needs only to create a public Git repository formatted as a Runtipi app store and include a symlink at the logo location pointing to /data/.env or another sensitive target. Once a Runtipi instance adds this malicious app store and attempts to serve the logo (whether manually or through automatic app discovery), the unauthenticated endpoint leaks the target file content over HTTP. No authentication, user interaction during the attack, or special capabilities are required to exploit, though the CVSS rating of 6.5 (Medium) reflects that user interaction is factored into the scoring—specifically, a user must trigger the logo load by viewing the app or Runtipi discovering it. The technical bar for creating a malicious app store is low.

Remediation

Upgrade to Runtipi version 4.10.0 or later, which implements proper symlink resolution checks in the logo-serving endpoint. Before patching, if you cannot immediately upgrade, consider restricting network access to your Runtipi instance and avoiding untrusted app-store repositories. Do not add external or third-party app stores from unknown sources until you have confirmed your version is patched. Additionally, rotate any secrets (JWT keys, database credentials, API tokens) that may have been exposed through logs or .env files in unpatched instances.

Patch guidance

Apply the official Runtipi update to version 4.10.0 or later. Verify the release notes and checksums from the official Runtipi repository to ensure authenticity. If you are running a self-hosted or containerized deployment, rebuild your container image with the patched version and restart services. For managed Runtipi instances, check with your provider for automatic patching status. After patching, review application logs for any suspicious requests to the logo endpoint (typically /logo endpoints or similar paths) from unexpected sources, which may indicate prior exploitation attempts.

Detection guidance

Monitor HTTP access logs for repeated requests to logo-serving endpoints (typically paths like /api/app/*/logo or /apps/*/logo) from unusual IP addresses or user agents, especially requests that precede the patching date. Watch for 200 responses returning unusually large payloads (symlink targets often pull in larger system files than expected small image data). Review Runtipi application logs for warnings about symlinks or path validation failures. If you have added third-party app stores, audit their repository contents for suspicious symlinks using `find repo -type l` or equivalent commands. Examine the /data/.env and /data/state/seed files on affected instances for signs of compromise (unexpected access timestamps, missing or modified content).

Why prioritize this

Although rated CVSS 6.5 (Medium), this vulnerability merits prompt attention due to its unauthenticated, easily exploitable nature and the high sensitivity of exposed artifacts (JWT secrets, database credentials). The attack surface—any app store a user adds—is broad and relatively invisible. Credential theft from .env files can lead to full container compromise, making this a stepping stone to further attacks. Organizations running Runtipi for critical personal infrastructure or in connected networks should prioritize patching within days rather than weeks.

Risk score, explained

The CVSS 6.5 score reflects a high-impact confidentiality breach (C:H) with no authentication required (PR:N) and low attack complexity (AC:L), balanced against the requirement for user interaction (UI:R)—specifically, a user must trigger the logo load via the marketplace. The Remote (AV:N) vector confirms network exploitability. No integrity or availability impact is scored. In real-world context, the score may underrepresent risk if your instance uses public or semi-trusted app stores, as the attack surface is effectively larger than a typical authenticated file-read.

Frequently asked questions

Can I safely use third-party app stores if I'm running a vulnerable version?

Not without additional safeguards. The vulnerability is exploitable as soon as you add an app store and Runtipi attempts to load its metadata. If you must use third-party stores, vet the repository source, avoid untrusted or anonymous repositories, and ideally restrict network access to your Runtipi instance from external networks. Patching to 4.10.0+ is the definitive solution.

What files are most at risk of exposure?

Any file readable by the Runtipi container process can be targeted via symlink, but the most dangerous are /data/.env (credentials), /data/state/seed (cryptographic material), and application logs. Attackers will prioritize these, but sophisticated attackers may probe for /etc/passwd, SSH keys, or other system files depending on container configuration.

How can I tell if my Runtipi instance has been exploited?

Review HTTP access logs for suspicious requests to logo endpoints, particularly those originating from IPs you don't recognize or hitting endpoints shortly after you added a new app store. Check if .env or seed files have been accessed unexpectedly (filesystem audit logs or access times). If concerned, rotate all secrets in your deployment and check for unauthorized changes to app configurations or running services.

Is the vulnerability present if I only use official Runtipi app stores?

Runtipi itself must be vulnerable for the symlink resolution to occur, but the attack *requires* a malicious app store to be added. If you only use official Runtipi-curated stores and they are properly vetted, your risk is lower—but you should still patch promptly in case vulnerabilities in official stores are discovered. Patching removes the vulnerability entirely regardless of which stores you use.

This analysis is provided for educational and risk management purposes. Verification of patch status, affected versions, and vendor guidance should be performed independently against official Runtipi releases and documentation. No proof-of-concept exploit code is provided. Organizations should test patches in non-production environments before deployment. This vulnerability page does not constitute legal or compliance advice. Always consult your organization's security policies and incident response procedures. Source: NVD (public-domain), retrieved 2026-07-26. Analysis generated by SEC.co (claude-haiku-4-5).