XML is still everywhere in healthcare software: legacy integrations, device gateways, cloud portals, SOAP services, configuration files, and document-like formats. That matters because a weakly configured XML parser can turn “data in” into “file read,” “internal network access,” or “service outage.” That class of issue is called an XXE attack (XML External Entity).
What is an XXE attack?
An XXE attack happens when an application parses XML input that includes a reference to an external entity (for example, a local file path or a URL), and the XML parser is configured in a way that allows it to fetch and expand that entity. OWASP and PortSwigger both summarize the common impacts: file disclosure, server-side request forgery (SSRF), and denial of service (DoS) (OWASP XXE Prevention Cheat Sheet, PortSwigger: XXE injection).
If exploited, attackers may be able to:
- Read sensitive files from the server (keys, configs, credentials)
- Trigger SSRF to reach internal services and metadata endpoints
- Cause DoS through parser overload and entity expansion
- Pivot from a “simple” parser bug into broader infrastructure compromise
How XXE works (in plain language)
XML supports a feature called a Document Type Definition (DTD). DTDs can define entities. If a parser is allowed to resolve external entities, it may load data from outside the XML document (files, URLs) and insert it during parsing. The application thinks it’s doing normal XML processing—but it may be doing attacker-directed I/O instead.
A realistic XXE scenario in MedTech
A common pattern: a cloud portal accepts an XML-based import (device profile, integration payload, batch job input) or a legacy SOAP message from a partner system. If the parser is allowed to resolve external entities, a malicious payload can turn that routine “data processing” step into unintended file access or outbound requests from inside your environment—right where internal APIs and secrets tend to live.
Where XXE shows up in medical device ecosystems
In MedTech, the XML parser isn’t always “in the device.” Often it lives in the surrounding ecosystem:
- Cloud portals that accept XML-based payloads from devices, apps, or third parties
- Integration services (SOAP/XML gateways) that translate messages to/from internal APIs
- File upload pipelines that process XML-based formats (for example, SVG images or XML exports)
- Provisioning and update services that read XML configuration templates
- Support tooling that parses XML logs, exports, or diagnostic bundles
The practical risk: if the vulnerable parser has network reach into “trusted” zones (internal APIs, update infrastructure, identity systems), XXE can become a stepping stone to a much bigger incident.
Practical impact: what can go wrong
1) Sensitive data exposure
If the parser can read local files, attackers may extract configuration secrets, database credentials, API tokens, or private keys. That can quickly turn into unauthorized access elsewhere.
2) SSRF and internal discovery
With XXE-driven SSRF, attackers can make the server call internal endpoints that aren’t exposed publicly. That’s especially dangerous in environments where “internal” implicitly means “trusted.”
3) Service disruption
Some XXE patterns can exhaust memory/CPU and create outages. In healthcare contexts, downtime is not just an IT inconvenience—it can become an operational continuity and patient safety concern.
How to find XXE risk before attackers do
Start with two questions:
- Where do we parse XML? Include “hidden” places like uploads, middleware, and integration components.
- Do we need DTDs/external entities at all? Most systems don’t. If you don’t need them, disabling them is usually the cleanest fix.
Then validate with security activities that produce evidence (not opinions):
- Threat modeling to map data flows and identify parser entry points (Medical Device Threat Modeling Services)
- SAST to catch risky parser configurations and XML-handling code paths (Medical Device SAST Services)
- Penetration testing to confirm exploitability in the running system (FDA-Compliant Vulnerability & Penetration Testing)
How to prevent XXE attacks (controls that actually work)
Most XXE vulnerabilities exist because XML libraries support dangerous features by default that your application doesn’t need. Prevention is usually straightforward if you’re deliberate.
- Disable DTDs and external entity resolution unless there is a validated business need (use OWASP as your baseline: XXE Prevention Cheat Sheet).
- Disable external resource inclusion features (for example, XInclude) if they’re not required.
- Enforce secure parser defaults in shared libraries/components (don’t rely on every team to “remember” a checklist).
- Validate inputs (schema validation can help, but treat it as a supporting control—not your primary defense).
- Constrain outbound network access from services that parse XML (reduces SSRF blast radius).
- Run parsing services with least privilege (reduces what “file read” can access).
- Patch and track third-party components so you can respond fast when parser CVEs appear.
That last point is where many teams stumble. If you can’t quickly answer “where is this XML library used?”, you’ll be slower than the threat. An operational SBOM helps you close that gap (FDA-Compliant SBOM Services for MedTech).
How this supports FDA-aligned evidence (premarket + postmarket)
Regulators don’t want magic—they want a defensible process and proof you executed it. FDA’s current premarket cybersecurity guidance emphasizes secure development, verification evidence, and documentation that supports efficient review (FDA: Cybersecurity in Medical Devices (Premarket + QMS Considerations)). (This is general information, not legal advice.)
For issues like XXE, strong submissions and audit-ready programs typically show:
- Secure design decisions (for example, “external entities disabled by default”) traced to requirements
- Architecture views and trust boundaries showing where XML is processed
- Verification evidence (SAST outputs, security test results, pen test outcomes)
- A postmarket plan for vulnerability intake, triage, remediation, and communication
If you need help building the package end-to-end (documentation + testing), start here:
Preventing repeat vulnerabilities: make it a lifecycle control
XXE isn’t just a “bug fix.” The durable win is making secure parsing a standard engineering control: secure defaults, coding standards, automated checks, and regression testing. Many manufacturers map these practices to secure development frameworks like NIST’s SSDF (NIST SP 800-218 (SSDF)), then connect them to product risk management (for example, ISO 14971) and secure development expectations (for example, IEC 81001-5-1) so the evidence is consistent across premarket and postmarket activities.
Key takeaways
- XXE is often a configuration problem as much as a coding problem.
- Most systems don’t need DTDs/external entities—disable them by default.
- In MedTech, XXE frequently lives in portals and integrations, not just “the device.”
- Prove it with evidence: threat model → secure defaults → SAST/pen test → postmarket response.
FAQs
Is XXE still a real risk today?
Yes. XML remains common in integrations and file formats, and many parsers still support risky features unless explicitly disabled. XXE often persists because “hidden XML” shows up in uploads and middleware.
What’s the difference between XXE and SSRF?
XXE is the vulnerability (unsafe XML parsing). SSRF is one possible impact (the attacker makes the server call internal or external URLs). XXE can be used as a path to SSRF when external entities can reference URLs.
Where should I look for XXE exposure?
Anywhere XML is parsed: SOAP services, integration gateways, “format-tolerant” endpoints, upload processors (for example, SVG), configuration import/export features, and diagnostic tooling.
Is input validation enough to stop XXE?
Usually not. Validation can reduce risk, but the most reliable fix is disabling external entity resolution (and similar features) at the parser level, then validating input as a secondary control.
Will a WAF solve XXE?
A WAF can help catch known payloads, but it should not be your primary control. Parser hardening and secure defaults are far more dependable—and they travel with the product across environments.
How do I keep XXE from coming back?
Standardize secure XML parsing via shared libraries and secure defaults, add CI checks and SAST rules, run security regression tests, and maintain SBOM-driven component tracking so you can respond quickly when parser CVEs appear.
Ready to reduce XXE risk in your product?
If you want a clear, regulator-ready path (threat model, testing evidence, and lifecycle controls), we can help.