Total
418855 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-82115 | 2026-11-02 | N/A | 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-82898 | 2026-11-02 | N/A | N/A | ||
| Incorrect order of security checks in Apache Wicket. org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener obtains the page a request targets before it consults its resource isolation policies, because those policies are passed that page. Obtaining the page instantiates it, and instantiating a page runs the configured org.apache.wicket.authorization.IAuthorizationStrategy. An application that refuses an unauthenticated visitor by throwing org.apache.wicket.RestartResponseAtInterceptPageException therefore throws it from inside the isolation listener, before any policy has run. That exception replaces the request handler, so the policies are never consulted and a request that came from another origin is not refused. The exception's constructor stores the URL of the request it interrupted, so that Component#continueToOriginalDestination() can resume it once the visitor has signed in. The stored URL is the one the policies would have refused. On sign in Wicket redirects to it, and that redirect is same-origin, so the policies allow it and the listener runs in the newly authenticated session. The whole URL is stored, its query string included, so an ordinary org.apache.wicket.markup.html.form.Form is resumed with the field values the original request carried in its query string and Form#onSubmit() runs with values another origin chose. A form POST is not needed for this; a plain top-level navigation carries them. An application is affected where it registers ResourceIsolationRequestCycleListener, which is opt-in and is not registered by default, and where it refuses unauthorized access with RestartResponseAtInterceptPageException followed by continueToOriginalDestination(). No application override is involved on that path: IAuthorizationStrategy#isInstantiationAuthorized() documents throwing that exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication throws it and org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel continues to the original destination, and org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installs the same pattern. A visitor who is already signed in is not affected, because no interception occurs. Request-body parameters stored alongside the intercepted URL are not applied to the resumed form: the resumption is a redirect, so the resumed request is a GET, and form components read their values from the query string on a GET. As a workaround, refuse unauthorized access with org.apache.wicket.RestartResponseException instead, which does not store the original destination; visitors are then not returned to the page they asked for after signing in. This issue affects Apache Wicket: from 9.1.0 through 9.24.0, from 10.0.0 through 10.11.0. Releases before 9.1.0, which is every 8.x release and 9.0.0, are not affected, because the resource isolation this issue concerns was introduced in 9.1.0. They are not protected either. Their only cross-origin defence is org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, which works out where a request came from by reading its Origin header and falling back to its Referer header. Neither header need arrive: a browser does not send Origin on the plain GET a link uses, and the document on the other origin decides through its own referrer policy whether a Referer reaches the application at all. That mechanism therefore never made the guarantee the Fetch Metadata based policy makes, and on those releases a listener invocation from another origin is not reliably refused in the first place. Anyone on a release before 9.1.0 who wants this protection should upgrade to 9.x or 10.x and register ResourceIsolationRequestCycleListener. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue. | |||||
| CVE-2026-82705 | 2026-11-02 | N/A | N/A | ||
| Missing authorization in Apache Wicket. org.apache.wicket.authorization.IAuthorizationStrategy declares isResourceAuthorized(), and that method has a single enforcement point in the framework: org.apache.wicket.request.handler.resource.ResourceRequestHandler, the handler that serves a resource reached through a mounted or shared ResourceReference. Components that are handed an org.apache.wicket.request.resource.IResource instance instead call IResource#respond() themselves from their own request listener and never construct that handler. In wicket-core these are org.apache.wicket.markup.html.link.ResourceLink, org.apache.wicket.markup.html.image.Image and org.apache.wicket.markup.html.form.ImageButton; in wicket-extensions it is org.apache.wicket.extensions.ajax.AjaxDownloadBehavior. A resource restricted by a custom isResourceAuthorized() implementation, or by an @AuthorizeResource annotation from wicket-auth-roles, is therefore enforced when it is requested through its own resource URL and is not enforced when the same instance is served through the component that holds it. Which of the two happens is decided by the constructor the application used, and not by anything the application can see in the rendered page. ResourceLink(String, ResourceReference) renders a resource URL and the request is authorized; ResourceLink(String, IResource) renders a component listener URL and it is not. Image, ImageButton and AjaxDownloadBehavior each offer the same pair of constructors and behave the same way. Image and ImageButton write that listener URL into the src attribute of the tag they render, so a browser requests it without any action by the user, and the resource an Image serves may also come from the component's model. An application is affected where it restricts a resource through IAuthorizationStrategy#isResourceAuthorized() or an @AuthorizeResource annotation and then hands that same resource to one of those components as an IResource. An application that does not restrict resources at all is not affected, and neither is a resource that is only mounted or registered as a shared resource. The pattern does not have to be written by the application itself: org.apache.wicket.extensions.markup.html.repeater.data.table.export.ExportToolbar builds each of its export links from an IResource instance, so the exported contents of a data table are served without the resource check in any application that adds that toolbar. As a workaround, register the resource in the application's shared resources and pass the resulting ResourceReference to the component instead of the IResource, so that the request is routed through the handler that consults the authorization strategy. 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-83594 | 2026-11-02 | N/A | N/A | ||
| Memory allocation with an excessive size value in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField uploads files to a separately mounted resource rather than through a form, and is told the outcome afterwards over its own Ajax callback. That callback reads the request parameter filesInfo, a JSON array carrying a client file name, a size and a content type for each file, and turns it into the list of FileUploadToResourceField.UploadInfo that onUploadSuccess() receives. Nothing binds that JSON to an upload the resource performed and nothing re-derives it from the stored files, so the number of entries and every value in them are whatever the request supplied. The callback URL is rendered into the page, no prior upload is required, and both GET and POST reach it, so any client that can load the page can have the component report files that were never uploaded, without authenticating beyond whatever the page itself requires and without any user interaction. UploadInfo#get(), which the class offers as the way to obtain the bytes of an upload, allocates a byte array from UploadInfo#getSize() before it opens the file. The array is therefore sized by the number the request supplied, and the allocation happens even for a file that was never stored. One small request can cost the server close to two gigabytes of heap, and the request is trivially repeatable, so a few of them exhaust the heap for every request the Java virtual machine is serving. A size that the conversion to int turns negative instead throws NegativeArraySizeException, which the exception handler inside that method does not cover, so it escapes into the application. An application is affected where it uses FileUploadToResourceField, which is not the ordinary upload path through FileUploadField and Form and has to be extended and mounted deliberately. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself. Where the application denies the ENABLE action on the field through its authorization strategy, the callback is refused like any other listener. The 8.x line does not contain this component and is not affected. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue. | |||||
| CVE-2026-84177 | 2026-11-02 | N/A | N/A | ||
| Incorrect behavior order in Apache Wicket: a file path is validated before the framework appends the attributes that complete it. org.apache.wicket.request.resource.PackageResource asks the configured package resource guard about a path built from the scope class' package and the file name in the request URL, and then hands that same path to the resource stream locator together with a style, a variation and a locale. Those three attributes are decoded from the name of the first query parameter and never appear in the string the guard was given. org.apache.wicket.core.util.resource.locator.ResourceNameIterator appends them to that path, each preceded by an underscore, in the order variation, style, locale, before the file extension, so the file that is opened is not the file the guard approved. org.apache.wicket.markup.html.PackageResourceGuard decides whether an HTML file is a component's markup template by looking for a class file of the same name beside it, stripping one underscore-delimited suffix at a time as it goes. HTML is on the default allow list, so that check is the only thing separating a static HTML file, which may be served, from a markup template, which may not. Asked about the name of a template, the guard refuses it correctly. Asked about a shorter name for which no class exists, it accepts, and a style supplied in the URL then completes that name into the markup template of a component class, which is written to the response. An application is affected if the simple name of any of its component classes contains an underscore and no shorter part of that name is itself a class, such as Report_v2 or Wizard_Step1; an application with no such class name is not affected. No unusual deployment, packaging or configuration is required, and running in deployment rather than development mode does not prevent it. Java naming conventions discourage underscores in class names and no module Wicket ships has one, so no framework markup is exposed; what an application exposes this way is its own. A component whose class name has no underscore is not reachable, and neither is its localized or styled markup, because the guard finds the class file under the base name and refuses the request. The attributes cannot change the file extension and cannot leave the component's package, so nothing beyond HTML files in that package is reachable. Access is read-only, and what is disclosed is developer-authored template content: component structure, developer comments, markup that is rendered only under some conditions, inline script, and the endpoints a template names. No user data, credential or session material is reachable this way. An attacker has to name a class in the target package and the component itself, and Wicket writes fully qualified class names into the URL of every package resource it renders. 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 of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. | |||||
| CVE-2026-82557 | 2026-11-02 | N/A | 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-113795 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 5.5 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.20.0, accessing a crafted PDF stream with a large number of filters or multiple filters that pass around large amounts of data can cause large memory consumption. This issue is fixed in version 6.20.0. | |||||
| CVE-2026-113794 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 5.5 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.20.0, an attacker can craft an incomplete PDF that ends inside a standard cross-reference table, causing pypdf to mishandle the unexpected end of file and enter an infinite loop. This issue is fixed in version 6.20.0. | |||||
| CVE-2026-113789 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 3.3 LOW |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.0, an attacker can craft a PDF that causes large memory usage or long runtimes when an application retrieves the document's form fields. This issue is fixed in version 6.21.0. | |||||
| CVE-2026-114364 | 2026-11-02 | N/A | N/A | ||
| Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in Apache Syncope. This CVE covers an incomplete fix for CVE-2026-77051: an administrator with adequate entitlements can achieve execution of arbitrary SQL via stacked queries, leveraging unsanitized opEvent parameters. Reference: https://cve.org/CVERecord?id=CVE-2026-77051 This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 through 4.0.8, from 4.1.0-M0 through 4.1.3. Users are recommended to upgrade to version 4.0.9 / 4.1.4, which fix this issue. | |||||
| CVE-2026-50053 | 1 Synacor | 1 Zimbra Collaboration Suite | 2026-11-02 | N/A | 8.7 HIGH |
| A request attribute override vulnerability in Zimbra Collaboration Suite (ZCS) allows unauthenticated requests to /h/* to populate servlet attributes intended for trusted internal dispatch. RestFilter copies URL parameters specifying an authentication token, target account, target item and dispatch state into the request attributes consumed by the Classic Web Client. Combined with CVE-2026-10632 on ZCS 10.1.16, this allows an attacker to supply their own valid token and document identifiers and execute JavaScript in another user's signed-in browser session. ZCS 10.1.17 blocks that XSS chain by changing the document renderer, but retains the request attribute override. | |||||
| CVE-2026-22690 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 5.3 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Prior to version 6.6.0, pypdf has possible long runtimes for missing /Root object with large /Size values. An attacker who uses this vulnerability can craft a PDF which leads to possibly long runtimes for actually invalid files. This can be achieved by omitting the /Root entry in the trailer, while using a rather large /Size value. Only the non-strict reading mode is affected. This issue has been patched in version 6.6.0. | |||||
| CVE-2026-33123 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 6.5 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Versions prior to 6.9.1 allow an attacker to craft a malicious PDF which leads to long runtimes and/or large memory usage. Exploitation requires accessing an array-based stream with many entries. This issue has been fixed in version 6.9.1. | |||||
| CVE-2026-102996 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 7.5 HIGH |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.18.1, a crafted PDF can provide a TrueType or Type1 simple font with an unusually large /Widths array, causing pypdf/_font.py Font._collect_tt_t1_character_widths to process entries beyond the 256 character codes meaningful for a simple font and consume excessive memory during operations such as text extraction. This issue is fixed in version 6.18.1. | |||||
| CVE-2026-49461 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 5.5 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.12.2, an attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires extracting the text of a page which contains a form XObject with self-references. This vulnerability is fixed in 6.12.2. | |||||
| CVE-2026-27888 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 7.5 HIGH |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.7.3, an attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing the `xfa` property of a reader or writer and the corresponding stream being compressed using `/FlateDecode`. This has been fixed in pypdf 6.7.3. As a workaround, apply the patch manually. | |||||
| CVE-2026-59938 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 5.3 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.14.0, an attacker can craft a PDF with declared image size values that are much too large compared to the actual data, causing large memory usage in pypdf image parsing. This issue is fixed in version 6.14.0. | |||||
| CVE-2026-115572 | 2026-11-02 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.2, an attacker can craft a PDF that repeatedly references the same nonexistent indirect object, causing relevant file parts such as pages to trigger repeated full-file recovery loads and long runtimes when accessed. This issue is fixed in version 6.21.2. | |||||
| CVE-2026-84309 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 5.5 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.16.0, an attacker can craft a PDF whose cyclic tree structure causes pypdf/generic/_data_structures.py TreeObject.insert_child to follow /Next links indefinitely when a writing code path inserts a child, producing an infinite loop. This issue is fixed in version 6.16.0. | |||||
| CVE-2026-54531 | 1 Py-pdf | 1 Pypdf | 2026-11-02 | N/A | 5.5 MEDIUM |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.13.0, an attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires merging a file with outlines into a writer. This vulnerability is fixed in 6.13.0. | |||||