Fix PDF Upload Errors in Joomla 3.x: PHP Code and No Data

This Joomla technical guide explains how to investigate two confusing Joomla 3.x PDF upload messages: Invalid file: The file contains PHP code and Upload Failed: No data. The errors commonly point to file-validation, PHP, server, temporary-directory, or security-filtering issues, and they do not by themselves establish that a site has been compromised.

PDF uploads can fail at several points between the browser, PHP, Joomla, and server-side security controls. A disciplined test sequence helps administrators isolate the responsible layer without weakening file-upload protections or assuming that an error message represents a confirmed security incident.

What Joomla 3.x PDF upload errors do and do not mean

This guide concerns operational PDF upload failures on Joomla 3.x websites. It does not map either Invalid file: The file contains PHP code or Upload Failed: No data to a specific CVE, National Vulnerability Database record, or CISA Known Exploited Vulnerabilities entry. The available reviewed evidence identifies no CVE or CISA KEV match for these messages.

That distinction matters. A rejected upload can be the expected result of a protective control: Joomla, PHP, a web application firewall (WAF), a hosting-level scanner, or a security extension may inspect the file name, declared type, detected content type, or file contents before accepting it. Equally, a missing upload payload can result from a server limit or an inaccessible temporary directory. Neither symptom alone proves an intrusion, active exploitation, or malicious activity.

The right approach is to preserve the protections that are working, collect evidence from a controlled test, and make one measured change at a time. Exact behaviour can vary with the host, PHP handler, Joomla configuration, installed upload extensions, and custom security rules.

Diagnose the “Invalid file: The file contains PHP code” message

This message indicates that an upload validation or security check has rejected the file because it detected content it considers unsafe or inconsistent with an ordinary PDF. It should be treated as a validation result first, not as proof that the uploaded document or the Joomla site is malicious.

Start with the file itself

Use a known-good, uncomplicated PDF as the baseline test. Prefer a newly exported document from a trusted desktop application, with a short file name and a conventional .pdf extension. Do not use a document that has merely been renamed from another format, and do not attempt to alter a rejected file to defeat validation.

Compare the outcome with the original document. If the clean test PDF succeeds while one particular document fails, the issue is likely file-specific or related to how that document was generated. Ask the document owner to export a fresh PDF from the source application. If every ordinary PDF fails, move on to the Joomla, PHP, and security-control checks below.

Review upload policy and content checks

Check the upload settings that govern the Joomla Media Manager or the extension handling the upload. Confirm that PDF is an intended permitted document type and that the configured file-type policy matches the site’s business needs. If the upload takes place through a form, document library, learning system, or another extension, review that extension’s upload settings as well; it may apply its own rules independently of Joomla’s Media Manager.

Also identify any security extension, host-level malware scanner, reverse proxy, or WAF that evaluates uploads. A rule can reject a legitimate document because of MIME or content inspection, a false positive, or a mismatch between the file’s detected and expected type. Record the time of the failed test, the user account used, the filename, the browser, and the exact error message. Those details make it possible for the hosting provider or security administrator to correlate the event with its logs and rules.

Do not respond by broadly disabling file inspection, allowing executable file types, or relaxing security rules across the site. If a specific control is implicated, have the administrator or provider review the relevant event and make the narrowest safe adjustment supported by the evidence.

Diagnose “Upload Failed: No data” at the PHP and server layer

The phrase Upload Failed: No data generally means Joomla did not receive usable upload data for the request. The browser may have selected a file, yet the request can still be limited, interrupted, discarded, or prevented from reaching the application correctly.

Begin with the size of the test file. PHP upload processing is influenced by several settings, and a limit in any relevant layer can prevent a successful request. The administrator or host should review the effective—not merely configured—values for the following settings:

• upload_max_filesize: the maximum size accepted for an individual uploaded file.
• post_max_size: the maximum size of the full HTTP POST request, which must accommodate the file and accompanying form data.
• max_file_uploads: the number of files PHP permits in one request when multiple uploads are used.
• memory_limit: the memory available to PHP, which can affect processing in some site and extension configurations.
• Execution timeouts: request, PHP, proxy, or web-server time limits that can interrupt slower transfers.
• Temporary directory configuration and permissions: PHP needs an available, writable temporary location while it receives uploaded files.

A hosting dashboard can sometimes display these values, but the values used by the website may differ from a generic PHP information page if the site runs under a separate PHP handler or account. Ask hosting support to confirm the active settings for the site and to check whether the temporary directory is writable and has adequate available space.

Web-server and proxy limits can also be lower than PHP’s limits. If PHP settings appear sufficient but uploads stop at a repeatable size, the hosting provider should inspect the web-server, reverse-proxy, or WAF limits that apply to the request. Avoid guessing which limit is responsible; correlate a controlled upload attempt with server logs.

Use a controlled PDF upload test sequence

A small, repeatable test prevents unrelated changes from obscuring the cause. Perform the tests in a maintenance window where possible, and keep notes of each result. If the site is managed by an agency, share the record with its administrator rather than making broad configuration changes directly on production.

1. Confirm the upload path. Establish whether the PDF is being uploaded through Joomla Media Manager, an extension, or a custom form. Test the same path that users normally use.
2. Try one known-good small PDF. Note whether it succeeds and preserve the exact result.
3. Try the same file with an authorised administrator account. If permissions differ by user group, this can show whether the issue is related to access or the upload environment.
4. Compare a small and a larger legitimate PDF. A size-dependent failure is useful evidence for reviewing PHP, server, proxy, and WAF limits.
5. Check browser and network conditions. Retry with a current browser and a stable connection. If the problem occurs only on one network or device, document that observation before changing the server.
6. Inspect records immediately after the test. Match the test time to Joomla, PHP, web-server, and security-control logs.
7. Change one approved setting or rule at a time. Retest with the same baseline PDF and retain the previous setting so it can be restored if necessary.

This sequence does not attempt to bypass any protection. Its purpose is to produce reliable evidence about where the upload is being rejected or lost.

Check Joomla, extensions, and security controls

Although these errors are not identified here as a vulnerability disclosure, regular maintenance remains part of safe troubleshooting. Confirm that the Joomla 3.x installation is on the latest available Joomla 3.x release for that branch, and ensure that extensions involved in uploads are current. Because Joomla 3.x is a legacy branch, sites that must remain maintainable and supported should also plan a tested migration path to a supported Joomla major version where feasible.

Before updating, take a verified backup and test the update process in a staging environment when the site is business-critical. Include upload-related extensions, templates, security extensions, and integration plugins in the review. An outdated extension may have its own upload workflow or compatibility constraints, so updating Joomla core alone may not resolve the problem.

Review security controls with the same care. Establish which product or layer rejected the document before requesting a rule change. If a WAF or security extension is involved, provide its administrator with the test time, affected URL or feature name, user role, filename, file size, and relevant log entry. A narrowly scoped correction is safer than disabling scanning or opening upload permissions globally.

Confirm that the account performing the upload has only the permissions required for its role. File uploads should remain limited to trusted users and to the document types the site genuinely needs. Maintaining that boundary reduces risk while still allowing legitimate publishing work to continue.

Read the logs before escalating the problem

Logs turn a generic front-end message into a diagnosable event. Review Joomla logs, PHP error logs, web-server error logs, and records from any WAF, hosting scanner, or security extension. Search around the precise time of the controlled upload test rather than looking only for the visible Joomla message.

Useful details to collect include the timestamp and time zone, the Joomla user account, upload feature used, filename, file size, browser, error shown to the user, and whether a small baseline PDF behaved differently. Do not post sensitive logs or documents publicly. Redact personal information, session data, authentication material, and internal paths before sharing material with support.

Escalate to qualified hosting or Joomla administration support when the logs point to a server-level limit, temporary-directory failure, blocked request, or permission problem that you cannot safely change. Provide the controlled-test record rather than a general report that “uploads do not work”; it will shorten diagnosis and reduce unnecessary configuration changes.

When an upload error should trigger a wider security review

Most isolated PDF upload problems are configuration, compatibility, file-generation, or filtering issues. However, persistent and unexplained anomalies should be considered in the context of the rest of the site. A broader review is warranted when upload failures appear alongside unexpected files, unfamiliar administrator accounts, unexplained configuration changes, unusual traffic patterns, or other indicators that cannot be explained through ordinary maintenance.

In that situation, preserve logs and backups, avoid destructive cleanup actions that could remove evidence, and engage a qualified security professional for a site and server assessment. The assessment may include malware scanning and log analysis, but this article does not conclude that these PDF upload messages themselves demonstrate compromise. No specific CVE, NVD entry, or CISA KEV record is associated with the described errors in the reviewed evidence.

A practical remediation checklist

• Test the failing upload path with one known-good, simple PDF.
• Record the exact error, time, user account, file size, browser, and upload feature used.
• Confirm that PDF is permitted by the relevant Joomla or extension upload policy.
• Review active PHP values for upload_max_filesize, post_max_size, max_file_uploads, memory_limit, applicable execution timeouts, and the temporary directory.
• Ask the host to check web-server, proxy, and WAF limits if a size threshold or blocked request is suspected.
• Review Joomla, PHP, server, WAF, and security-extension logs for the matching test time.
• Update Joomla 3.x to the latest available release in its branch, update upload-related extensions, and plan migration to a supported Joomla major version where feasible.
• Keep upload validation and restrictive permissions in place; make only evidence-based, narrowly scoped changes.
• Seek qualified administrative or security assistance if anomalies persist or coincide with other signs of compromise.

A careful baseline test, verified server settings, and matching log evidence will usually reveal whether the problem is a document, policy, PHP, temporary-directory, server-limit, or security-filter issue. That is a more reliable and safer route than treating either message as a confirmed vulnerability or disabling the controls designed to protect the site.