Home
Bugtraq
Full List
Only Bugs
Only Tricks
Only Exploits
Only Dorks
Only CVE
Only CWE
Fake Notes
Ranking
CVEMAP
Full List
Show Vendors
Show Products
CWE Dictionary
Check CVE Id
Check CWE Id
Search
Bugtraq
CVEMAP
By author
CVE Id
CWE Id
By vendors
By products
RSS
Bugtraq
CVEMAP
CVE Products
Bugs
Exploits
Dorks
More
cIFrex
Facebook
Twitter
Donate
About
Submit
CWE
:
Sorry. No results for Bugtraq WLB2
CVEMAP Search Results
CVE
Details
Description
2024-09-25
CVE-2024-45599
Updating...
Cursor is an artificial intelligence code editor. Prior to version 0.41.0, if a user on macOS has granted Cursor access to the camera or microphone, any program that is run on the machine is able to access the camera or the microphone without explicitly being granted access, through a DyLib Injection using DYLD_INSERT_LIBRARIES environment variable. The usage of `com.apple.security.cs.allow-dyld-environment-variables` and `com.apple.security.cs.disable-library-validation` allows an external dynamic library to be injected into the application using DYLD_INSERT_LIBRARIES environment variable. Moreover, the entitlement `com.apple.security.device.camera` allows the application to use the host camera and `com.apple.security.device.audio-input` allows the application to use the microphone. This means that untrusted code that is executed on the user's machine can access the camera or the microphone, if the user has already given permission for Cursor to do so. In version 0.41.0, the entitlements have been split by process: the main process gets the camera and microphone entitlements, but not the DyLib entitlements, whereas the extension host process gets the DyLib entitlements but not the camera or microphone entitlements. As a workaround, do not explicitly give Cursor the permission to access the camera or microphone if untrusted users can run arbitrary commands on the affected machine.
2024-08-07
CVE-2024-7143
Updating...
A flaw was found in the Pulp package. When a role-based access control (RBAC) object in Pulp is set to assign permissions on its creation, it uses the `AutoAddObjPermsMixin` (typically the add_roles_for_object_creator method). This method finds the object creator by checking the current authenticated user. For objects that are created within a task, this current user is set by the first user with any permissions on the task object. This means the oldest user with model/domain-level task permissions will always be set as the current user of a task, even if they didn't dispatch the task. Therefore, all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.
Copyright
2026
, cxsecurity.com
Back to Top
