Description

The Prevent Direct Access – Protect WordPress Files plugin for WordPress is vulnerable to unauthorized access of protected files due to insufficient token validation in the `get_advance_file_by_url()` method in all versions up to, and including, 2.8.8.8 The method uses a SQL `LIKE` operator for token lookup without escaping wildcard characters via `$wpdb->esc_like()`. This makes it possible for unauthenticated attackers to bypass the private token requirement by supplying SQL wildcard characters (such as `%`) as the token value, matching any record in the plugin's file table and downloading any protected file.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-13T06:17:38.353Z",
  "pubdate": "2026-08-13T06:17:38.353Z",
  "executiveSummary": "The Prevent Direct Access – Protect WordPress Files plugin for WordPress is susceptible to an unauthorized access vulnerability affecting all versions up to and including 2.8.8.8. The flaw stems from insufficient token validation and improper handling of user-supplied input within the file protection mechanism. Specifically, the vulnerability allows unauthenticated remote attackers to bypass private token requirements by injecting SQL wildcard characters into the token parameter. Successful exploitation of this security defect grants unauthorized users the ability to download arbitrary protected files managed by the plugin, leading to a complete compromise of confidentiality regarding restricted assets. The risk implications are severe, as sensitive documents, media, or proprietary data intended to be hidden from public access can be systematically enumerated and retrieved without any prior authentication or special privileges. Remediation requires updating the plugin to a patched version where input sanitization and proper query construction are enforced.",
  "technicalDetails": "The vulnerability resides in the `get_advance_file_by_url()` method implemented within the Prevent Direct Access – Protect WordPress Files plugin, affecting all software versions up to and including 2.8.8.8. The root cause of the vulnerability is the improper neutralization of special elements used in an SQL command, specifically the omission of the `$wpdb->esc_like()` sanitization function when executing database queries involving user-supplied token values.\nDuring the file retrieval request lifecycle, the vulnerable method performs a database lookup to validate the private token associated with a protected file. Instead of performing a strict cryptographic or exact string comparison, the underlying implementation utilizes a SQL `LIKE` operator to query the plugin's internal file table. Because the input parameter is concatenated or passed directly into the `LIKE` clause without escaping SQL wildcard characters, an attacker can manipulate the query logic by supplying arbitrary wildcard characters, most notably the percent sign (`%`).\nThe attack flow proceeds as follows: an unauthenticated network attacker targets a protected file URL managed by the plugin. Instead of providing a valid, cryptographically secure private token, the attacker submits a payload consisting of SQL wildcard characters such as `%` as the token value via the request parameter. When the `get_advance_file_by_url()` method processes this input, the unescaped wildcard matches the first available record—or an arbitrary record depending on table ordering—within the plugin's file table due to the loose matching behavior of the `LIKE` operator.\nUpon successfully matching a database record, the access control check incorrectly evaluates the token as valid. Consequently, the application bypasses the intended security restriction, grants authorization, and serves the protected file to the unauthenticated user. This requires no prior authentication, specific user privileges, or interactive user sessions, exposing the affected WordPress deployment to unauthorized data exfiltration over standard network protocols. Post-exploitation impact includes the potential exposure of sensitive or restricted files stored within the protected directories of the WordPress installation."
}