CVE-2024-13567: Awesome Support Information Disclosure Flaw

CVE-2024-13567 Overview

CVE-2024-13567 is a sensitive information exposure vulnerability in the Awesome Support – WordPress HelpDesk & Support Plugin. The flaw affects all plugin versions up to and including 6.3.1. Unauthenticated attackers can extract files stored in the /wp-content/uploads/awesome-support directory, which holds attachments uploaded with support tickets. Because customers often attach screenshots, logs, and account details to support requests, the exposed data can include personally identifiable information, internal documents, and credentials. The vendor classified this as an information disclosure issue [CWE-200] and released a partial patch in version 6.3.1.

Critical Impact
Unauthenticated remote attackers can enumerate and download support ticket attachments containing potentially sensitive customer data directly from the plugin's upload directory.

Affected Products

Awesome Support – WordPress HelpDesk & Support Plugin versions up to and including 6.3.1
WordPress sites running the awesome-support plugin with default upload directory configuration
Any deployment exposing /wp-content/uploads/awesome-support over HTTP/HTTPS

Discovery Timeline

2025-04-01 - CVE-2024-13567 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-13567

Vulnerability Analysis

The Awesome Support plugin stores ticket file attachments in a predictable path under /wp-content/uploads/awesome-support. The directory lacks server-side access controls, allowing direct HTTP requests to retrieve stored files. Because WordPress serves the uploads directory as static content by default, files placed inside this subdirectory inherit public read access unless the site administrator adds explicit web server restrictions.

The plugin's file uploader, implemented in class-file-uploader.php, writes attachments to disk without generating unguessable filenames or placing an authentication gate in front of retrieval. Attackers who can enumerate or guess filenames can fetch ticket attachments without authenticating to WordPress. The issue is categorized as Sensitive Information Exposure under [CWE-200].

Root Cause

The root cause is missing access control on stored file attachments. The plugin relies on filesystem placement inside the public uploads tree rather than serving files through an authenticated PHP handler that verifies the requester has rights to view the underlying ticket.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker issues HTTP GET requests against paths under /wp-content/uploads/awesome-support/ to retrieve attachment files. Combined with directory listing misconfigurations or filename enumeration through other plugin endpoints, an attacker can harvest data at scale. The vulnerability was partially addressed in version 6.3.1 (see WordPress Changeset #3250497 and WordPress Changeset #3262629).

No public proof-of-concept code is required to demonstrate this issue; the vulnerability is exercised through standard HTTP requests against predictable paths. See the Wordfence Vulnerability Report for additional technical context.

Detection Methods for CVE-2024-13567

Indicators of Compromise

HTTP GET requests to URLs containing /wp-content/uploads/awesome-support/ from external IP addresses without prior authenticated session activity
Repeated 200 responses for attachment files originating from a single client over a short time window
Web server access logs showing directory listing requests against the awesome-support upload path
Outbound traffic spikes from the web server delivering attachment payloads to unknown clients

Detection Strategies

Audit web server access logs for any unauthenticated requests reaching the awesome-support uploads directory
Monitor for filename enumeration patterns such as sequential or brute-forced attachment names
Alert on user agents associated with automated scrapers retrieving content from /wp-content/uploads/awesome-support/
Compare requests for attachment files against authenticated session cookies to identify anonymous downloads

Monitoring Recommendations

Enable verbose access logging on the WordPress reverse proxy or web server for the affected path
Forward access logs to a centralized log analytics platform and create dashboards tracking requests to plugin upload directories
Configure file integrity monitoring on /wp-content/uploads/awesome-support to detect unexpected access patterns
Track the plugin version reported by WordPress and alert when sites remain on versions at or below 6.3.1

How to Mitigate CVE-2024-13567

Immediate Actions Required

Update the Awesome Support plugin to the latest available version beyond 6.3.1 that fully addresses the issue
Restrict direct web access to /wp-content/uploads/awesome-support/ via web server configuration
Review existing ticket attachments and rotate any credentials or secrets that may have been exposed
Notify affected users if log analysis confirms unauthorized retrieval of their attachments

Patch Information

The vendor released a partial fix in Awesome Support version 6.3.1. Administrators should apply all subsequent plugin updates, as referenced in WordPress Changeset #3250497 and WordPress Changeset #3262629. Review the WordPress File Uploader Code to validate that the deployed version includes the access control hardening.

Workarounds

Add an .htaccess rule or equivalent Nginx location block denying direct access to the awesome-support uploads directory
Move attachment storage outside the public web root and serve files through an authenticated PHP handler
Randomize attachment filenames with cryptographically strong identifiers to prevent enumeration
Disable file attachments in support tickets if business processes permit, until a full patch is installed

bash

# Apache .htaccess example to block direct access to attachments
# Place in /wp-content/uploads/awesome-support/.htaccess
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
</IfModule>