{"vulnerability": "cve-2020-1517", "sightings": [{"uuid": "aecf11f2-b292-4539-98fc-b18b0c6128f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15174", "type": "seen", "source": "MISP/6e30f326-aec9-463b-ae21-d80758e62ed0", "content": "", "creation_timestamp": "2024-11-14T06:07:03.000000Z"}, {"uuid": "672f0764-1c9a-4949-bba6-12087e80974a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15174", "type": "published-proof-of-concept", "source": "https://t.me/CyberSecurityTechnologies/1940", "content": "Discord Electron Desktop app RCE:\n- Missing contextIsolation\n- XSS in iframe embeds\n- Navigation restriction bypass (CVE-2020-15174)\nhttps://mksben.l0.cm/2020/10/discord-desktop-rce.html", "creation_timestamp": "2022-06-07T23:39:56.000000Z"}, {"uuid": "511e614b-b64c-46fe-9b76-715b28895707", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15176", "type": "seen", "source": "https://t.me/cibsecurity/15126", "content": "\u203c CVE-2020-15176 \u203c\n\nIn GLPI before version 9.5.2, when supplying a back tick in input that gets put into a SQL query,the application does not escape or sanitize allowing for SQL Injection to occur. Leveraging this vulnerability an attacker is able to exfiltrate sensitive information like passwords, reset tokens, personal details, and more. The issue is patched in version 9.5.2\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-10-07T22:29:25.000000Z"}, {"uuid": "f09c2361-902c-4b9b-979d-80227f990d42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15175", "type": "seen", "source": "https://t.me/cibsecurity/15128", "content": "\u203c CVE-2020-15175 \u203c\n\nIn GLPI before version 9.5.2, the `?pluginimage.send.php?` endpoint allows a user to specify an image from a plugin. The parameters can be maliciously crafted to instead delete the .htaccess file for the files directory. Any user becomes able to read all the files and folders contained in \u00e2\u20acœ/files/\u00e2\u20ac\ufffd. Some of the sensitive information that is compromised are the user sessions, logs, and more. An attacker would be able to get the Administrators session token and use that to authenticate. The issue is patched in version 9.5.2.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-10-07T22:29:26.000000Z"}, {"uuid": "314ae0b3-8bcb-4170-b1e5-8f804c7b413a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15174", "type": "seen", "source": "https://t.me/hn_best_comments/6128", "content": "Re: Discord Desktop App RCE\n        \nHi all! Discord Employee here that was involved in the remediation of this exploit! I just wanted to clarify with a timeline, and explanation as to why we had context isolation disabled!\n\n9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.\n\n9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.\n\n10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.\n\nThanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!\n\nFollowing that, the next day we deployed a better update as we understood more about the issue (which was the sandbox attribute on the iframe.) In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174) which allowed for a bypass of our CSP, by allowing the main window to be navigated to a different domain.\n\n----\n\nAs for context isolation, a lot of the code that had been written was not compatible with contextIsolation - and required significant work to refactor. For example, due to the way that objects needed to be cloned to pass through the bridge, the internal APIs that existed needed to be entirely reworked, as they were not really compatible with this model. We began this work in April shortly after we worked out all the quirks required to upgrade to Electron 7 which is when contextBridge would be available for us to turn on contextIsolation. It was not as simple as flipping a boolean from false -> true, and required a re-work of our native modules and their internal APIs, and also doing so in a way that would be backwards & forwards compatible with the various app versions that we had shipped in the wild - in addition to dealing with some performance regressions that needed work-arounds in the new context isolated world.\n\nIn August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!\n        \njhgg, 12 hours ago", "creation_timestamp": "2026-08-02T00:01:11.570957Z"}, {"uuid": "035c2e38-d73f-437e-a25b-87f70273b12c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15174", "type": "seen", "source": "https://t.me/hn_best_comments/6128", "content": "Re: Discord Desktop App RCE\n        \nHi all! Discord Employee here that was involved in the remediation of this exploit! I just wanted to clarify with a timeline, and explanation as to why we had context isolation disabled!\n\n9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.\n\n9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.\n\n10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.\n\nThanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!\n\nFollowing that, the next day we deployed a better update as we understood more about the issue (which was the sandbox attribute on the iframe.) In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174) which allowed for a bypass of our CSP, by allowing the main window to be navigated to a different domain.\n\n----\n\nAs for context isolation, a lot of the code that had been written was not compatible with contextIsolation - and required significant work to refactor. For example, due to the way that objects needed to be cloned to pass through the bridge, the internal APIs that existed needed to be entirely reworked, as they were not really compatible with this model. We began this work in April shortly after we worked out all the quirks required to upgrade to Electron 7 which is when contextBridge would be available for us to turn on contextIsolation. It was not as simple as flipping a boolean from false -> true, and required a re-work of our native modules and their internal APIs, and also doing so in a way that would be backwards & forwards compatible with the various app versions that we had shipped in the wild - in addition to dealing with some performance regressions that needed work-arounds in the new context isolated world.\n\nIn August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!\n        \njhgg, 12 hours ago", "creation_timestamp": "2026-08-01T08:00:04.306893Z"}, {"uuid": "8091cb08-7186-41e8-920f-61d1a63b16ae", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15174", "type": "seen", "source": "https://t.me/hn_best_comments/6128", "content": "Re: Discord Desktop App RCE\n        \nHi all! Discord Employee here that was involved in the remediation of this exploit! I just wanted to clarify with a timeline, and explanation as to why we had context isolation disabled!\n\n9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.\n\n9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.\n\n10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.\n\nThanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!\n\nFollowing that, the next day we deployed a better update as we understood more about the issue (which was the sandbox attribute on the iframe.) In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174) which allowed for a bypass of our CSP, by allowing the main window to be navigated to a different domain.\n\n----\n\nAs for context isolation, a lot of the code that had been written was not compatible with contextIsolation - and required significant work to refactor. For example, due to the way that objects needed to be cloned to pass through the bridge, the internal APIs that existed needed to be entirely reworked, as they were not really compatible with this model. We began this work in April shortly after we worked out all the quirks required to upgrade to Electron 7 which is when contextBridge would be available for us to turn on contextIsolation. It was not as simple as flipping a boolean from false -> true, and required a re-work of our native modules and their internal APIs, and also doing so in a way that would be backwards & forwards compatible with the various app versions that we had shipped in the wild - in addition to dealing with some performance regressions that needed work-arounds in the new context isolated world.\n\nIn August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!\n        \njhgg, 12 hours ago", "creation_timestamp": "2026-07-29T12:01:07.787151Z"}, {"uuid": "883ce952-11a5-48eb-8f96-20b896e46aee", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-15174", "type": "seen", "source": "https://t.me/hn_best_comments/6128", "content": "Re: Discord Desktop App RCE\n        \nHi all! Discord Employee here that was involved in the remediation of this exploit! I just wanted to clarify with a timeline, and explanation as to why we had context isolation disabled!\n\n9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.\n\n9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.\n\n10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.\n\nThanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!\n\nFollowing that, the next day we deployed a better update as we understood more about the issue (which was the sandbox attribute on the iframe.) In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174) which allowed for a bypass of our CSP, by allowing the main window to be navigated to a different domain.\n\n----\n\nAs for context isolation, a lot of the code that had been written was not compatible with contextIsolation - and required significant work to refactor. For example, due to the way that objects needed to be cloned to pass through the bridge, the internal APIs that existed needed to be entirely reworked, as they were not really compatible with this model. We began this work in April shortly after we worked out all the quirks required to upgrade to Electron 7 which is when contextBridge would be available for us to turn on contextIsolation. It was not as simple as flipping a boolean from false -> true, and required a re-work of our native modules and their internal APIs, and also doing so in a way that would be backwards & forwards compatible with the various app versions that we had shipped in the wild - in addition to dealing with some performance regressions that needed work-arounds in the new context isolated world.\n\nIn August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!\n        \njhgg, 12 hours ago", "creation_timestamp": "2026-07-30T00:01:47.493094Z"}]}