https://db.gcve.eu/sightings/feed 2026-07-23T01:10:39.733509+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent sightings. https://db.gcve.eu/sighting/6d2c7104-5387-467f-ab6c-53ec0d3aec0f/export 2026-07-23T01:10:39.753911+00:00 sync_user https://db.gcve.eu/user/sync_user {"uuid": "6d2c7104-5387-467f-ab6c-53ec0d3aec0f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2020-26235", "type": "seen", "source": "https://gist.github.com/soul2zimate/a5296bc917881b1c43c396b5caf75393", "content": "", "creation_timestamp": "2026-04-07T11:43:13.000000Z"} 2026-04-07T11:43:13+00:00 https://db.gcve.eu/sighting/972e9213-4431-48b5-899a-33a988a245f1/export 2026-07-23T01:10:39.755804+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "972e9213-4431-48b5-899a-33a988a245f1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26234", "type": "seen", "source": "https://t.me/cibsecurity/17460", "content": "\u203c CVE-2020-26234 \u203c\n\nOpencast before versions 8.9 and 7.9 disables HTTPS hostname verification of its HTTP client used for a large portion of Opencast's HTTP requests. Hostname verification is an important part when using HTTPS to ensure that the presented certificate is valid for the host. Disabling it can allow for man-in-the-middle attacks. This problem is fixed in Opencast 7.9 and Opencast 8.8 Please be aware that fixing the problem means that Opencast will not simply accept any self-signed certificates any longer without properly importing them. If you need those, please make sure to import them into the Java key store. Better yet, get a valid certificate.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-12-09T07:35:04.000000Z"} 2020-12-09T07:35:04+00:00 https://db.gcve.eu/sighting/9f10d49a-2e74-4583-a4ba-5dfb13b60414/export 2026-07-23T01:10:39.756968+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "9f10d49a-2e74-4583-a4ba-5dfb13b60414", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26236", "type": "seen", "source": "https://t.me/cibsecurity/17416", "content": "\u203c CVE-2020-26236 \u203c\n\nIn ScratchVerifier before commit a603769, an attacker can hijack the verification process to log into someone else's account on any site that uses ScratchVerifier for logins. A possible exploitation would follow these steps: 1. User starts login process. 2. Attacker attempts login for user, and is given the same verification code. 3. User comments code as part of their normal login. 4. Before user can, attacker completes the login process now that the code is commented. 5. User gets a failed login and attacker now has control of the account. Since commit a603769 starting a login twice will generate different verification codes, causing both user and attacker login to fail. For clients that rely on a clone of ScratchVerifier not hosted by the developers, their users may attempt to finish the login process as soon as possible after commenting the code. There is no reliable way for the attacker to know before the user can finish the process that the user has commented the code, so this vulnerability only really affects those who comment the code and then take several seconds before finishing the login.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-12-09T07:25:16.000000Z"} 2020-12-09T07:25:16+00:00 https://db.gcve.eu/sighting/fc4b4fcd-fcb6-4768-a281-fb5aaa0d0eba/export 2026-07-23T01:10:39.757094+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "fc4b4fcd-fcb6-4768-a281-fb5aaa0d0eba", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26235", "type": "seen", "source": "https://t.me/cibsecurity/16833", "content": "\u203c CVE-2020-26235 \u203c\n\nIn Rust time crate from version 0.2.7 and before version 0.2.23, unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires the user to set any environment variable in a different thread than the affected functions. The affected functions are time::UtcOffset::local_offset_at, time::UtcOffset::try_local_offset_at, time::UtcOffset::current_local_offset, time::UtcOffset::try_current_local_offset, time::OffsetDateTime::now_local and time::OffsetDateTime::try_now_local. Non-Unix targets are unaffected. This includes Windows and wasm. The issue was introduced in version 0.2.7 and fixed in version 0.2.23.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-11-25T00:47:16.000000Z"} 2020-11-25T00:47:16+00:00 https://db.gcve.eu/sighting/e27469aa-5c96-44bc-b348-f09f9a0fd87a/export 2026-07-23T01:10:39.757209+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "e27469aa-5c96-44bc-b348-f09f9a0fd87a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26232", "type": "seen", "source": "https://t.me/cibsecurity/16825", "content": "\u203c CVE-2020-26232 \u203c\n\nJupyter Server before version 1.0.6 has an Open redirect vulnerability. A maliciously crafted link to a jupyter server could redirect the browser to a different website. All jupyter servers are technically affected, however, these maliciously crafted links can only be reasonably made for known jupyter server hosts. A link to your jupyter server may appear safe, but ultimately redirect to a spoofed server on the public internet.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-11-25T00:47:07.000000Z"} 2020-11-25T00:47:07+00:00 https://db.gcve.eu/sighting/2dbc0fb3-e015-415b-8339-d2b562ff83e1/export 2026-07-23T01:10:39.757298+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "2dbc0fb3-e015-415b-8339-d2b562ff83e1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26231", "type": "seen", "source": "https://t.me/cibsecurity/16758", "content": "\u203c CVE-2020-26231 \u203c\n\nOctober is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. A bypass of CVE-2020-15247 (fixed in 1.0.469 and 1.1.0) was discovered that has the same impact as CVE-2020-15247. An authenticated backend user with the cms.manage_pages, cms.manage_layouts, or cms.manage_partials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.enableSafeMode being enabled is able to write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This is not a problem for anyone that trusts their users with those permissions to normally write & manage PHP within the CMS by not having cms.enableSafeMode enabled, but would be a problem for anyone relying on cms.enableSafeMode to ensure that users with those permissions in production do not have access to write & execute arbitrary PHP. Issue has been patched in Build 470 (v1.0.470) and v1.1.1.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-11-24T00:46:18.000000Z"} 2020-11-24T00:46:18+00:00 https://db.gcve.eu/sighting/6f9c6e66-389e-4f32-a206-3526ae0fe9f8/export 2026-07-23T01:10:39.757387+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "6f9c6e66-389e-4f32-a206-3526ae0fe9f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26239", "type": "seen", "source": "https://t.me/cibsecurity/16733", "content": "\u203c CVE-2020-26239 \u203c\n\nScratch Addons is a WebExtension that supports both Chrome and Firefox. Scratch Addons before version 1.3.2 is vulnerable to DOM-based XSS. If the victim visited a specific website, the More Links addon of the Scratch Addons extension used incorrect regular expression which caused the HTML-escaped values to be unescaped, leading to XSS. Scratch Addons version 1.3.2 fixes the bug. The extension will be automatically updated by the browser. More Links addon can be disabled via the option of the extension.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-11-23T22:46:02.000000Z"} 2020-11-23T22:46:02+00:00 https://db.gcve.eu/sighting/ad9dd5ac-9379-44bd-af59-77057e7dd22d/export 2026-07-23T01:10:39.757474+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "ad9dd5ac-9379-44bd-af59-77057e7dd22d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26236", "type": "seen", "source": "https://t.me/cibsecurity/16670", "content": "\u203c CVE-2020-26236 \u203c\n\nIn ScratchVerifier before commit a603769, an attacker can hijack the verification process to log into someone else's account on any site that uses ScratchVerifier for logins. A possible exploitation would follow these steps: 1. User starts login process. 2. Attacker attempts login for user, and is given the same verification code. 3. User comments code as part of their normal login. 4. Before user can, attacker completes the login process now that the code is commented. 5. User gets a failed login and attacker now has control of the account. Since commit a603769 starting a login twice will generate different verification codes, causing both user and attacker login to fail. For clients that rely on a clone of ScratchVerifier not hosted by the developers, their users may attempt to finish the login process as soon as possible after commenting the code. There is no reliable way for the attacker to know before the user can finish the process that the user has commented the code, so this vulnerability only really affects those who comment the code and then take several seconds before finishing the login.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-11-20T20:42:57.000000Z"} 2020-11-20T20:42:57+00:00 https://db.gcve.eu/sighting/9f9b3e26-c2fa-4028-a2f0-7c496140cd07/export 2026-07-23T01:10:39.757561+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "9f9b3e26-c2fa-4028-a2f0-7c496140cd07", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2020-26230", "type": "seen", "source": "https://t.me/cibsecurity/16321", "content": "\u203c CVE-2020-26230 \u203c\n\nRadar COVID is the official COVID-19 exposure notification app for Spain. In affected versions of Radar COVID, identification and de-anonymization of COVID-19 positive users that upload Radar COVID TEKs to the Radar COVID server is possible. This vulnerability enables the identification and de-anonymization of COVID-19 positive users when using Radar COVID. The vulnerability is caused by the fact that Radar COVID connections to the server (uploading of TEKs to the backend) are only made by COVID-19 positives. Therefore, any on-path observer with the ability to monitor traffic between the app and the server can identify which users had a positive test. Such an adversary can be the mobile network operator (MNO) if the connection is done through a mobile network, the Internet Service Provider (ISP) if the connection is done through the Internet (e.g., a home network), a VPN provider used by the user, the local network operator in the case of enterprise networks, or any eavesdropper with access to the same network (WiFi or Ethernet) as the user as could be the case of public WiFi hotspots deployed at shopping centers, airports, hotels, and coffee shops. The attacker may also de-anonymize the user. For this additional stage to succeed, the adversary needs to correlate Radar COVID traffic to other identifiable information from the victim. This could be achieved by associating the connection to a contract with the name of the victim or by associating Radar COVID traffic to other user-generated flows containing identifiers in the clear (e.g., HTTP cookies or other mobile flows sending unique identifiers like the IMEI or the AAID without encryption). The former can be executed, for instance, by the Internet Service Provider or the MNO. The latter can be executed by any on-path adversary, such as the network provider or even the cloud provider that hosts more than one service accessed by the victim. The farther the adversary is either from the victim (the client) or the end-point (the server), the less likely it may be that the adversary has access to re-identification information. The vulnerability has been mitigated with the injection of dummy traffic from the application to the backend. Dummy traffic is generated by all users independently of whether they are COVID-19 positive or not. The issue was fixed in iOS in version 1.0.8 (uniform distribution), 1.1.0 (exponential distribution), Android in version 1.0.7 (uniform distribution), 1.1.0 (exponential distribution), Backend in version 1.1.2-RELEASE. For more information see the referenced GitHub Security Advisory.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-11-13T22:33:56.000000Z"} 2020-11-13T22:33:56+00:00