CVE-2014-9147

This is a “backup file exposure” issue. Think of your website like an office—if the safe that holds your files is left in a hallway where anyone can grab it, attackers don’t need to break in; they just request the file directly.

If the database backup file is accessible, attackers may be able to download sensitive information that’s normally meant only for recovery.

This matters if you run or host a public-facing website using Fiyo CMS version 2.0.1.8.

It’s mainly a risk when the .backup/ directory (or backup files inside it) is reachable over the internet, because the problem can be triggered by a direct web request with no login needed.

Treat this as AMBER urgency: there is public exploit code available, which means attackers can automate attempts to find and download backups.

Even though a specific official patch isn’t known, the exposure can often be stopped quickly by removing public access to the backup directory and deleting exposed backup files.

1. Confirm you’re affected

   • Verify the CMS software and exact version number on the site.
   • If you have multiple environments, check production and any publicly reachable staging/test sites.

2. Check whether backup files are reachable

   • From a controlled admin machine, attempt to access the backup directory path(s) in the same way an outside visitor would (i.e., via a normal browser/HTTP request).
   • Document whether you can download any file under .backup/ (or whether the server blocks it).

3. Immediate mitigation if backups are public

   • Block access to the .backup/ directory at the web server and/or reverse proxy/firewall level.
   • Ensure the backup directory is not publicly served and that directory listings are disabled.
   • Remove exposed backup files from the web root (or ensure backups are stored outside the publicly accessible folder).

4. Longer-term remediation

   • Since no fixed version/patch information is available from the findings, prioritize moving off the vulnerable version or obtaining guidance from the vendor/support channel.
   • Rebuild/rotate backups after you’ve secured storage locations.

5. What to monitor

   • Check web access logs for repeated requests to .backup/ or backup-like filenames.
   • Look for unusual download spikes or high rates of 200/206 responses tied to backup endpoints.

6. Communication

   • If logs show downloads occurred, treat it as a potential data exposure event and coordinate with your legal/IT/privacy responsibilities for notification and risk assessment.

Severity is high (reported CVSS 7.5) with a primary impact of confidentiality loss (sensitive information exposure) and no stated impact to availability. The weakness is consistent with CWE-200 (information exposure through directory contents or accessible backup artifacts).

Attack mechanism: a remote, unauthenticated attacker can issue direct HTTP requests to the database backup location under .backup/ and retrieve the backup file(s) if they are publicly reachable.

Exploitation status: public exploit code exists (two known). KEV listing is not present in CISA KEV, and there is no vendor patch/fixed version information available in the findings.

EPSS is provided as a prediction only and is not used as proof of real-world exploitation here.