| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An Authorization Bypass vulnerability in the Marmind web application with version 4.1.141.0 allows users with lower privileges to gain control to files uploaded by administrative users. The accessed files were not visible by the low privileged users in the web GUI. |
| Information about the starred projects for private user profiles was exposed via the GraphQL API starting from 12.2 via the REST API. This affects GitLab >=12.2 to <13.4.7, >=13.5 to <13.5.5, and >=13.6 to <13.6.2. |
| A limited information disclosure vulnerability exists in Gitlab CE/EE from >= 12.2 to <13.4.7, >=13.5 to <13.5.5, and >=13.6 to <13.6.2 that allows an attacker to view limited information in user's private profile |
| OAuthenticator is an OAuth login mechanism for JupyterHub. In oauthenticator from version 0.12.0 and before 0.12.2, the deprecated (in jupyterhub 1.2) configuration `Authenticator.whitelist`, which should be transparently mapped to `Authenticator.allowed_users` with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as `GitHubOAuthenticator.org_whitelist` are **not** affected. All users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the `admin.whitelist.users` configuration in the jupyterhub helm chart or the `c.Authenticator.whitelist` configuration directly. Users of other deprecated configuration, e.g. `c.GitHubOAuthenticator.team_whitelist` are **not** affected. If you see a log line like this and expect a specific list of allowed usernames: "[I 2020-11-27 16:51:54.528 JupyterHub app:1717] Not using allowed_users. Any authenticated user will be allowed." you are likely affected. Updating oauthenticator to 0.12.2 is recommended. A workaround is to replace the deprecated `c.Authenticator.whitelist = ...` with `c.Authenticator.allowed_users = ...`. If any users have been authorized during this time who should not have been, they must be deleted via the API or admin interface, per the referenced documentation. |
| October 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. |
| Spree is a complete open source e-commerce solution built with Ruby on Rails. In Spree from version 3.7 and before versions 3.7.13, 4.0.5, and 4.1.12, there is an authorization bypass vulnerability. The perpetrator could query the API v2 Order Status endpoint with an empty string passed as an Order token. This is patched in versions 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. Users of Spree < 3.7 are not affected. |
| GLPI stands for Gestionnaire Libre de Parc Informatique and it is a Free Asset and IT Management Software package, that provides ITIL Service Desk features, licenses tracking and software auditing. In GLPI before version 9.5.3, any authenticated user has read-only permissions to the planning of every other user, even admin ones. Steps to reproduce the behavior: 1. Create a new planning with 'eduardo.mozart' user (from 'IT' group that belongs to 'Super-admin') into it's personal planning at 'Assistance' > 'Planning'. 2. Copy the CalDAV url and use a CalDAV client (e.g. Thunderbird) to sync the planning with the provided URL. 3. Inform the username and password from any valid user (e.g. 'camila' from 'Proativa' group). 4. 'Camila' has read-only access to 'eduardo.mozart' personal planning. The same behavior happens to any group. E.g. 'Camila' has access to 'IT' group planning, even if she doesn't belong to this group and has a 'Self-service' profile permission). This issue is fixed in version 9.5.3. As a workaround, one can remove the `caldav.php` file to block access to CalDAV server. |
| An issue was discovered in the ALFA Windows 10 driver 6.1316.1209 for AWUS036H. The Wi-Fi implementation does not verify the Message Integrity Check (authenticity) of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets in WPA or WPA2 networks that support the TKIP data-confidentiality protocol. |
| An issue was discovered in the FileImporter extension for MediaWiki before 1.34.4. An attacker can import a file even when the target page is protected against "page creation" and the attacker should not be able to create it. This occurs because of a mishandled distinction between an upload restriction and a create restriction. An attacker cannot leverage this to overwrite anything, but can leverage this to force a wiki to have a page with a disallowed title. |
| An issue was discovered in Zammad before 3.4.1. There are wrong authorization checks for impersonation requests via X-On-Behalf-Of. The authorization checks are performed for the actual user and not the one given in the X-On-Behalf-Of header. |
| An issue was discovered in Zammad before 3.4.1. Admin Users without a ticket.* permission can access Tickets. |
| Stratodesk NoTouch Center before 4.4.68 is affected by: Incorrect Access Control. A low privileged user on the platform, for example a user with "helpdesk" privileges, can perform privileged operations including adding a new administrator to the platform via the easyadmin/user/submitCreateTCUser.do page. |
| An information leak was discovered in MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4. Handling of actor ID does not necessarily use the correct database or correct wiki. |
| An issue was discovered in file_download.php in MantisBT before 2.24.3. Users without access to view private issue notes are able to download the (supposedly private) attachments linked to these notes by accessing the corresponding file download URL directly. |
| Multiple flaws were found in the way samba AD DC implemented access and conformance checking of stored data. An attacker could use this flaw to cause total domain compromise. |
| A flaw was found in the way samba, as an Active Directory Domain Controller, is able to support an RODC (read-only domain controller). This would allow an RODC to print administrator tickets. |
| A flaw was found in infinispan 10 REST API, where authorization permissions are not checked while performing some server management operations. When authz is enabled, any user with authentication can perform operations like shutting down the server without the ADMIN role. |
| If the upload course tool in Moodle was used to delete an enrollment method which did not exist or was not already enabled, the tool would erroneously enable that enrollment method. This could lead to unintended users gaining access to the course. Versions affected: 3.9 to 3.9.2, 3.8 to 3.8.5, 3.7 to 3.7.8, 3.5 to 3.5.14 and earlier unsupported versions. This is fixed in moodle 3.9.3, 3.8.6, 3.7.9, 3.5.15, and 3.10. |
| In moodle, insufficient capability checks could lead to users with the ability to course restore adding additional capabilities to roles within that course. Versions affected: 3.9 to 3.9.2, 3.8 to 3.8.5, 3.7 to 3.7.8, 3.5 to 3.5.14 and earlier unsupported versions. This is fixed in moodle 3.9.3, 3.8.6, 3.7.9, 3.5.15, and 3.10. |
| An issue was discovered in ManagedClusterView API, that could allow secrets to be disclosed to users without the correct permissions. Views created for an admin user would be made available for a short time to users with only view permission. In this short time window the user with view permission could read cluster secrets that should only be disclosed to admin users. |
