Export limit exceeded: 10374 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (271 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-85314 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 6.5 Medium |
| Improper Input Validation vulnerability in Apache Camel Mail component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. CVE-2026-46584 addressed mail headers reaching the Exchange without passing through a header filter, but the MimeMultipart data format retained an unfiltered path: unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied. Those names sit outside the Camel namespace that consumer filters block, so a message crafted by an external sender could still set them, and the mail.smtp namespace influences how a downstream mail producer connects and sends. This is an incomplete fix of CVE-2026-46584 rather than a new class of defect: a deployment that applied that advisory and considered camel-mail settled remained exposed on this path. 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 MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open. For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders("mail.smtp*") before any mail producer. | ||||
| CVE-2026-85315 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 5.3 Medium |
| Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel gRPC component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. When a route behind a gRPC consumer failed, the exception's message was placed into the gRPC status description. Unlike the status cause, which stays local to the server, the description is transmitted to the calling client, so an external caller able to provoke a failure could read the internal error message. What that discloses depends on the exception, and in practice includes class and package names, paths, host names and connection detail carried in messages. This is the gRPC member of the same unmuted-consumer-exception family as the knative, mina and CXF advisories published alongside 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. A muteException consumer option, defaulting to true, puts a generic description in the status instead of the route exception's message. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, map failures onto an explicit status in an onException handler so the framework never copies the exception message into the description. | ||||
| CVE-2026-85316 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 4.8 Medium |
| Insufficient Granularity of Access Control vulnerability in Apache Camel Platform HTTP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The component decided whether an endpoint ran in proxy mode by testing whether its configured path started with the string proxy, rather than by matching the path exactly. Any endpoint whose path merely begins with those characters - proxyStatus, proxy-config, proxying and so on - therefore became a proxy endpoint without the route author asking for it. A proxy endpoint forwards requests onward, so an endpoint that was intended to serve its own content instead relays traffic on behalf of whoever calls it, which is both a request forgery primitive and an exposure of whatever the forwarding path can reach. 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. Proxy mode is now selected by an exact path match rather than by prefix. For deployments that cannot upgrade immediately, rename any endpoint path that begins with proxy but is not intended to be a proxy. | ||||
| CVE-2026-85317 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 4.8 Medium |
| Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low. 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 cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache. | ||||
| CVE-2026-64944 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. The importer stores imported question bodies as raw HTML without passing them through the normal Markdown-to-HTML sanitization path, so attacker-controlled HTML embedded in an imported data source is persisted and rendered to all viewers (including privileged users) as stored XSS. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-64945 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| A vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. The question operation controller gates hide/show operations on the wrong permission check result (the unpin permission instead of the hide permission), so in custom role configurations that separate these permissions, a user granted only question.unpin can hide or restore questions without holding question.hide or question.show. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-67249 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| A vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. A verification code issued for one email-based workflow could be accepted by another sensitive workflow because the code purpose was not properly enforced. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-79624 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| Insufficient session expiration vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Insufficient session invalidation allowed revoked users to continue accessing known private uploaded files with a stale visit token. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-76994 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Unauthenticated attackers could obtain metadata associated with hidden questions through public answer profiles. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-79613 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Unauthenticated attackers could access comments associated with non-public content through public user profiles. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-79620 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| Exposure of sensitive information through data queries vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. An improper authorization check in the similar-question search allowed authenticated users to view metadata of non-public questions. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-79633 | 2 Apache, Apache Software Foundation | 2 Answer, Apache Answer | 2026-10-19 | N/A |
| vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Missing authorization checks allowed authenticated users to perform actions on non-public content they were not permitted to access. Users are recommended to upgrade to version 2.0.3, which fixes the issue. | ||||
| CVE-2026-78162 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | N/A |
| Deserialization of Untrusted Data vulnerability in Apache Camel. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The camel-hazelcast component applies a default Hazelcast JavaSerializationFilterConfig to the instances it creates from its own configuration, a protection introduced by CVE-2026-43865. That change did not reach two of the configuration paths Camel builds itself, so those paths continued to create Hazelcast instances whose Java deserialization is unrestricted. ReplicatedHazelcastAggregationRepository extends HazelcastAggregationRepository but overrides doStart() without calling super.doStart(), keeping its own copy of the bootstrap block, and therefore never received the filter: a route using it without supplying a hazelcastInstance starts a Hazelcast member that deserializes values read from the backing ReplicatedMap with no class restriction. HazelcastDefaultComponent#getOrCreateHzClientInstance() builds its own ClientConfig when hazelcastMode=client is selected and neither a referenced ClientConfig nor hazelcastConfigUri is supplied, and likewise applied no filter, so client-mode endpoints behaved differently from node-mode endpoints for an otherwise identical configuration. In both cases an attacker able to publish into the Hazelcast cluster that the affected instance is attached to can cause a serialized Java object of their choosing to be deserialized inside Hazelcast's own serialization layer, before Camel processes the exchange, resulting in remote code execution. Hazelcast clusters have neither authentication nor TLS enabled by default. Selecting client mode is a topology choice rather than a security option, so neither path required the deployment to opt in to unsafe behaviour. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, supply an explicit Hazelcast configuration carrying a JavaSerializationFilterConfig, or inject a pre-built HazelcastInstance, since a user-supplied configuration is never overwritten by Camel. Alternatively set the JVM-wide filter -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* and enable Hazelcast cluster authentication and TLS to restrict who can reach the cluster. | ||||
| CVE-2026-84178 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 6.1 Medium |
| Cross-Site Request Forgery (CSRF) vulnerability in Apache Camel OAuth component. This issue affects Apache Camel: from 4.11.0 before 4.18.5, from 4.19.0 before 4.22.1. The authorization code callback did not carry a state parameter binding it to the authorization request that started the flow, and the callback did not verify one. An authorization code obtained in any browser could therefore be redeemed at the callback and associated with whichever session presented it, which is login cross-site request forgery: a victim can be silently signed in as an identity the attacker controls, so that actions the victim then performs, and data they then submit, land in the attacker's account. The same unvalidated callback handling also allowed the post-authentication redirect target to be influenced, giving an open redirect from a trusted origin. The state check runs before the authorization code is redeemed, so these paths are reachable without any interaction with the identity provider. 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 authorization request now issues a state value bound to the session, and the callback rejects a request whose state is absent or does not match, stopping the route with a 400 response. For deployments that cannot upgrade immediately, terminate the authorization code flow in a component that performs its own state binding rather than relying on the Camel callback. Note that after upgrading, a deployment behind a proxy that drops or rewrites the callback query string will begin to see 400 responses, because the state parameter must survive the round trip. | ||||
| CVE-2026-68571 | 2 Apache, Apache Software Foundation | 2 Apache Kylin, Apache Kylin | 2026-10-19 | 8.8 High |
| Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Kylin. Special parameter in JDBC URL can lead to code injection. Impact most to the kylin services that are directly exposed to public network, which is not common. In-house kylin deployments are mostly not impacted. This issue affects Apache Kylin: from 4 through 5.0.4. Users are recommended to upgrade to version 5.0.5, which fixes the issue. | ||||
| CVE-2026-63618 | 2 Apache, Apache Software Foundation | 2 Apache Kylin, Apache Kylin | 2026-10-17 | 7.5 High |
| Exposure of Sensitive Information (system level configuration info) to an Unauthorized Actor vulnerability in Apache Kylin. This issue affects Apache Kylin: from 4 through 5.0.4. Users are recommended to upgrade to version 5.0.5, which fixes the issue. | ||||
| CVE-2026-105111 | 1 Apache | 1 Apache Commons Bcel | 2026-10-09 | 4.7 Medium |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Apache Commons BCEL. This only happens when you're using Class2HTML to generate webpages for possibly-attacker-controlled class files, where Class2HTML emitters write attacker class-file strings into HTML unescaped (stored XSS in reports). This issue affects Apache Commons BCEL: before 6.13.0. Users are recommended to upgrade to version 6.13.0, which fixes the issue. | ||||
| CVE-2026-81862 | 1 Apache | 2 Airflow Teradata Provider, Apache-airflow-providers-teradata | 2026-10-07 | 6.5 Medium |
| Apache Airflow's Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket's credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured — which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator's control. The two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow's secrets masker — and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata's DBQL query logs and live monitoring views, where Airflow's masking never applies and the values persist for that system's log retention period. Affects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata's query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path. | ||||
| CVE-2026-81914 | 1 Apache | 2 Airflow Google Provider, Apache-airflow-providers-google | 2026-10-07 | 4.3 Medium |
| Apache Airflow's Google provider built Google Drive search expressions by interpolating file and folder names directly into single-quoted string literals, without escaping the quote character that delimits them. A name containing an apostrophe therefore terminated the literal early and appended clauses of the attacker's choosing to the query. The names are frequently not written by the Dag author. In a wildcard `gcs_to_gdrive` transfer they come from the source bucket listing, so anyone able to create objects in that bucket controls them — typically an external data producer or an ingest-only service account, a different trust principal from the Dag author. An injected clause can broaden the match and so steer which file or folder the hook resolves: an upload can be directed into a folder the attacker named, and, because downloads select the most recently modified match, a download can return a file they placed rather than the one the Dag asked for. Affects deployments passing externally-sourced names to the Google Drive hook, including wildcard `gcs_to_gdrive` transfers from buckets writable by less-trusted principals. Users are advised to upgrade to `apache-airflow-providers-google` `22.6.0` or later, which escapes quote and backslash characters in every value interpolated into a Drive query. | ||||
| CVE-2026-81930 | 1 Apache | 2 Airflow Snowflake Provider, Apache-airflow-providers-snowflake | 2026-10-07 | 6.3 Medium |
| Apache Airflow's Snowflake provider did not validate the connection's `account` and `region` fields before interpolating them into request URLs. The SQL API endpoint is built as `https://{account}.snowflakecomputing.com/api/v2/statements`, so an `account` value containing `/`, `?` or `#` demotes the intended domain to a path, query or fragment and leaves the attacker in control of the request host. The provider sends that request with an `Authorization: Bearer` header carrying a JWT minted from the connection's private key, or the configured OAuth or programmatic access token. A user who can edit the Snowflake connection but cannot read its secrets — Airflow gives connection-configuration users write-only access to stored credentials, and a `private_key_file` lives on the worker rather than in the connection — can therefore cause a valid token for the account to be delivered to a host of their choosing and replay it against the genuine Snowflake endpoint. No Dag-authoring ability is required: the attacker edits the connection and waits for an existing Dag to use it. The same unvalidated value was also used to build the OAuth token-request URL and the Cortex Agent base URL. Affects deployments where Snowflake connections are editable by users who are not trusted with the connection's credentials. Users are advised to upgrade to `apache-airflow-providers-snowflake` `6.18.0` or later, which rejects `account` and `region` values containing anything other than letters, digits, `.`, `_` and `-` in every URL the provider builds from them. | ||||