CVE-2026-62278: LubeLogger Path Traversal Vulnerability

CVE-2026-62278 Overview

LubeLogger, a self-hosted open-source vehicle maintenance and fuel mileage tracker, contains a path traversal vulnerability [CWE-22] in versions prior to 1.6.8. Authenticated non-administrative users can reach the HandleTranslationFileUpload endpoint and influence the file name passed from Controllers/FilesController.cs to RenameFile in Helper/FileHelper.cs. The RenameFile function constructs newFilePath using string replacement and moves the uploaded file without verifying that the resolved absolute path remains under the web root or data directory. A crafted upload name can place or overwrite files outside the intended storage directory with the privileges of the application process.

Critical Impact
Authenticated users can write files outside the intended storage directory, enabling overwrite of application assets or placement of attacker-controlled content on the host.

Affected Products

LubeLogger versions prior to 1.6.8
Controllers/FilesController.cs — HandleTranslationFileUpload endpoint
Helper/FileHelper.cs — RenameFile function

Discovery Timeline

2026-09-18 - CVE-2026-62278 published to the National Vulnerability Database (NVD)
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-62278

Vulnerability Analysis

The flaw resides in LubeLogger's translation file upload workflow. When an authenticated user uploads a translation file, HandleTranslationFileUpload in Controllers/FilesController.cs accepts a user-controlled name and passes it to RenameFile in Helper/FileHelper.cs. RenameFile builds the destination path by applying a naive string replacement on the original file name segment. The function then calls File.Move without validating that the resulting absolute path resides under the web root or the data directory.

Because the endpoint lacked an administrative role check, any authenticated account could reach it. Combined with the missing path containment check, a crafted newName value containing traversal sequences allowed the resulting newFilePath to escape the intended directory. The impact scales with the privileges of the application process, allowing overwrite of configuration, static assets, or executable content served by the application.

Root Cause

Two defects combine to create the issue: an authorization gap on HandleTranslationFileUpload, and unsafe path construction in RenameFile. The fix in 1.6.8 restricts the endpoint to root users and resolves the absolute path, rejecting any destination not rooted under _webEnv.WebRootPath or the data directory.

Attack Vector

An authenticated non-administrative user submits a translation file upload with a crafted name. The name is used to construct a destination path that resolves outside the intended storage directory. The application then moves the uploaded file to that arbitrary location.

text

// Patch: Controllers/FilesController.cs — add role restriction
             var fileName = UploadFile(file);
             return Json(fileName);
         }
-
+        [Authorize(Roles = nameof(UserData.IsRootUser))]
         [HttpPost]
         public IActionResult HandleTranslationFileUpload(IFormFile file)
         {

// Patch: Helper/FileHelper.cs — verify resolved path stays within allowed roots
                 {
                     var originalFileName = Path.GetFileNameWithoutExtension(fullFilePath);
                     var newFilePath = fullFilePath.Replace(originalFileName, newName);
+                    //security: check for path traversal exploit
+                    string absoluteFilePath = Path.GetFullPath(newFilePath);
+                    string dataPath = Path.Combine(_webEnv.ContentRootPath, "data");
+                    if (!absoluteFilePath.StartsWith(_webEnv.WebRootPath) && !absoluteFilePath.StartsWith(dataPath))
+                    {
+                        return false;
+                    }
                     File.Move(fullFilePath, newFilePath);
                     return true;
                 }
// Source: [GitHub Commit c8d5888](https://github.com/hargata/lubelog/commit/c8d5888ebc69e6a163e33f36200233ec845e5c57)

Detection Methods for CVE-2026-62278

Indicators of Compromise

Unexpected files under LubeLogger's wwwroot or data directories with recent modification timestamps that do not match a deployment event.
HTTP POST requests to the translation upload endpoint from non-administrative user sessions.
Uploaded file names containing traversal sequences such as ..\, ../, or absolute path fragments.
Overwrites of existing static assets, language files, or configuration files served by the LubeLogger application process.

Detection Strategies

Enable request logging on the LubeLogger reverse proxy and alert on requests to the translation file upload path from accounts lacking the root role.
File integrity monitoring on the LubeLogger wwwroot and data directories to identify writes outside of expected deployment windows.
Correlate authentication logs with file system change events to attribute suspicious writes to specific user sessions.

Monitoring Recommendations

Baseline the set of files managed by the LubeLogger process and alert on new files appearing outside wwwroot and data.
Monitor the application process user account for writes to unexpected locations on the host.
Track LubeLogger version strings across deployments to confirm 1.6.8 or later is in use.

How to Mitigate CVE-2026-62278

Immediate Actions Required

Upgrade LubeLogger to version 1.6.8 or later, which adds the root role check and absolute path validation.
Audit existing LubeLogger user accounts and remove or disable unused non-administrative accounts.
Review LubeLogger wwwroot and data directories for unexpected or modified files prior to the upgrade.

Patch Information

The fix is available in GitHub Release v1.6.8. Technical details are documented in GitHub Security Advisory GHSA-qm5x-mmwx-q7rm, GitHub Pull Request #1395, and GitHub Commit c8d5888. Related discussion appears in GitHub Issue #1398.

Workarounds

Restrict network access to the LubeLogger instance to trusted users only while the upgrade is scheduled.
Run the LubeLogger process under a low-privilege account with write access limited to the required directories.
Place the LubeLogger deployment on a read-only file system for all paths except wwwroot and data where feasible.

bash

# Verify installed LubeLogger version and confirm remediation
docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.version" }}' lubelogger

# Example: pull the fixed release
docker pull ghcr.io/hargata/lubelogger:1.6.8