| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Blocksy theme for WordPress is vulnerable to Stored Cross-Site Scripting via the `blocksy_meta` metadata fields in all versions up to, and including, 2.1.30 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| In removePermission of PermissionManagerServiceImpl.java, there is a possible way to override any system permission due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. |
| In multiple functions of ProfilingService.java, there is a possible persistent denial of service due to improper input validation. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions of ProfilingService.java, there is a possible persistent denial of service due to improper input validation. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible way to delete media without the MANAGE_EXTERNAL_STORAGE permission due to an intent redirect. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions of MediaProvider.java, there is a possible external storage write permission bypass due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions of MediaProvider.java, there is a possible way to bypass the WRITE_EXTERNAL_STORAGE permission due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. |
| In multiple functions of KeyguardViewMediator.java, there is a possible lockscreen bypass due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In validateAddingWindowLw of DisplayPolicy.java, there is a possible way for an app to intercept drag-and-drop events due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible lockscreen bypass due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible bypass of a file path filter designed to prevent access to sensitive directories due to incorrect unicode normalization. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. |
| Wekan versions prior to 8.20 allow non-administrative users to access migration functionality due to insufficient permission checks, potentially resulting in unauthorized migration operations. |
| WeKan versions prior to 8.19 contain an authorization logic vulnerability where the instance configuration setting allowPrivateOnly is not sufficiently enforced at board creation time. When allowPrivateOnly is enabled, users can still create public boards due to incomplete server-side enforcement. |
| WeKan versions prior to 8.19 contain an insecure direct object reference (IDOR) in the card comment creation API. The endpoint accepts an authorId from the request body, allowing an authenticated user to spoof the recorded comment author by supplying another user's identifier. |
| WeKan versions prior to 8.19 contain an authorization vulnerability in card move logic. A user can specify a destination board/list/swimlane without adequate authorization checks for the destination and without validating that destination objects belong to the destination board, potentially enabling unauthorized cross-board moves. |
| WeKan versions prior to 8.19 contain an authorization vulnerability where certain card update API paths validate only board read access rather than requiring write permission. This can allow users with read-only roles to perform card updates that should require write access. |
| WeKan versions prior to 8.19 contain an insecure direct object reference (IDOR) in checklist creation and related checklist routes. The implementation does not verify that the supplied cardId belongs to the supplied boardId, allowing cross-board ID tampering by manipulating identifiers. |
| WeKan versions prior to 8.19 contain an insecure direct object reference (IDOR) in checklist creation and related checklist routes. The implementation does not verify that the supplied cardId belongs to the supplied boardId, allowing cross-board ID tampering by manipulating identifiers. |
| WeKan versions prior to 8.19 contain an information disclosure vulnerability in the attachments publication. Attachment metadata can be returned without properly scoping results to boards and cards accessible to the requesting user, potentially exposing attachment metadata to unauthorized users. |
| WeKan versions prior to 8.19 contain an authorization weakness in the attachment upload API. The API does not fully validate that provided identifiers (such as boardId, cardId, swimlaneId, and listId) are consistent and refer to a coherent card/board relationship, enabling attempts to upload attachments with mismatched object relationships. |
