Incorrect Authorization

In S+ Operations and S+ Historian, not all client commands correctly check user permission as expected. Authenticated but Unauthorized remote users could execute a Denial-of-Service (DoS) attack, execute arbitrary code, or obtain more privilege than intended on the machines.Show less

IBM Automation Workstream Services 19.0.3, 20.0.1, 20.0.2, IBM Business Automation Workflow 18.0, 19.0, and 20.0 and IBM Business Process Manager 8.6 could allow an authenticated user to obtain sensitive information or cuase a denial of service due to iimproper authorization checking. IBM X-Force ID: 189445.Show less

In AndroidManifest.xml, there is a possible permissions bypass. This could lead to local escalation of privilege allowing a non-system app to send a broadcast it shouldn't have permissions to send, with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-157472962Show less

In callUnchecked of DocumentsProvider.java, there is a possible permissions bypass. This could lead to local escalation of privilege allowing a malicious app to access files available to the DocumentProvider without user permission, with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-157294893Show less

In updateIncomingFileConfirmNotification of BluetoothOppNotification.java, there is a possible permissions bypass. This could lead to local escalation of privilege allowing an attacker with physical possession of the device to transfer files to it over Bluetooth, with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-160691486Show less

An information leak vulnerability exists in Gerrit versions prior to 2.15.21, 2.16.25, 3.0.15, 3.1.10, 3.2.5 where a missing access check on the branch REST API allows an attacker with only the default set of priviledges to read all other user's personal account data as well as sub-trees with restricted access.Show less

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.Show less

An issue was discovered in the Linux kernel before 5.7.3, related to mm/gup.c and mm/huge_memory.c. The get_user_pages (aka gup) implementation, when used for a copy-on-write page, does not properly consider the semantics of read operations and therefore can grant unintended write access, aka CID-17839856fd58.Show less

October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.470, backend users with the default "Publisher" system role have access to create & manage users where they can choose which role the new user has. This means that a user with "Publisher" access has the ability to escalate their access to "Developer" access. Issue has been patched in Build 470 (v1.0.470) & v1.1.1.Show less

October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.421 and before version 1.0.469, an attacker can read local files on an October CMS server via a specially crafted request. Issue has been patched in Build 469 (v1.0.469) and v1.1.0.Show less

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.Show less

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.Show less

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.Show less

A security feature bypass vulnerability exists in the way Key Distribution Center (KDC) determines if a service ticket can be used for delegation via Kerberos Constrained Delegation (KCD). To exploit the vulnerability, a compromised service that is configured to use KCD could tamper with a service ticket that is not valid for delegation to force the KDC to accept it. The update addresses this vulnerability by changing how the KDC validates service tickets used with KCD.Show less