Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact It impacts applications where: - the PHP daemon run with root permissions ; - the application is either running outside a container or has sensitive file access ; It could happens with this kind of workflows: Patches A list a schema with http and https by default is used to validate the remote path by default. Workarounds Developers should ensure usage cannot allow (in any case) a user to pass a free input directly to the Snappy library. Instead developers can list available available stylesheets and pick the right one with the user input. References Read more about SSRF at owasp.org/www-community/attacks/ServerSideRequestForgery
Recommended action: Upgrade to 1.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Issue On March 17th the vulnerability CVE-2023-28115 was disclosed, allowing an attacker to gain remote code execution through PHAR deserialization. To fix this issue, the version 1.4.2 was released with an additional check in the affected function to prevent the usage of the phar:// wrapper. However, because PHP wrappers are case-insensitive and the patch only checks the presence of the phar:// string, it can be bypassed to achieve remote code execution again using a different case. As for the initial vulnerability, PHP 7 or below is required for a successful exploitation using the deserialization of PHP archives metadata via the phar:// wrapper. Technical details Description The following patch was committed on the 1.4.2 release to fix CVE-2023-28115. If the user is able to control the second parameter of the generateFromHtml() function of Snappy, it will then be passed as the $filename parameter in the prepareOutput() function. In the original vulnerability, a file name with a…
Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
snappy is vulnerable to PHAR deserialization due to a lack of checking on the protocol before passing it into the fileexists() function. If an attacker can upload files of any type to the server he can pass in the phar:// protocol to unserialize the uploaded file and instantiate arbitrary PHP objects. This can lead to remote code execution especially when snappy is used with frameworks with documented POP chains like Laravel/Symfony vulnerable developer code. If user can control the output file from the generateFromHtml() function, it will invoke deserialization. Proof of Concept Install Snappy via composer require knplabs/knp-snappy. After that, under snappy directory, create an index.php file with this vulnerable code. As an attacker, we going to generate the malicious phar using this script. Then run these command to generate the file Then execute index.php with php index.php. You will see a file named pwned will be created. Noted that attacker can upload a file with…
Recommended action: Upgrade to 1.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.