Publish GHSA-m8xx-3x29-84h8

Author: advisory-database[bot]

advisories/github-reviewed/2026/06/GHSA-m8xx-3x29-84h8/GHSA-m8xx-3x29-84h8.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-m8xx-3x29-84h8",
-  "modified": "2026-06-03T20:25:50Z",
+  "modified": "2026-06-03T20:29:20Z",
   "published": "2026-06-03T20:25:50Z",
   "aliases": [
     "CVE-2022-31114"
   ],
   "summary": "backpack/crud is vulnerable to Cross-Site Scripting (XSS)",
-  "details": "### Impact\n\nIt’s a “*moderate*” vulnerability… but being an admin panel, we take this seriously. It’s difficult… but an attacker could conduct a targeted phishing campaign, in order to **trick your users or admins to click a malicious link, which under very specific circumstances could give them information... or even admin access**. It’s *unlikely*, but that’s not good enough in admin panels - we should make it *impossible*. That’s why we’re bothering you with this. \n\n### Patches\n\n\nIf you don’t have custom error views, the views provided by Backpack would output the exception message *without escaping it*, which made an attack possible using Reflected XSS, in some very specific circumstances (that we will not disclose). **To fix those error views in Backpack 4.x and 5.x, please run**:\n\n```bash\ncomposer update backpack/crud\nphp artisan backpack:fix\n```\n\nThe problem has been patched in:\n- v4.0.63\n- v4.1.69\n- v5.0.13\n\n> **IMPORTANT! Running a `composer update` should get you the patched version, but you also need to run `php artisan backpack:fix` afterwards, to patch your published error views, if necessary.**\n\n### Workarounds\n\nAlternatively (if you don’t want to run `composer update`), you can manually look inside your error views in “*resources/views/errors*” and output `e($exception->getMessage())` instead of `$exception->getMessage()`. That’s all there is to the fix, really.\n\n### What we've done about this\n\nWe’ve acted as soon as our team found it (last week of March 2022):\n- We’ve pushed patches to 5.x, 4.1 and 4.0;\n- We’ve made it easy to apply the fix to existing projects, using a new `php artisan backpack:fix` command;\n- We’ve kept the specific circumstances a secret; as far as we know, only our team knows about the niche case where this exploit is possible;\n- We’ve emailed all our licensed users, to have a chance to fix their projects before it’s public;\n- We've sent an email blast to our 25.000+ strong Security Newsletter;\n- We've made this public with a blog post and soon a CVE, after our community has had a reasonable chance to fix their projects;\n- We will continue to monitor this and remind paying users to apply this fix if they haven’t;\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [backpack/crud](https://github.com/laravel-backpack/crud)\n* Email us at [hello@backpackforlaravel.com](mailto:hello@backpackforlaravel.com)\n\n---\n\nPS. You can [read this blog post](https://backpackforlaravel.com/articles/news/we-recommend-you-fix-this-vulnerability) for more information.",
+  "details": "### Impact\n\nIt’s a “*moderate*” vulnerability… but being an admin panel, we take this seriously. It’s difficult… but an attacker could conduct a targeted phishing campaign, in order to **trick your users or admins to click a malicious link, which under very specific circumstances could give them information... or even admin access**. It’s *unlikely*, but that’s not good enough in admin panels - we should make it *impossible*. That’s why we’re bothering you with this. \n\n### Patches\n\n\nIf you don’t have custom error views, the views provided by Backpack would output the exception message *without escaping it*, which made an attack possible using Reflected XSS, in some very specific circumstances (that we will not disclose). **To fix those error views in Backpack 4.x and 5.x, please run**:\n\n```bash\ncomposer update backpack/crud\nphp artisan backpack:fix\n```\n\nThe problem has been patched in:\n- v4.0.63\n- v4.1.69\n- v5.0.13\n\n> **IMPORTANT! Running a `composer update` should get you the patched version, but you also need to run `php artisan backpack:fix` afterwards, to patch your published error views, if necessary.**\n\n### Workarounds\n\nAlternatively (if you don’t want to run `composer update`), you can manually look inside your error views in “*resources/views/errors*” and output `e($exception->getMessage())` instead of `$exception->getMessage()`. That’s all there is to the fix, really.\n\n### What the maintainers have done about this\n\nActed as soon as our team found it (last week of March 2022):\n- Pushed patches to 5.x, 4.1 and 4.0;\n- Made it easy to apply the fix to existing projects, using a new `php artisan backpack:fix` command;\n- Kept the specific circumstances a secret; as far as we know, only our team knows about the niche case where this exploit is possible;\n- Emailed all our licensed users, to have a chance to fix their projects before it’s public;\n- Sent an email blast to our 25.000+ strong Security Newsletter;\n- Made this public with a blog post and soon a CVE, after our community has had a reasonable chance to fix their projects;\n- Will continue to monitor this and remind paying users to apply this fix if they haven’t;\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [backpack/crud](https://github.com/laravel-backpack/crud)\n* Email us at [hello@backpackforlaravel.com](mailto:hello@backpackforlaravel.com)\n\n---\n\nPS. You can [read this blog post](https://backpackforlaravel.com/articles/news/we-recommend-you-fix-this-vulnerability) for more information.",
   "severity": [
     {
       "type": "CVSS_V4",
@@ -82,6 +82,10 @@
       "type": "ADVISORY",
       "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31114"
     },
+    {
+      "type": "WEB",
+      "url": "https://backpackforlaravel.com/articles/news/we-recommend-you-fix-this-vulnerability"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/Laravel-Backpack/CRUD"