CVE-2019-8390

qdPM 9.1 has a “search keywords” field that can be tricked into putting attacker-made code into a page. When a visitor opens a link with the malicious search text, the code can run in their browser—like swapping the sign at the store entrance so people are redirected or their browsing session is interfered with.

This matters if your business runs qdpm 9.1 and your users can access the search page/feature that uses the search[keywords] parameter. No login is required for an attacker to craft a malicious input, but a person must view the page for the script to run.

The risk is highest when the search feature is reachable to normal visitors (internet-accessible) and an attacker can get those visitors to open a crafted link.

Verdict: AMBER. Attackers can inject and run code in a visitor’s browser (and public exploits are available), so this is not just theoretical. Prioritize updating qdpm 9.1 to eliminate the vulnerable input handling.

1. Confirm exposure in your environment

   • Identify the qdpm version you run. The finding specifically names qdPM 9.1.
   • Find the search functionality that accepts a keywords parameter. Look for pages/requests that include search[keywords] (or the equivalent in your deployment).
   • Determine whether the search page is reachable by regular visitors (internet-facing) in your default setup.

2. Upgrade using the vendor remediation

   • Use the vendor-provided remediation link: http://qdpm.net/download-qdpm-free-project-management
   • Install the updated qdpm release provided there and ensure it is not 9.1 anymore.
   • If you cannot upgrade immediately, document a short-term compensating plan (see step 3) while you schedule the upgrade.

3. Temporary containment (if you cannot patch right away)

   • Reduce who can reach the vulnerable search page/feature: restrict access to authenticated users or internal networks if your business allows it.
   • If your deployment allows configuration controls for the search endpoint, disable or limit the search feature exposure until patching is complete.

4. Validate the fix

   • After upgrading, revisit the search page and verify that the search keywords input is safely handled.
   • Perform a simple test using harmless, non-destructive text to ensure it displays as text and is not interpreted/executed as script.

5. What to monitor

   • Look for evidence of malicious search links being visited (web server logs around the search endpoint).
   • Watch for unusual client-side behavior reported by users (unexpected popups, login prompts, redirects), especially after the upgrade window.

Severity/impact context: This is a Cross-site Scripting issue (CWE-79) in qdPM 9.1, specifically through the search[keywords] parameter. The mechanism is that attacker-controlled input can be reflected into the page in a way that executes JavaScript in the victim’s browser.

Attack preconditions from findings: no authentication is required for the attacker to craft the malicious input, but user interaction is required (a user must view the crafted page). Reachability in default config is unknown, so exposure depends on whether the search page/parameter is reachable in your deployment.

Exploitation status: public exploit available (2 known). KEV is not listed in CISA KEV for this CVE.

Likelihood note: EPSS is reported as 9.8% with a rising trend, but public KEV confirmation is not present here; the main practical driver for urgency is the existence of public exploits.

Verdict: AMBER (fixing is important, but it’s scoped to the vulnerable search parameter usage pattern and still requires user interaction).