| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The AI Agent by SiteGround plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.2.7. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to upload images to the WordPress media library, bypassing the upload_files capability restriction that Contributors are normally subject to, as authenticated attackers with Contributor-level access or above can satisfy the endpoint's nonce and permission checks. The sg_ai_studio_gutenberg_nonce required by the endpoint is emitted to any user with block editor access — including Contributors — making the absent upload_files check the sole barrier to exploitation. |
| WeGIA before 3.9.2 contains an authorization bypass vulnerability in the password change flow that allows any authenticated user to change their account password without providing existing credentials by exploiting the unconditional exclusion of the alterarSenha method from permission checks in controle/control.php. Attackers can manipulate the redir parameter to point to alterar_senha.php, routing through verificarSenhaConfig() instead of verificarSenha() to bypass current password verification and convert temporary session access into permanent account takeover. |
| ATutor is vulnerable to Missing Authorization Check on Test and Question Import endpoints. A low-privileged authenticated user (e.g. a student) enrolled in a course can bypass authorization checks by sending requests directly to the backend import endpoints, allowing the unauthorized import of tests and questions within a course.
Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, and 10.0.9, a user who does not hold the "admin" or "power" Splunk roles could cause the Splunk App for Splunk Observability Cloud to forward requests to Splunk Observability Cloud, including the Splunk Observability Cloud access token stored for the app. With this access, the user could view all relevant data available to that token and make limited changes to Splunk Observability Cloud content. The vulnerability does not affect Splunk Enterprise 9.4 and 9.3 versions. The vulnerability is possible because the app's Representational State Transfer (REST) API endpoint handlers do not enforce the read_o11y_content capability before forwarding requests with the stored access token. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.10, 3.9.24, and 3.8.71, a user who holds a Splunk role with permissions to list storage passwords but does not hold Splunk Secure Gateway administration privileges could access Mobile Device Management signing secrets that compromise all affected mobile-device enrollment trust through Splunk Secure Gateway. The vulnerability is possible because Splunk Secure Gateway Representational State Transfer (REST) API endpoints for deployment bundle, Security Assertion Markup Language setup, and companion app workflows do not require Splunk Secure Gateway administration privileges before processing requests. |
| Lemmy is a link aggregator and forum for the fediverse. Prior to 0.19.19 and 1.0.0-alpha.18, Lemmy blocks new private messages from a sender after the recipient blocks that sender, but the edit path skips the same block check. create_private_message checks the recipient's block list with PersonActions::read_block before inserting a message, while edit_private_message in crates/api/api_crud/src/private_message/update.rs only checks that the caller is orig_private_message.creator_id. The update then writes new content and returns the modified PrivateMessageView without consulting the recipient's block list, allowing a blocked sender to keep changing an old message that the recipient can still see and providing a post-block harassment path. This issue is fixed in versions 0.19.19 and 1.0.0-alpha.18. |
| Unauthenticated Broken Access Control in Altair <= 5.2.2 versions. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "user" Splunk role could craft a Dashboard Studio dashboard that runs attacker-controlled Search Processing Language (SPL) for another authenticated user. The attacker-controlled SPL could access all relevant data and affect system integrity and availability. The vulnerability is possible because Dashboard Studio does not consistently enforce the expected app-visibility authorization boundary before dashboard search query options reach search dispatch. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "user" Splunk role should not be able to exploit the vulnerability at will. For more information see Create search-based visualizations with ds.search (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/dashboard-studio/10.4/use-data-sources/create-search-based-visualizations-with-ds.search) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user that does not hold the fsh_manage capability could perform Remote Code Execution through Federated Search bundle selection. This could allow for access to all relevant data and affect system integrity and availability. The vulnerability is possible because the Federated Search dispatch flow accepts caller-controlled bundle selection without enforcing the capability that manages federated providers and indexes. For more information see Security models for Federated Search for Splunk (https://help.splunk.com/en/splunk-enterprise/search/federated-search/10.4/run-federated-searches-across-other-splunk-deployments/service-accounts-and-security-for-federated-search-for-splunk/security-models-for-federated-search-for-splunk) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.8, and 9.4.13, a user who does not hold the "admin" or "power" Splunk roles could trick another user into running arbitrary Search Processing Language (SPL) commands through the Data Model Editor using the permissions of the affected user. The commands could access all relevant data available to the affected user and affect system integrity. The vulnerability is possible because Splunk Web does not apply SPL safeguards for risky commands when the Data Model Editor runs the base search for auto-extracted fields. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| MyBooks is an ebook management web server also known as Talebook. In 3.41.2 and earlier, the AdminSettings.post handler for POST /api/admin/settings in webserver/handlers/admin.py applies the auth decorator but does not check the self.admin_user property, unlike the corresponding GET handler. Any authenticated regular user can therefore overwrite server configuration values including SMTP credentials, OAuth client secrets, storage paths, security feature flags, and autoreload settings. The process_auth_header function in webserver/handlers/base.py also fails to verify the matched account's active flag, allowing a registered but unactivated account to authenticate and reach the vulnerable handler. Exploitation can disclose secrets through configuration access paths, sabotage application behavior, force service restarts, and supply the settings needed for related code-injection attacks. This issue is fixed in version 3.42.0. |
| Grav Flex Objects Plugin allows you to build custom collections of objects. Prior to 1.4.3, the Grav Flex Objects Admin Next API requireFlexPermission() method in classes/Api/FlexApiController.php returns without denying access when a directory blueprint omits config.admin.permissions. An authenticated account with only api.access can use the index, show, create, update, delete, export, and media handlers for a permission-less directory even though the core admin.flex-object. authorization fallback would deny the same actions. This issue is fixed in version 1.4.3. |
| A flaw was found in the MON subscription handler of Ceph, a distributed storage system. The handler does not properly authorize access to the config-key store when processing MMonSubscribe messages. Any CephX user holding mon allow r capabilities can read the entire config-key store, which contains sensitive operational secrets including OSD LUKS disk encryption passphrases and, on clusters managed by cephadm, the SSH private key used to administer every host. Exposure of these secrets can lead to full host-level root access and compromise of encrypted data at rest. |
| Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3. |
| Lemur manages TLS certificate creation. Prior to 1.9.3, CertificateExport placed its CertificatePermission ownership check inside the plugin.requires_key branch for POST /api/1/certificates//export. A plugin declaring requires_key false bypassed that check, and the handler still passed cert.private_key as an argument and recorded a key_view audit event. The bundled JavaTruststoreExportPlugin ignored the key, so the immediate exposure was limited to public certificate material and misleading audit entries, but a future plugin could have consumed the supplied key. The fix passes no private key to plugins that do not require one and confines ownership checks and key_view logging to actual private-key exports. This issue is fixed in version 1.9.3. |
| phpMyFAQ versions before v4.1.6 fail to validate the security.enableRegistration setting in API endpoints, allowing attackers to create user accounts when registration is disabled. Attackers can bypass the registration restriction by submitting requests to POST /api/register or POST /api/v3.1/register endpoints, which do not check the configuration flag enforced by the HTML registration page. |
| IBM Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, FW1060.00 through FW1060.80, and FW950.00 through FW950.H2 is affected by a vulnerability in access controls over privileged system configuration operations on the FSP. An attacker with authenticated administrator-level access to the FSP can place the managed system into a non-production operational mode, allowing certain system components to be disabled. This condition persists across FSP resets and requires explicit operator intervention — clearing the affected configuration — to restore normal operation. Successful exploitation results in an availability impact to the managed system. |
| phpMyFAQ before 4.1.7 fails to properly enforce CONFIGURATION_EDIT permission on admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration, allowing any authenticated user to access sensitive administrative data. Attackers can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics by calling these endpoints with a valid session. |
| Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content. Prior to 1.0.8, the Grav API plugin intercepts the apiKeyGenerate and apiKeyRevoke admin tasks in user/plugins/api/api.php and authorizes the caller with only admin.login. A basic panel user can select another account from the route, create a persistent ApiKeyManager credential bound to that target, and inherit the target's API permissions, including api.super or administrative write access when present. This issue is fixed in version 1.0.8. |
| ArcadeDB (com.arcadedb) versions 26.7.3 and earlier fail to enforce the UPDATE_SCHEMA permission check when a DEFINE FUNCTION statement targets an already-existing function library. A user with only database access can add or overwrite SQL or Cypher functions in an existing library and persist the change, enabling tampering with admin-defined function logic. The issue is fixed in 26.8.1. (JavaScript functions still trigger the UPDATE_SECURITY check and are not affected.) |
