A key sign is reliance on Office versions that still support the vulnerable path, combined with users who can open documents from untrusted sources. If the MSDT URL protocol remains enabled, and security teams have not validated Microsoft’s workaround, exposure is still present. The risk is highest when document controls are assumed to stop execution without testing.
How to recognise Follina-style exposure in an environment
Follina-style exposure is not just “having Office installed”, it is a combination of product version, protocol handling, and document trust assumptions. The clearest sign is that users can still open externally sourced documents in a way that can trigger a remote template or protocol-based execution path, especially when MSDT handling has not been disabled or validated by security testing.
Another strong indicator is a gap between policy and reality, where teams assume document filters, email scanning, or macro settings are enough to stop weaponised files without actually confirming the vulnerable execution path is blocked. That gap matters because this class of issue often survives normal document security controls.
Exposure usually shows up as an environment where legacy Office behaviour, permissive document handling, and untrusted inbound files overlap. If those three conditions coexist, treat the environment as potentially reachable rather than merely “patched in theory”.
Which conditions make the exposure materially worse?
The highest-risk environments are the ones with broad document intake, weak application control, and incomplete validation of Microsoft’s workaround. A workstation estate may look hardened on paper, but if users routinely open attachments or downloaded documents from outside the business, the attack surface stays open.
When organisations allow protocol handlers, remote content retrieval, or legacy Office components to remain enabled, the document becomes a launch point rather than a static file. That is why the practical question is not whether documents are blocked in general, but whether the exact triggering path has been tested end to end.
If you want a concrete exposure signal, look for inconsistencies between standard desktop policy and actual execution behaviour. A file that looks harmless in review but can still initiate a suspicious child process, network retrieval, or Office-to-script transition is a sign that the control boundary is weaker than assumed.
What evidence helps confirm exposure before an incident occurs?
Start with version and configuration evidence, then test the user path. Confirm which Office builds are deployed, whether MSDT-related behaviour is disabled, and whether security teams have validated the workaround in the actual desktop image rather than relying on a vendor statement alone.
Then look at delivery and user exposure. If inbound email, collaboration platforms, or web downloads regularly deliver documents from outside trusted business channels, those files should be treated as plausible delivery vectors until tested. For exploitability context, the current advisory and exploitation record should be tracked through NIST National Vulnerability Database and prioritised using FIRST EPSS rather than waiting for local confirmation.
For organisations that need a strong operational signal, compare your exposure list against CISA Known Exploited Vulnerabilities Catalog and verify whether the vulnerable execution path is still reachable in your desktop population. If it is, document it as active exposure, not theoretical risk.
Risk and Threat Considerations
Follina-style issues are dangerous because they collapse the boundary between a document and code execution. If the vulnerable path remains reachable, an attacker only needs a user to open a crafted file, then the document content can be used to reach a secondary payload or command execution step.
Failure mechanism: The attack succeeds when document trust controls, protocol handling, or application defaults still allow the vulnerable Office path to resolve and execute attacker-influenced content.
Impact: Successful exploitation can lead to remote code execution, follow-on payload delivery, and rapid compromise of the user endpoint, especially where documents are treated as inherently safe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Document exploitation is a malicious-code delivery path that needs preventive controls. |
| CM-7 — Least Functionality | Disabling MSDT-style attack paths is a least-functionality control decision. | |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure depends on confirming whether the vulnerable path still exists in deployed builds. | |
| Recommendation — Block or detonate suspicious documents and enforce protections against exploit payloads. Remove or disable unnecessary protocol handlers and execution paths. Continuously check deployed Office versions and exposure status against known vulnerabilities. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Document exploits are malware-delivery vectors that require endpoint and content defenses. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardening Office and disabling risky handlers is a secure-configuration task. | |
| Recommendation — Use layered malware defenses to inspect and contain malicious documents. Harden Office settings and remove risky document execution features. | ||
Practitioner Guidance
What to verify: Do not rely on generic macro or attachment controls as proof of safety. Verify the specific Office build, the MSDT-related setting, and the real behaviour of a test document in a controlled environment before closing the issue.
Decision rule: If users can still open untrusted documents and the triggering path has not been explicitly disabled and tested, treat the endpoint estate as exposed and prioritise remediation over further policy review.
What good looks like: The vulnerable path is removed or proven unreachable, the user journey is tested with realistic documents, and the organisation can show evidence that document handling no longer depends on assumptions about how Office will behave.
Practitioner takeaway: Exposure here is defined by reachable execution, not by the presence of a policy statement, so the only meaningful assurance is an end-to-end test of the exact document path attackers would use.
