Improper restriction of XML external entity reference vulnerability in TÜBİTAK BİLGEM Software Technologies Research Institute İmzager allows Serialized Data External Linking.
This issue affects İmzager: from 2.10.5 before 2.10.7.
Quest Foglight for Databases getSource XML External Entity Processing Information Disclosure Vulnerability. This vulnerability allows remote attackers to initiate arbitrary server-side requests on affected installations of Quest Foglight for Databases. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the getSource method. Due to the improper restriction of XML External Entity (XXE) references, a crafted document specifying a URI causes the XML parser to access the URI and embed the contents back into the XML document for further processing. An attacker can leverage this vulnerability to disclose information in the context of the application. Was ZDI-CAN-29934.
Quest Foglight for Databases AbstractParser XML External Entity Processing Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Quest Foglight for Databases. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the AbstractParser class. Due to the improper restriction of XML External Entity (XXE) references, a crafted document specifying a URI causes the XML parser to access the URI and embed the contents back into the XML document for further processing. An attacker can leverage this vulnerability to disclose information in the context of SYSTEM. Was ZDI-CAN-28929.
MailEnable parseObjectResponse XML External Entity Processing Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of MailEnable. Authentication is required to exploit this vulnerability.
The specific flaw exists within the implementation of the parseObjectResponse method. The issue results from the lack of proper restriction of XML External Entity (XXE) references. An attacker can leverage this vulnerability to disclose information in the context of the service account. Was ZDI-CAN-29137.
Copernik XML Factory versions prior to 0.1.2 have an XML External Entity (XXE) vulnerability due to improper restriction of XML External Entity references when XInclude is enabled. This allows an attacker to cause the application to resolve attacker-controlled xi:include references, potentially disclosing local files or making server-side requests to internal network endpoints. The vulnerability affects the stock JDK XML provider when Apache Xerces is not present and requires explicit enabling of XInclude processing on the XML factory or reader. The issue is fixed in version 0.1.2.
Szafir and Szafir Weryfikująca are vulnerable to XML External Entity (XXE) injection. When a user signs or verify a crafted XML file containing a `DOCTYPE` with an external DTD reference, the parser processes external entities, allowing an attacker to read arbitrary files from the victim's filesystem.
This issue was fixed in Szafir version 2.0 build 708. Szafir Weryfikująca is no longer supported (End of Life) and has not been fixed.
CVE-2026-66090 is a high-severity vulnerability in Apereo Foundation's openEQUELLA prior to version 2026.1. The XML parser used for item metadata does not disable external entity resolution, allowing users with item creation permissions to submit crafted XML. This can lead to the server reading arbitrary files accessible to the service or making server-side requests to attacker-controlled locations, including cloud metadata services.
CVE-2026-66089 is a vulnerability in Apereo Foundation's openEQUELLA prior to version 2026.1. The SOAP API's stopEdit operation uses an XML parser that resolves external entities, enabling attackers to read arbitrary files accessible to the service or perform server-side request forgery (SSRF). This flaw is fixed in version 2026.1.
In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, an XML external entity reference vulnerability in SVG image processing allows an unauthenticated attacker to read local files on the server via a crafted SVG image with a nested embedded SVG, when the image is processed or exported to PDF.
CVE-2026-112198 is an XML External Entity (XXE) injection vulnerability in the SAFT import feature of the Tactis NoviGest Desktop App. The vulnerability arises because the application uses a JAXB Unmarshaller to process user-supplied XML files without disabling external entity resolution. This flaw allows an attacker with access to the import functionality to craft malicious XML files that can read local files accessible to the application process. If the application runs with elevated privileges, this could lead to exposure of sensitive system files.
CVE-2026-90885 is an XML External Entity (XXE) vulnerability in the Apache Camel Saxon component affecting versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.2. The vulnerability arises because the default Saxon Configuration used by XQueryBuilder accepts DOCTYPE declarations and resolves external entities when the message body is already a javax.xml.transform.Source, allowing external entity expansion. This can lead to unauthorized reading of files accessible to the Camel process and issuing network requests to arbitrary hosts. The issue is fixed in Apache Camel versions 4.18.5 and 4.22.2 and later.
CVE-2026-18061 is an XML External Entity (XXE) vulnerability in the AWS Advanced JDBC Wrapper's optional RemoteQueryCachePlugin. This plugin, when enabled with a shared cache, allows an attacker with write access to insert malicious XML into cached column values. When the application reads these cached results as XML, external entities are resolved, potentially exposing sensitive files accessible to the application process, including database and IAM role credentials. The vulnerability affects versions from 3.3.0 through 4.2.0 and is fixed in version 4.3.0. The plugin is not enabled by default. Mitigation includes disabling the plugin or restricting write access to the shared cache.
Kitodo.Production versions prior to 3.9.2 contain an XML External Entity (XXE) vulnerability in XML parsing helpers used during EAD/XML file import. Authenticated users uploading crafted XML files can exploit this to perform local file disclosure and outbound SSRF from the server. The issue is fixed in version 3.9.2.
CVE-2026-108357 is a high-severity vulnerability in PHPOffice PhpSpreadsheet affecting versions from 3.3.0 up to but not including 3.10.8 and from 4.0.0 up to but not including 5.10.0. It involves improper restriction of XML External Entity (XXE) references due to how the library processes SpreadsheetML XML with double-encoded less-than characters, allowing an attacker to bypass entity checks. This can lead to denial of service via entity expansion and potentially local file access or server-side request forgery (SSRF) on PHP versions before 8.0 or when LIBXML_NOENT is enabled. The issue is fixed in versions 3.10.8 and 5.10.0.
PhpSpreadsheet versions prior to 1.30.7, 2.1.19, 2.4.8, 3.10.8, and 5.10.0 contain an XML External Entity (XXE) vulnerability due to improper restriction of XML external entity references. The XmlScanner::scan method fails to detect certain escape sequences in XLSX XML parts, allowing attackers to craft malicious XLSX files that can trigger entity expansion denial of service, local file access, or server-side request forgery (SSRF) on affected PHP versions. This vulnerability is fixed in the specified versions.
CVE-2026-113582 is a high-severity vulnerability in Apache Abdera, a retired and unsupported project. The flaw involves improper restriction of XML external entity (XXE) references, which can allow attackers to access sensitive data or make server-side requests when parsing attacker-controlled XML. Since Apache Abdera is no longer maintained, no official fix will be released. Users are advised to migrate to supported alternatives or ensure that untrusted XML does not reach the vulnerable parser. Downstream products embedding Abdera may also be affected.
In Eclipse OpenJ9 versions up to 0.63, opening a supplied diagnostic dump bundle with the jdmpview tool, or equivalent DTFJ code, may cause the analyst's machine to read an arbitrary local file named inside the bundle and send its contents to an arbitrary remote host.
FopProducer transforms the incoming XSL-FO message body by creating a javax.xml.transform.TransformerFactory through TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING before running an identity transform over the body. On the JDK's built-in transformer, that feature alone already empties the accessExternalDTD and accessExternalStylesheet limits, so an external DTD or entity is refused. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, for example because the application also uses camel-xslt-saxon or camel-saxon, TransformerFactory.newInstance() returns that implementation instead, and FEATURE_SECURE_PROCESSING on its own does not restrict external resource access on it. A DOCTYPE with an external subset, or an external general entity, declared in the XSL-FO document is then resolved and expanded while the body is transformed. An external sender whose XSL-FO reaches a fop producer could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. camel-fop does not bring such a factory itself, and excludes Xalan, so a default deployment using the JDK transformer is not affected; the issue is reachable only where another component has placed an alternative JAXP TransformerFactory on the classpath. Releases on the 4.14.x line and earlier reached end of life before this issue was resolved and do not receive a fix.
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel.
This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1.
Improper Restriction of XML External Entity Reference in the Smooks component (camel-smooks) in Apache Camel allows an attacker who supplies the XML message body to read local files or issue requests to internal network locations via an external entity declaration in that body. This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1. The Smooks data format (.unmarshal().smooks(...)) and the Smooks component (smooks:) parse the incoming XML body with the reader Smooks resolves by default, which is the Woodstox SAX parser. That reader resolves external general and parameter entities and loads external DTDs, and camel-smooks applied none of the parser hardening that the other Camel XML components apply. A DOCTYPE with an external subset, or an external general entity, declared in the XML document is therefore resolved and expanded while the body is unmarshalled, and the resolved content is bound into the unmarshalled result and returned on InOut routes. An external sender whose XML reaches a camel-smooks data format or endpoint could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since resolving external entities was the default behaviour. Configurations that declare their own reader - EDI, CSV, JSON, or a custom reader - do not use the XML reader and are not affected. Users are recommended to upgrade to version 4.18.5, 4.22.1 or 4.23.0, which fixes the issue.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders.
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel XPath component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
With documentType set to InputSource, XPathBuilder handed the payload straight to javax.xml.xpath, which builds a DocumentBuilder of its own using the JDK defaults. The hardening applied to Camel's default document type was therefore bypassed: a DOCTYPE declaration that is refused on the default type was accepted here, and the external entity it declared was resolved and expanded into the evaluated document. An external sender whose XML reaches such an expression could read files readable by the Camel process and cause the process to issue requests to hosts it names. The two document types disagreeing on parser configuration is what made this reachable, since a deployment choosing InputSource for streaming reasons had no indication it was also choosing a weaker parser.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type's documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design. For deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE.