~/blog

When Legacy Meets Risk: Unrestricted File Upload & Default Credentials in QaTraq 6.9.2

October 19, 2025

TL;DR

While performing an internal security review of our infrastructure, I discovered an outdated instance of QaTraq 6.9.2, a test management platform still used by one of our development teams. During analysis, I identified two critical vulnerabilities:

After responsibly validating the issues using a locally built environment, I reached out to the vendor but received no response. The findings were later submitted to MITRE for CVE assignment.


đź“– Background

As part of a periodic internal security assessment, we review non-production systems and development tools deployed across our infrastructure. During one such review, I came across an instance of QaTraq, a test case management tool that had been set up years ago for QA automation experiments.

A quick look revealed that the service was still accessible, though not externally exposed. This triggered a deeper review — primarily to ensure the system wasn’t a forgotten risk vector.


🔍 Discovery Process

The version running was QaTraq 6.9.2, released roughly a decade ago. Given its age and lack of recent updates, my first step was to locate the original source code to understand the underlying implementation.

I managed to find the open-source codebase rebuilt the environment in a Docker container, replicating the original deployment. This allowed me to test vulnerabilities safely and validate any findings in isolation.


🚨 The Vulnerabilities

1. Unrestricted File Upload → Remote Code Execution

Inside the Test Script module, the “Add Attachment” feature allows users to upload files without any restriction on file type or content.

By uploading a server-interpreted file (e.g., a PHP script), the file is stored in the attachments directory and can later be accessed through the “View Attachment” option. Because the server directly executes these files, an attacker with valid credentials could execute arbitrary commands on the host.

Attack Vector (PoC)

  1. Log in → Test Script → Add Attachment
  2. Upload shell.php containing: <?php system($_GET['cmd']); ?>
  3. View Attachment → shell.php?cmd=id

2. Default Credentials — admin:admin

QaTraq 6.9.2 ships with a default administrative account that remains active after installation. No enforcement mechanism exists to change the credentials during setup, meaning anyone with access to the login page can authenticate directly as the administrator.

Attack Vector (PoC)

  1. Visit the web login page
  2. Enter admin / admin → Gain admin dashboard access

đź§  Why This Matters

Legacy applications often get repurposed or left running in internal environments, especially when integrated with automation frameworks. Even when they are not directly exposed to the internet, vulnerabilities like these can:

Interestingly, a quick check on SourceForge shows that QaTraq 6.9.2 continues to receive a significant number of active downloads even this week, highlighting that legacy tools are still in use despite being obsolete and unsupported. This makes understanding and mitigating their risks all the more important.

To mitigate these risks, I advised our team to avoid using outdated applications whenever possible and switch to well-maintained, actively supported tools to reduce inherent security risks. Taking such steps not only lowers the likelihood of security issues but also ensures smoother internal operations.


đź§± Reproduction & Responsible Disclosure

To confirm the findings responsibly, I found the publicly available source code but getting it to run was far from straightforward — multiple dependency mismatches, outdated libraries, and missing configuration files made the setup quite challenging.

After several iterations, I eventually built it. The process that itself highlighted how much legacy software persists unmaintained.

After validating both issues:

  1. I reported the findings to the vendor with detailed PoC and reproduction steps.
  2. Waited for over two months — no response or acknowledgment.
  3. As part of coordinated disclosure, I submitted both issues to MITRE for CVE assignment.

đź§­ Key Takeaways


🗓️ Disclosure Timeline

Date Action
June 30, 2025 Vulnerability identified during internal review
July 18, 2025 Verified in local environment
July 22, 2025 Vendor contacted
October 13, 2025 CVE request submitted to MITRE

The findings have been submitted to MITRE, and I will update this post once the CVE is officially assigned.


đź§© References

  1. QaTraq Project — Archived Source Repository
  2. CVE IDs — (Pending Assignment)

🧵 Thanks for reading! I enjoy exploring how small oversights evolve into real-world risks — and how better design and security practices can prevent them. More AppSec deep dives coming soon.


currently online
made with ♥ by claude.ai