Export limit exceeded: 420824 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10668 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-84172 | 1 Apache | 1 Wicket | 2026-11-02 | N/A |
| Files accessible to external parties in Apache Wicket. org.apache.wicket.markup.html.PackageResourceGuard decides whether a file on the classpath may be streamed to a client as a package resource. HTML is on the default allow list, so the only thing that separates a static HTML file, which may be served, from a component's markup template, which may not, is a check for a class file of the same name beside it. That check calls getResource() on the class loader that loaded wicket-core. The resource itself is reached through different class loaders: the scope class is resolved through the application's IClassResolver, which uses the thread context class loader, and org.apache.wicket.core.util.resource.ClassPathResourceFinder#find() then tries the scope class' own loader, the context class loader, and the wicket-core loader last. Where wicket-core is loaded by a class loader that cannot see the application's classes, the check finds no class file, concludes the file is not a component markup template, and serves it. A request for the package resource URL of a component class then returns that component's markup template with status 200. 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. Access is read-only, and no user data, credential or session material is reachable this way. Such a deployment is rare. The ordinary packaging, a web archive with wicket-core in WEB-INF/lib, puts the framework and the application in one class loader, so the check finds the class file and the template is refused; those deployments are not affected. The exposure is confined to deployments that give wicket-core a class loader which cannot see the application's component classes: wicket-core placed in a servlet container's shared library directory, in an enterprise archive library directory with the application in the web archive, as an application server global module, or as an OSGi bundle, where wicket-core's bundle cannot resolve a class held by an application bundle. Markup shipped by Wicket's own modules, and by any other code sharing a class loader with wicket-core, remains protected. An attacker has to name a component class, 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-120320 | 1 Jxxghp | 1 Moviepilot | 2026-11-02 | 4.7 Medium |
| A vulnerability was determined in jxxghp MoviePilot up to 3.1.2. This vulnerability affects the function WorkflowExecutor.restore_context of the file app/chain/workflow.py of the component Workflow Fork Endpoint. Executing a manipulation can lead to deserialization. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 3.1.3 is able to resolve this issue. This patch is called 6034dcc880c13079aeb398dbe32c346ebcd3a6d2. It is recommended to upgrade the affected component. | ||||
| CVE-2026-39738 | 2026-11-01 | 9.8 Critical | ||
| Deserialization of Untrusted Data vulnerability in Aman FunnelKit Automations wp-marketing-automations allows Object Injection.This issue affects FunnelKit Automations: from n/a through 3.8.6.1. | ||||
| CVE-2026-86404 | 1 Redhat | 6 Amq Broker, Build Of Apache Camel For Quarkus, Build Of Apache Camel For Spring Boot and 3 more | 2026-11-01 | 8.8 High |
| EAP's Artemis deserialization configuration permits deserialization by default. ObjectMessage.getObject() uses ObjectInputStreamWithClassLoader, which implements allow-list/block-list filtering via its checkSecurity()/isTrustedType() method. However, by default both allow-list and block-list are empty. When the allow-list is empty (size == 0), isTrustedType() returns true for ALL classes. This means all classes are deserializable by default. | ||||
| CVE-2026-15555 | 1 Redhat | 4 Jboss Enterprise Application Platform, Jboss Enterprise Application Platform Els, Jboss Enterprise Application Platform Expansion Pack and 1 more | 2026-11-01 | 8.8 High |
| A flaw was found in JBoss marshalling. The Infinispan session replication path deserializes replicated session data via the JBoss Marshalling River unmarshaller with no class filtering — enabling RCE via deserialization gadget chains on every cluster node. | ||||
| CVE-2026-118636 | 1 Apache | 1 Mina | 2026-10-31 | 9.8 Critical |
| **UNSUPPORTED WHEN ASSIGNED** JavaNativeMessageDecoder in the MINA 3.0 codec module calls ObjectInputStream.readObject() on frame bytes with no class filter, so an application that puts it in front of an untrusted peer is open to gadget-chain RCE. As the 3.0.0 branch is inactive, we do not plan to release a version that fixes this issue. Users are recommended to use the latest Apache MINA 2.2.X branch. | ||||
| CVE-2026-118599 | 1 Gnome | 1 Epiphany | 2026-10-31 | 5.5 Medium |
| A file overwrite vulnerability exists in Epiphany when installing WebExtension packages from .xpi files. In src/webextension/ephy-web-extension-manager.c, decompress_xpi_thread() used libarchive with archive_read_support_format_all() (and filters), so the installer did not require a real ZIP. A TAR file named *.xpi was extracted. TAR supports hard-link entry types; with Epiphany's archive_write_disk options (including ARCHIVE_EXTRACT_PERM), a crafted hard-link target can cause an attacker-chosen existing user-writable file to be truncated and overwritten with attacker-controlled content and mode bits, without a dedicated warning dialog, when the user installs or opens the crafted .xpi. This is related to but separate from the ZIP-slip path traversal fixed as CVE-2026-77679 (#2922 / MR !2143). Requirements: the victim must install or open a malicious WebExtension (.xpi). Affected: Epiphany >= 47.0 (WebExtension XPI install path). Fixed: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2248 (commit 0cc9ab55 — only enable ZIP format support). Upstream: https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2988 Reporter acknowledgment: Fernando Munoz | ||||
| CVE-2026-116230 | 2 Ndemic Creations, Ndemiccreations | 2 Plague Inc Evolved, Plague Inc Evolved | 2026-10-31 | 6.3 Medium |
| A vulnerability was identified in Ndemic Creations Plague Inc Evolved up to 1.24.0.3. The affected element is an unknown function of the component Workshop Scenario Loader. Such manipulation leads to deserialization. The attack may be performed from remote. Upgrading to version 1.24.0.4 is sufficient to fix this issue. It is recommended to upgrade the affected component. | ||||
| CVE-2026-88137 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-31 | 6.5 Medium |
| Files or directories accessible to external parties in WebDAV allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-118938 | 1 Trailofbits | 1 Fickling | 2026-10-30 | 8.8 High |
| In Trail of Bits fickling through 0.1.12, a pickle STACK_GLOBAL operand carrying a dotted __qualname__ (for example "Values.read_file") is resolved by pickle's find_class through _getattribute to an arbitrary attribute path rather than to a module-level function. Fickling records only the leading component of the name in its import tracking and renders the operation as a plain import (for instance, 'python -m fickling' displays it as 'from optparse import Values.read_file'), so the trailing attribute reference is never analyzed as a call. The OvertlyBadEvals analysis pass does not flag it, and check_safety() returns LIKELY_SAFE with zero findings. This allows an attacker to reach a class method that performs code execution: optparse.Values.read_file executes exec(open(filename).read(), vars), achieving arbitrary code execution when the crafted pickle is loaded through fickling.load(), which chains check_safety() into pickle.loads() as an explicit security gate. optparse is present in all current CPython 3.x releases (deprecated as of Python 3.13, not removed). This weakness is in the resolution and analysis of dotted attribute-path names, and is distinct from and independently fixable from the module-origin trust weakness tracked as CVE-2026-16760: resolving or flagging dotted attribute-path imports closes this vector while leaving the module-level trust behavior unchanged. This bypass was verified to remain present on the vendor master branch at commit d011709 as of 2026-10-30, after the vendor's October blocklist additions and a new heuristic that flags private stdlib attributes; because the public class method Values.read_file is neither blocklisted nor flagged as a private attribute, it is not addressed by those remediations. | ||||
| CVE-2026-78527 | 2026-10-30 | 8.8 High | ||
| Contributor PHP Object Injection in GS Testimonial Slider <= 3.3.10 versions. | ||||
| CVE-2023-22793 | 1 Veeam | 1 Management Pack For Microsoft System Center | 2026-10-30 | N/A |
| A vulnerability allowing an unauthenticated attacker to perform remote code execution (RCE) on servers running the Veeam Virtualization Extensions service of Veeam Management Pack for Microsoft System Center. | ||||
| CVE-2026-107238 | 1 Veeam | 1 Management Pack For Microsoft System Center | 2026-10-30 | N/A |
| A vulnerability allowing an authenticated domain user to perform remote code execution (RCE) as the LocalSystem account on servers running the Veeam Management Pack for Microsoft System Center Collector service. | ||||
| CVE-2026-103039 | 2 Gravityforms, Wordpress-extensions | 2 Gravity Forms, Gravity Forms | 2026-10-30 | 9.8 Critical |
| The Gravity Forms plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.1.2 via a Post Custom Field whose input type is List. This is due to GFFormsModel::create_post() passing the submitted value to WordPress' unrestricted global maybe_unserialize() rather than the plugin's own hardened GFCommon::maybe_unserialize(), which was added in 3.1.1 and passes allowed_classes => false precisely to prevent object instantiation. Where the field has a content template enabled, the submitted row reaches that call verbatim. This makes it possible for unauthenticated attackers to inject a PHP object into post meta. No PHP Object Injection gadget chain is present in the plugin itself; however, if a gadget chain is present via an additional plugin or theme, it could allow the attacker to perform actions such as remote code execution. Where the custom field is mapped to the protected _wp_page_template meta key, WordPress itself supplies the chain: validate_file() accepts non-scalars, WP_Theme::__toString() then resolves an attacker-controlled path, and on hosts with a readable PEAR install and register_argc_argv enabled this yields remote code execution. | ||||
| CVE-2026-119290 | 1 Zuke-build | 1 Zuke | 2026-10-30 | 7.5 High |
| Zuke is a code-first, strongly typed build automation system for Deno. Prior to 1.51.0, @zuke/core writes rendered reportSummary(...) notes to GITHUB_STEP_SUMMARY through writeJobSummary without applying the redactor that protects resolved secret() values in console and persisted run output. A GitHub Actions build that places secret-derived text in a summary note can publish credentials in cleartext to everyone able to view the workflow run, including unauthenticated viewers of a public repository, and the durable summary remains exposed until the run is deleted. GitHub Actions masking directives do not protect the summary file, while runs outside GitHub Actions and builds that do not summarize secret-derived text are not affected. This issue is fixed in version 1.51.0. | ||||
| CVE-2026-62848 | 1 Metalama | 1 Metalama | 2026-10-30 | 7.3 High |
| Metalama is a Roslyn-based open-source patterns and architecture toolkit for C#. From 2023.0.101-rc until 2025.1.18, 2026.0.25 and 2026.1.19, the Windows Visual Studio integration deserializes local named-pipe messages without restricting which CLR types can be instantiated. The pipe connects `devenv`, the out-of-process Roslyn code-analysis process and the `CodeLens` process, and has the predictable name `Metalama_{role}_{processId}_{hash(PackageVersion)}`. Releases from the first public 2023.0 line through 2026.0.x use Newtonsoft.Json with `TypeNameHandling.All`; the later `SerializationBinder` only remaps assembly names, and `BindToType` resolves arbitrary wire-supplied types without an allow-list. Releases 2026.1.0 through 2026.1.18 use typeless MessagePack with `TypelessObjectResolver` and likewise instantiate arbitrary types. A same-user local process able to write to the pipe can send crafted messages that lead to arbitrary code execution with confidentiality, integrity and availability impacts inside the affected Visual Studio process. Default Windows pipe ACLs limit writers to the same logged-in user, so this does not escalate privileges or cross a security boundary; command-line and MSBuild-only builds do not use the channel. The maintained Metalama + PostSharp extension is affected from 2024.1 through 2026.1.4, while earlier Metalama-free PostSharp versions are unaffected. The retired Metalama and Caravela extensions remain affected and require removal or migration. The framework issue is fixed in versions 2025.1.18, 2026.0.25 and 2026.1.19; the maintained Metalama + PostSharp Visual Studio extension is fixed in version 2026.1.5. The retired Metalama and Caravela extensions require removal or migration. | ||||
| CVE-2026-16760 | 1 Trailofbits | 1 Fickling | 2026-10-30 | 8.8 High |
| In Trail of Bits fickling through 0.1.12, the _process_import() method in fickle.py adds an imported name to the likely_safe_imports set whenever the source module is present in sys.stdlib_module_names and the name is absent from the UNSAFE_IMPORTS denylist, without inspecting what the name resolves to or how it behaves. The OvertlyBadEvals analysis pass in analysis.py then unconditionally skips any call whose function name appears in likely_safe_imports, including calls that would otherwise be flagged as overtly dangerous. As a result, any callable reachable through a non-blocked standard library module inherits module-level trust regardless of its own behavior, and check_safety() returns LIKELY_SAFE with zero findings for pickle payloads that reach code execution or file write through such callables. Demonstrated primitives: dataclasses._create_fn, which passes an attacker-controlled function body to exec() and yields arbitrary code execution on Python 3.7 through 3.12 (the internal _create_fn function was removed in Python 3.13); mailcap.findmatch, which internally calls os.system() on a test command taken from an attacker-controlled caps dictionary, yielding arbitrary code execution on Python versions through 3.12 (the mailcap module was removed in Python 3.13); and readline.add_history() followed by readline.write_history_file(), which writes attacker-controlled content to an arbitrary filesystem path (POSIX platforms, where the readline module is available). fickling.load() chains check_safety() into pickle.loads() as an explicit security gate, so a LIKELY_SAFE verdict causes the payload to be deserialized and executed with the privileges of the victim process. The root cause is the inference of callable safety from module origin; it is independent of, and separately fixable from, the dotted __qualname__ resolution weakness tracked as CVE-2026-118938, which this advisory does not address. As of 2026-10-30 the three demonstrated modules were added to UNSAFE_IMPORTS on the vendor master branch (commit d011709) pending release; released versions through 0.1.12 remain affected, and the module-origin trust root cause persists, as demonstrated by the related CVE-2026-118938 remaining exploitable on that same build. | ||||
| CVE-2026-118763 | 1 Sigstore | 1 Sigstore | 2026-10-30 | 7.4 High |
| sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin. | ||||
| CVE-2026-59388 | 1 Cloudfoundry | 2 Cf-deployment, Cloud Controller | 2026-10-30 | 6.5 Medium |
| Cloud Controller (CAPI) leaks sensitive data into audit logs in multiple instances: custom buildpack credentials are exposed in audit events for app manifest application, creation, and updates; syslog drain URL credentials are exposed in user-provided service instance audit events; and service binding parameters are leaked in app manifest and service binding audit events. | ||||
| CVE-2026-93327 | 1 Google | 1 Application Integration | 2026-10-30 | N/A |
| A Deserialization of Untrusted Data vulnerability in the SubWorkflow task in Google Cloud Application Integration versions prior to 2026-09-11 on Google Cloud Platform allows an authenticated attacker to execute arbitrary code using a maliciously crafted serialized object. This vulnerability was patched on 11 September 2026, and no customer action is needed. | ||||