Export limit exceeded: 11856 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (11856 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-82704 | 1 Apache | 1 Wicket | 2026-11-06 | N/A |
| Missing authorization in Apache Wicket. org.apache.wicket.core.request.handler.ListenerRequestHandler invokes an IRequestListener only when org.apache.wicket.Component#canCallListener() allows it, and that method is isEnabledInHierarchy() && isVisibleInHierarchy(). The visibility half reads a flag that carries the outcome of IAuthorizationStrategy#isActionAuthorized() for the Component.RENDER action, and that flag is written in one place only, Component#configure(), during the render phase. A listener URL built by a subclass of org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper carries the page identifier and the component path in a single parameter, and the page identifier may be empty. When it is, a new page instance is constructed, PageProvider#wasExpired() is false because no identifier was supplied, and PageAndComponentProvider#getComponent() finds the component directly on the new instance, so neither a render pass nor Component#configure() runs before the listener is invoked. The flag therefore still holds its constructor default, the component counts as visible, and the listener of a component the authorization strategy denied RENDER for is executed. The same request also skips Component#onConfigure(), so visibility and enablement an application sets there are not applied either. There are two ways to reach this, and neither requires anything but a request. On a page that is stateful, the caller omits the page identifier from a listener URL that would otherwise carry it. On a page that Wicket considers stateless, nothing has to be altered at all: Wicket itself writes listener URLs without a page identifier for such pages, and a component the strategy denies RENDER for is treated as stateless and therefore does not keep the page stateful, so denying RENDER can itself produce the page-id-less form. The second route has never been refused. The ENABLE decision of IAuthorizationStrategy is consulted on every invocation and still refuses, as does a request that supplies the real identifier of a page instance that has already been rendered; a component the application disabled in Component#onConfigure() is protected by neither, because that callback has not run. An application is affected where it withholds an individual component from the caller, either by denying the RENDER action through IAuthorizationStrategy, including through the MetaDataRoleAuthorizationStrategy and AuthorizeAction facilities of wicket-auth-roles, or by setting the component's visibility or enabled flag in Component#onConfigure(), the callback Wicket's own documentation directs applications to use for both. The page carrying such a component has to be constructible from a bookmarkable or mounted URL, which requires a public constructor taking either no arguments or a PageParameters argument. Behaviours pass through the same gate, so an AJAX behaviour attached to such a component is equally exposed. Separately, and whether or not any component is withheld, a listener on a page Wicket considers stateful is invoked on an instance the request itself constructed, so it acts on models built from page parameters the caller supplied rather than on the state the application last rendered. Instantiation authorization is unaffected: IAuthorizationStrategy#isInstantiationAuthorized() is still consulted when the new page instance is created, so a guard placed on the page rather than on the individual component continues to hold. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. | ||||
| CVE-2026-82558 | 1 Apache | 1 Wicket | 2026-11-06 | N/A |
| Missing authorization in Apache Wicket. org.apache.wicket.protocol.ws.api.WebSocketBehavior, through which Wicket's native WebSocket support hands a message sent by the client to the application, calls its onMessage() callbacks without checking whether the client may invoke the component the behavior is attached to. Wicket opens a single WebSocket connection per page, and a message received on it is delivered to every WebSocketBehavior of that page. For an Ajax behavior Wicket makes this check before invoking it, through Behavior#canCallListener(Component), which refuses a component that is not visible or not enabled, including one for which the IAuthorizationStrategy denies the RENDER or ENABLE action. A WebSocketBehavior attached to such a component, or to a child of one, therefore receives the client's text and binary messages, together with a WebSocketRequestHandler that writes back to that client, where an Ajax behavior on the same component would be refused. An application is affected where it attaches a WebSocketBehavior that overrides onMessage() to a component that it hides, disables, or restricts through its IAuthorizationStrategy, for example with MetaDataRoleAuthorizationStrategy or the AuthorizeAction annotation. The client needs a session of their own and a page of their own that contains such a component: messages are delivered only to pages in the page store of the client's own session, so this gives no access to another user's session, page or connection. Messages pushed by the server are not affected. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Older, unsupported releases from 6.0.0 onwards are also affected. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. | ||||
| CVE-2026-82557 | 1 Apache | 1 Wicket | 2026-11-06 | N/A |
| Missing authorization in Apache Wicket. org.apache.wicket.markup.html.form.Form resolves the component that submitted a form from the request parameters in Form#onRequest() and passes the result directly to Form#onFormSubmitted(IFormSubmitter). The check that the submitting component is visible and enabled in its hierarchy runs only when onFormSubmitted() is given no submitter, so it no longer runs for an ordinary form submission, and it is the only point at which Wicket verifies that the application actually offered the named control to the caller. Form#findSubmitter() matches on the request parameter name alone and applies no visibility or enablement filter, and the request handler checks only the form itself, which is visible and enabled. A request that names a submit button the application withheld therefore reaches that button's onSubmit() and onAfterSubmit(), and its onError() when form validation fails; where the button sets setDefaultFormProcessing(false) it reaches onSubmit() and onAfterSubmit() without any form validation. An application is affected where a form submitting component, such as a Button or a SubmitLink, is unavailable to the caller while the enclosing form remains available. How the component was made unavailable does not matter: the component's own setVisible(false), setEnabled(false) or setVisibilityAllowed(false), an overridden isVisible() or isEnabled(), an invisible or disabled parent container anywhere above it, and a RENDER or ENABLE denial from IAuthorizationStrategy — for example through MetaDataRoleAuthorizationStrategy or the AuthorizeAction annotation — are all enforced by that one check, and all of them are bypassed. A component that renders as disabled carries its own input name in the markup the caller already holds. Submissions made through AjaxFormSubmitBehavior, and therefore through AjaxButton and AjaxSubmitLink, are not affected: those are invoked as a behaviour on the button itself, the behaviour's invocation is authorized against that button, and the non-Ajax callbacks of those two classes do nothing. Restrictions applied to the form or to the page rather than to the submitting component are unaffected. The 9.x and 8.x release lines, and the unsupported lines before them, are not affected; the behaviour was introduced in 10.3.0. This issue affects Apache Wicket: from 10.3.0 through 10.11.0. Users are recommended to upgrade to version 10.12.0, which fixes the issue. | ||||
| CVE-2026-82115 | 1 Apache | 1 Wicket | 2026-11-06 | N/A |
| Missing authorization in Apache Wicket. org.apache.wicket.protocol.ws.api.WebSocketMessageBroadcastHandler, the request handler Wicket's native WebSocket support uses to deliver an incoming frame, resolves the shared resource named by the client's handshake parameter and calls WebSocketResource#onPayload() on it directly, without consulting IAuthorizationStrategy#isResourceAuthorized(). That method has a single enforcement point in the framework, org.apache.wicket.request.handler.resource.ResourceRequestHandler, which the WebSocket transport does not pass through, and WebSocketResource#respond() is final and empty. No route to a WebSocketResource therefore asks the configured authorization strategy whether the caller may use it, and an @AuthorizeResource annotation on such a class has no effect. A caller needs a bound Wicket session and the name of the resource. The name is not a secret: Wicket writes it into the page that opens the connection. No page of the application is otherwise involved, because a request naming a resource is served with a throwaway page. All of the resource's callbacks are reached this way, including onConnect() and both onMessage() overloads, and what a callback pushes back through WebSocketRequestHandler goes to the caller's own connection. An application is affected where it registers a WebSocketResource as a shared resource and relies on the authorization strategy to restrict it. What the caller gains is whatever that resource's callbacks do with a text or binary message of the caller's choosing. The connection is registered under the caller's own session, so it gives no access to another user's connection. As a workaround, reject unauthorized connections with an IWebSocketConnectionFilter registered through WebSocketSettings#setConnectionFilter(), or repeat the authorization check at the start of each callback. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Older, unsupported releases from 7.0.0 onwards are also affected. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. | ||||
| CVE-2026-123655 | 1 Moodle | 1 Moodle | 2026-11-06 | 7.5 High |
| A flaw was found in Moodle. Insufficient access control checks on H5P content files allow unauthenticated remote attackers to view restricted materials, including content stored in the system context and files belonging to hidden or unavailable course modules. This issue results in unauthorized information disclosure of protected content. | ||||
| CVE-2026-123623 | 2026-11-06 | 5.9 Medium | ||
| Grida through 0.0.24 contains a missing authorization vulnerability in the Forms file-preview API routes that allows unauthenticated attackers to read other organizations' form response files. Attackers can use form and field IDs exposed in public form payloads with a chosen path parameter to obtain service-role signed URLs for attachments and connected Supabase bucket objects. | ||||
| CVE-2026-86795 | 1 Wordpress-extensions | 1 Community Events | 2026-11-06 | 5.3 Medium |
| The Community Events WordPress plugin before 1.6.0 does not have authorisation or nonce checks in one of its AJAX actions, allowing unauthenticated users to retrieve details of event submissions awaiting moderation, which are not available anywhere on the public site. | ||||
| CVE-2026-122151 | 1 Presenton | 1 Presenton | 2026-11-06 | 4.3 Medium |
| A security vulnerability has been detected in Presenton up to 0.9.11-beta. Impacted is the function JSON.parse of the file /api/user-config of the component User Configuration Handler. Such manipulation leads to cross-site request forgery. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 0.9.12-beta is recommended to address this issue. The name of the patch is 44c8a61122b21f17642d717b0c4d6f2c54c0f180. It is recommended to upgrade the affected component. | ||||
| CVE-2026-88135 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-11-06 | 7.8 High |
| Improper access control in WebDAV allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-103002 | 1 Gpustack | 1 Gpustack | 2026-11-06 | 8.8 High |
| GPUStack is an open-source GPU cluster manager for AI model serving and GPU instance provisioning. From 2.2.0 until 2.2.2, cluster_apiserver_proxy forwarded an authenticated non-administrator's requests to a selected Kubernetes cluster without a resource-level authorization check. The proxy used a reachable worker's Kubernetes ServiceAccount credentials, so the caller could read sensitive resources, create or modify workloads, or delete resources according to that ServiceAccount's permissions. Exploitation required a Kubernetes-provider cluster with a reachable worker, and attacker-controlled workloads could result in code execution in the target cluster. This issue is fixed in version 2.2.2. | ||||
| CVE-2026-123323 | 1 Jetbrains | 1 Youtrack | 2026-11-06 | 8.4 High |
| In JetBrains YouTrack before 2025.3.170763, 2026.1.14150, 2026.2.19656 improper URL validation in the app widget host allowed apps to send REST requests without user confirmation | ||||
| CVE-2026-33379 | 1 Grafana | 2 Grafana, Grafana Enterprise | 2026-11-06 | 8.5 High |
| A user with any role, including Viewer or a service account with no permissions, can create, externally publish, and delete dashboard snapshots (missing authorization). Only Grafana OSS and Grafana Enterprise 12.4 are affected; earlier versions and Grafana 13 are not. | ||||
| CVE-2026-97311 | 1 Redhat | 4 Build Keycloak, Build Of Keycloak, Red Hat Single Sign On and 1 more | 2026-11-06 | 4.3 Medium |
| A flaw was found in the Admin REST API of Keycloak, an identity and access management solution. The endpoints used to retrieve groups associated with a specific role do not properly check for individual group visibility permissions. This allows a delegated administrator with basic search privileges to view detailed information about all groups assigned to a role, bypassing intended security restrictions that should limit their view to specific groups. | ||||
| CVE-2026-97177 | 1 Redhat | 4 Build Keycloak, Build Of Keycloak, Red Hat Single Sign On and 1 more | 2026-11-06 | 6.6 Medium |
| A flaw was found in the user update mechanism of the Keycloak Admin REST API. When Fine-Grained Admin Permissions are enabled, the system fails to check for specific password reset authorizations during a general user profile update. This allows a delegated administrator, who should be restricted from resetting passwords, to change a user's credentials and take over their account. | ||||
| CVE-2026-96446 | 1 Redhat | 4 Build Keycloak, Build Of Keycloak, Red Hat Single Sign On and 1 more | 2026-11-06 | 4.2 Medium |
| A flaw was found in the Pushed Authorization Request PAR implementation of Keycloak. The issue occurs when the silent authentication path prompt=none is used, which allows the authorization process to skip certain steps if a user is already logged in. Due to this bypass, the security rule that ensures a pushed request URI is used only once is not enforced. An attacker could potentially reuse a request URI to obtain multiple authorization codes for a user who is already signed in, violating security standards like FAPI-2. | ||||
| CVE-2026-94217 | 1 Redhat | 2 Build Keycloak, Red Hat Single Sign On | 2026-11-06 | 3.5 Low |
| A flaw was found in the User-Managed Access (UMA) implementation of Keycloak. The issue occurs in the authorization token endpoint when processing permission tickets. If two different users own resources with the same name, the system incorrectly merges the permissions from both resources when one user requests an authorization token. This allows an attacker to gain access scopes on a victim's resource that were never intended to be shared. | ||||
| CVE-2026-94215 | 1 Redhat | 2 Build Keycloak, Red Hat Single Sign On | 2026-11-06 | 5.5 Medium |
| A flaw was found in the Admin REST API of Keycloak, an open-source identity and access management solution. The issue occurs because the API uses a per-request in-memory cache to resolve clients by their unique identifier without verifying if the client belongs to the realm specified in the request path. This allows an administrator with limited privileges to read or modify sensitive client configurations in the master realm by accessing them through a realm they control. Successful exploitation could lead to the exposure of client credentials or the redirection of administrative login attempts to malicious sites. | ||||
| CVE-2026-94213 | 1 Redhat | 2 Build Keycloak, Red Hat Single Sign On | 2026-11-06 | 4.9 Medium |
| A flaw was found in the Authorization Services component of Keycloak, an open-source identity and access management solution. The issue occurs in the policy evaluation endpoint, which is used by administrators to test how access policies apply to specific users. Due to missing authorization checks, a delegated administrator with limited viewing privileges can access the full profile and role information of any user in the realm, even if they are not permitted to view user details. This could lead to the exposure of sensitive information such as email addresses and assigned security roles. | ||||
| CVE-2026-111253 | 1 Redhat | 2 Hardened Images, Hummingbird | 2026-11-06 | 6.6 Medium |
| A flaw was found in dnf5daemon-server. Session methods on dynamically exported D-Bus session objects do not verify that the caller is the unique sender that created the session. A local attacker can modify another user's live package-management session and replace its resolved transaction plan. If the legitimate session party later authorizes execution, the root daemon may apply the attacker-chosen package operations. | ||||
| CVE-2026-40802 | 2026-11-06 | 7.6 High | ||
| Missing Authorization vulnerability in pubjet Pubjet | پابجت pubjet allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Pubjet | پابجت: from n/a through 5.4.8. | ||||