Total
2294 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-4532 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 4.3 Medium |
| An issue has been discovered in GitLab affecting all versions starting from 16.2 before 16.2.8, all versions starting from 16.3 before 16.3.5, all versions starting from 16.4 before 16.4.1. Users were capable of linking CI/CD jobs of private projects which they are not a member of. | ||||
| CVE-2023-4317 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 4.3 Medium |
| An issue has been discovered in GitLab affecting all versions starting from 9.2 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for a user with the Developer role to update a pipeline schedule from an unprotected branch to a protected branch. | ||||
| CVE-2023-3979 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 3.1 Low |
| An issue has been discovered in GitLab affecting all versions starting from 10.6 before 16.2.8, all versions starting from 16.3 before 16.3.5, all versions starting from 16.4 before 16.4.1. It was possible that upstream members to collaborate with you on your branch get permission to write to the merge request’s source branch. | ||||
| CVE-2023-3920 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 4.3 Medium |
| An issue has been discovered in GitLab affecting all versions starting from 11.2 before 16.2.8, all versions starting from 16.3 before 16.3.5, all versions starting from 16.4 before 16.4.1. It was possible that a maintainer to create a fork relationship between existing projects contrary to the documentation. | ||||
| CVE-2023-3511 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 2 Low |
| An issue has been discovered in GitLab EE affecting all versions starting from 8.17 before 16.4.4, all versions starting from 16.5 before 16.5.4, all versions starting from 16.6 before 16.6.2. It was possible for auditor users to fork and submit merge requests to private projects they're not a member of. | ||||
| CVE-2023-3509 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 3.7 Low |
| An issue has been discovered in GitLab affecting all versions before 16.7.6, all versions starting from 16.8 before 16.8.3, all versions starting from 16.9 before 16.9.1. It was possible for group members with sub-maintainer role to change the title of privately accessible deploy keys associated with projects in the group. | ||||
| CVE-2023-3484 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 8 High |
| An issue has been discovered in GitLab EE affecting all versions starting from 12.8 before 15.11.11, all versions starting from 16.0 before 16.0.7, all versions starting from 16.1 before 16.1.2. An attacker could change the name or path of a public top-level group in certain situations. | ||||
| CVE-2023-3443 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 3.1 Low |
| An issue has been discovered in GitLab affecting all versions starting from 12.1 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for a Guest user to add an emoji on confidential work items. | ||||
| CVE-2023-0120 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 3.5 Low |
| An issue has been discovered in GitLab affecting all versions starting from 10.0 before 16.1.5, all versions starting from 16.2 before 16.2.5, all versions starting from 16.3 before 16.3.1. Due to improper permission validation it was possible to edit labels description by an unauthorised user. | ||||
| CVE-2025-1417 | 2025-05-21 | N/A | ||
| In Proget MDM, a low-privileged user can access information about changes contained in backups of all devices managed by the MDM (Mobile Device Management). This information include user ids, email addresses, first names, last names and device UUIDs. The last one can be used for exploitation of CVE-2025-1416. Successful exploitation requires UUID of a targeted backup, which cannot be brute forced. This issue has been fixed in 2.17.5 version of Konsola Proget (server part of the MDM suite). | ||||
| CVE-2025-1418 | 2025-05-21 | N/A | ||
| A low-privileged user can access information about profiles created in Proget MDM (Mobile Device Management), which contain details about allowed/prohibited functions. The profiles do not reveal any sensitive information (including their usage in connected devices). This issue has been fixed in 2.17.5 version of Konsola Proget (server part of the MDM suite). | ||||
| CVE-2025-1416 | 2025-05-21 | N/A | ||
| In Proget MDM, a low-privileged user can retrieve passwords for managed devices and subsequently use functionalities restricted by the MDM (Mobile Device Management). For it to happen, they must know the UUIDs of targetted devices, which might be obtained by exploiting CVE-2025-1415 or CVE-2025-1417. This issue has been fixed in 2.17.5 version of Konsola Proget (server part of the MDM suite). | ||||
| CVE-2025-1415 | 2025-05-21 | N/A | ||
| A low-privileged user is able to obtain information about tasks executed on devices controlled by Proget MDM (Mobile Device Management), as well as details of the devices like their UUIDs needed for exploitation of CVE-2025-1416. In order to perform the attack, one has to know a task_id, but since it's a low integer and there is no limit of requests an attacker can perform to a vulnerable endpoint, the task_id might be simply brute forced. This issue has been fixed in 2.17.5 version of Konsola Proget (server part of the MDM suite). | ||||
| CVE-2024-21120 | 1 Oracle | 1 Outside In Technology | 2025-05-21 | 5.3 Medium |
| Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Core). Supported versions that are affected are 8.5.6 and 8.5.7. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Outside In Technology executes to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Outside In Technology accessible data as well as unauthorized read access to a subset of Oracle Outside In Technology accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Outside In Technology. CVSS 3.1 Base Score 5.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L). | ||||
| CVE-2022-3048 | 2 Fedoraproject, Google | 3 Fedora, Chrome, Chrome Os | 2025-05-21 | 6.8 Medium |
| Inappropriate implementation in Chrome OS lockscreen in Google Chrome on Chrome OS prior to 105.0.5195.52 allowed a local attacker to bypass lockscreen navigation restrictions via physical access to the device. | ||||
| CVE-2022-40816 | 1 Zammad | 1 Zammad | 2025-05-21 | 6.5 Medium |
| Zammad 5.2.1 is vulnerable to Incorrect Access Control. Zammad's asset handling mechanism has logic to ensure that customer users are not able to see personal information of other users. This logic was not effective when used through a web socket connection, so that a logged-in attacker would be able to fetch personal data of other users by querying the Zammad API. This issue is fixed in , 5.2.2. | ||||
| CVE-2022-39031 | 1 Lcnet | 1 Smart Evision | 2025-05-21 | 5.3 Medium |
| Smart eVision has insufficient authorization for task acquisition function. An unauthorized remote attacker can exploit this vulnerability to acquire the Session IDs of other general users only. | ||||
| CVE-2022-39029 | 1 Lcnet | 1 Smart Evision | 2025-05-21 | 6.5 Medium |
| Smart eVision has inadequate authorization for the database query function. A remote attacker with general user privilege, who is not explicitly authorized to access the information, can access sensitive information. | ||||
| CVE-2022-39030 | 1 Lcnet | 1 Smart Evision | 2025-05-21 | 7.5 High |
| smart eVision has inadequate authorization for system information query function. An unauthenticated remote attacker, who is not explicitly authorized to access the information, can access sensitive information. | ||||
| CVE-2024-36963 | 1 Linux | 1 Linux Kernel | 2025-05-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracefs: Reset permissions on remount if permissions are options There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs). But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated. This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some. For example: # cd /sys/kernel/tracing # chgrp 1002 current_tracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root root 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root root 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root root 0 May 1 21:25 dynamic_events -r--r----- 1 root root 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root root 0 May 1 21:25 enabled_functions Where current_tracer now has group "lkp". # mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root tracing 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root tracing 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamic_events -r--r----- 1 root tracing 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root tracing 0 May 1 21:25 enabled_functions Everything changed but the "current_tracer". Add a new link list that keeps track of all the tracefs_inodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories. | ||||