Export limit exceeded: 410569 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (410569 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-110887 | 2026-10-19 | 9.9 Critical | ||
| Improper Control of Generation of Code ('Code Injection') vulnerability in HivePress HivePress hivepress allows Remote Code Inclusion.This issue affects HivePress: from n/a through 1.7.32. | ||||
| CVE-2026-102608 | 1 Zoneminder | 1 Zoneminder | 2026-10-19 | 9 Critical |
| ZoneMinder is a free, open source closed-circuit television software application. Prior to 1.38.3, downloadEvents() manually wraps a monitor Name value in single quotes instead of using escapeshellarg() before placing it in shell commands when a user with monitor-create or monitor-edit permission stores a monitor Name containing shell metacharacters and a user with Events View permission exports that monitor's events. In this attack mechanism, the stored monitor Name reaches both the ffmpeg concatenation command and the tar or zip archive command and breaks out of manual quoting. Arbitrary commands execute as the web server user. This issue is fixed in version 1.38.3. | ||||
| CVE-2026-112247 | 1 Wuxi Wubang Security Software | 1 Five-in-one Safety Production Management Information System | 2026-10-19 | 4.3 Medium |
| A weakness has been identified in Wuxi Wubang Security Software Five-in-One Safety Production Management Information System up to 3.5. This affects an unknown function of the file /FCKeditor/editor/filemanager/connectors/aspx/upload.aspx of the component Upload Endpoint. Executing a manipulation of the argument NewFile can lead to cross site scripting. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-91858 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 6.5 Medium |
| FopProducer transforms the incoming XSL-FO message body by creating a javax.xml.transform.TransformerFactory through TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING before running an identity transform over the body. On the JDK's built-in transformer, that feature alone already empties the accessExternalDTD and accessExternalStylesheet limits, so an external DTD or entity is refused. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, for example because the application also uses camel-xslt-saxon or camel-saxon, TransformerFactory.newInstance() returns that implementation instead, and FEATURE_SECURE_PROCESSING on its own does not restrict external resource access on it. A DOCTYPE with an external subset, or an external general entity, declared in the XSL-FO document is then resolved and expanded while the body is transformed. An external sender whose XSL-FO reaches a fop producer could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. camel-fop does not bring such a factory itself, and excludes Xalan, so a default deployment using the JDK transformer is not affected; the issue is reachable only where another component has placed an alternative JAXP TransformerFactory on the classpath. Releases on the 4.14.x line and earlier reached end of life before this issue was resolved and do not receive a fix. | ||||
| CVE-2026-15661 | 1 Ibm | 1 Concert | 2026-10-19 | 5.3 Medium |
| IBM Concert 1.0 through 3.0.0 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files. | ||||
| CVE-2026-66788 | 1 Redhat | 2 Acm, Advanced Cluster Management For Kubernetes | 2026-10-19 | 9.9 Critical |
| A flaw was found in Lighthouse. A remote attacker, by compromising a spoke cluster, can exploit a vulnerability where the destination namespace for resource injection is derived from an attacker-controlled label or annotation on the broker object. This allows the attacker to inject unauthorized EndpointSlices and ServiceImports into any namespace on peer clusters, including critical system namespaces like kube-system and openshift-*. This could lead to privilege escalation or other forms of system compromise within the cluster. | ||||
| CVE-2026-66787 | 1 Redhat | 2 Acm, Advanced Cluster Management For Kubernetes | 2026-10-19 | 8.7 High |
| A flaw was found in the lighthouse component of Red Hat Advanced Cluster Management for Kubernetes. This vulnerability stems from insufficient validation of advertised IP addresses within EndpointSlice objects. A compromised spoke cluster can exploit this by creating EndpointSlices with attacker-controlled IP addresses, causing other clusters' lighthouse DNS to redirect legitimate service traffic to malicious endpoints. This enables a remote attacker to conduct transparent Man-in-the-Middle (MITM) attacks on cross-cluster service communications, potentially leading to unauthorized information disclosure and data manipulation. | ||||
| CVE-2026-66783 | 1 Redhat | 2 Acm, Advanced Cluster Management For Kubernetes | 2026-10-19 | 4.4 Medium |
| A flaw was found in the `submariner-operator` component of Red Hat Advanced Cluster Management for Kubernetes. This vulnerability allows a cluster administrator, or any user with permissions to modify the Submariner Custom Resource (CR), to specify an unvalidated image path. This lack of validation enables an attacker to execute arbitrary code with elevated privileges across the entire cluster, including control-plane nodes, by deploying a malicious image. | ||||
| CVE-2026-66782 | 1 Redhat | 2 Acm, Advanced Cluster Management For Kubernetes | 2026-10-19 | 5.8 Medium |
| A flaw was found in the Submariner operator. This vulnerability allows for the exposure of a long-lived broker service account (SA) bearer token within the Submariner Custom Resource (CR) specification. An attacker with access to the cluster's etcd database or through `kubectl get` commands could obtain this token. The possession of this token grants full control over the mesh network, enabling unauthorized management of network resources such as endpoints and secrets. | ||||
| CVE-2026-66781 | 1 Redhat | 2 Acm, Advanced Cluster Management For Kubernetes | 2026-10-19 | 5.4 Medium |
| A flaw was found in the Submariner operator. The Submariner Custom Resource (CR), used for configuring network connectivity, stores the IPsec pre-shared key (PSK) in an unencrypted format. This key, which is critical for securing communication between Kubernetes clusters, can be accessed by unauthorized parties. Such access enables an attacker to passively decrypt network traffic flowing between any two clusters in the mesh, resulting in sensitive information disclosure. | ||||
| CVE-2026-66780 | 1 Redhat | 2 Acm, Advanced Cluster Management For Kubernetes | 2026-10-19 | 6.5 Medium |
| A flaw was found in the submariner-operator component. The `submariner-k8s-broker-cluster` Role, which is assigned to joined clusters, possesses excessive permissions. This allows a compromised cluster to alter network configurations, specifically by overwriting other clusters' endpoint information. Consequently, an attacker can redirect inter-cluster tunnel traffic, enabling a Man-in-the-Middle (MITM) attack across the entire cluster mesh. | ||||
| CVE-2026-102477 | 1 Eclipse | 1 Vert.x | 2026-10-19 | N/A |
| In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], a gRPC endpoint does have a configurable per message maximum size in bytes, however the maximum size applies to the received bytes. When applied to a compressed message, this only applies to the compressed size and not the actual size of the uncompressed content. This can be used to force a gRPC endpoint to allocate more bytes than the value defined by the configuration, making the endpoint vulnerable to compression bomb attacks. The impacted component is io.vertx:vertx-gprc-server. | ||||
| CVE-2026-94228 | 1 Wordpress-extensions | 1 Truebooker | 2026-10-19 | 5.3 Medium |
| The TrueBooker WordPress plugin before 1.3.0 does not perform any capability check on one of its setup handlers, and the token it does check is issued to unauthenticated visitors, allowing anyone to overwrite the plugin's entire configuration and to discard any setting they do not supply. | ||||
| CVE-2026-94229 | 1 Wordpress-extensions | 1 Truebooker | 2026-10-19 | 5.3 Medium |
| The TrueBooker WordPress plugin before 1.3.0 does not verify that the requester owns a booking before rendering its confirmation summary, allowing unauthenticated attackers to enumerate booking identifiers and retrieve the personal information of customers who booked an appointment, as well as invalidate the customer's own confirmation link. | ||||
| CVE-2026-94230 | 1 Wordpress-extensions | 1 Truebooker | 2026-10-19 | 5.3 Medium |
| The TrueBooker WordPress plugin before 1.3.0 does not have authorisation checks in some of its AJAX actions, and does not validate the submitted service price server-side, allowing unauthenticated users to create bookings at a price of their choosing and to attach them to arbitrary customer accounts. | ||||
| CVE-2026-86589 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| Incorrect implementation of authentication algorithm vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. A flaw in the User Center login integration can cause a newly created external user session to omit its external identity, allowing subsequent requests to bypass central account suspension or deletion checks until the session expires or is revoked. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-85301 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 4.8 Medium |
| Improper Authentication vulnerability in Apache Camel Keycloak component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1. The security processor validated the issuer of an introspected token only when the introspection response actually carried an iss claim. When the claim was absent the check was skipped rather than treated as a failure, so a token that the configured issuer did not mint could be accepted provided the introspection endpoint answered without naming an issuer. Reaching this requires an introspection endpoint that omits iss and accepts tokens from more than one issuer, which is not the default Keycloak arrangement, hence the low severity; where that arrangement exists the consequence is that the deployment authenticates a caller it should have rejected. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check. For deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer. | ||||
| CVE-2026-85300 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 5.5 Medium |
| Incorrect Default Permissions vulnerability in Apache Camel PQC component. This issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1. When the component wrote generated key material to disk it did so with the permissions the process default umask produced, rather than restricting the file to its owner. On a host whose umask allows group or world read, the private key was therefore readable by other local accounts. The exposure is to a local party rather than to the remote sender that the Camel threat model treats as the primary adversary, which is why the severity is assessed low, but the consequence where it applies is complete: possession of the private key defeats every signature and key exchange the deployment performs with it. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Key material is now written with owner-only permissions. For deployments that cannot upgrade immediately, place the key directory on a path only the service account can traverse, and tighten the process umask. Key material already written with permissive permissions should be treated as exposed and rotated. | ||||
| CVE-2026-85312 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 4.8 Medium |
| Improper Input Validation vulnerability in Apache Camel Core component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The saga processor consulted a header named Long-Running-Action to decide which saga an exchange belonged to. The name carries no Camel prefix, so it sits outside the namespace that consumer header filters block, and an external sender could supply it on an inbound message. That let the sender name the saga the exchange joined, attaching their request to a long-running action started by someone else, or causing compensation to be associated with an action they did not initiate. The header is only consulted by a saga service that uses it, which bounds the exposure to deployments running sagas over an LRA coordinator. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange. For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders("Long-Running-Action") on every consumer that accepts messages from an untrusted sender. | ||||
| CVE-2026-85313 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 4.3 Medium |
| Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Jetty component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. Setting enableCORS on a Jetty endpoint installed Jetty's CrossOriginFilter with its stock defaults, which accept every origin and allow credentials. An operator asking for CORS therefore obtained a policy that lets a page on any origin make credentialed cross-origin requests to the endpoint and read the responses, without any indication that turning the option on had chosen an allow-all policy rather than an empty one to be filled in. This is the same defect class as the platform-http-vertx advisory published alongside it, in a different component. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly. For deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins. | ||||