https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 17:18:52 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-66908 <p>Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.</p> <p>This issue affects Apache Camel: from 4.8.0 before 4.22.0.</p> <p>The camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token le…</p> <p>Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.</p> <p>This issue affects Apache Camel: from 4.8.0 before 4.22.0.</p> <p>The camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token le…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-66908 https://vulnerability.circl.lu/vuln/ghsa-fpm2-m4qq-wghr <p><strong>Affected:</strong> Maven: org.apache.camel:camel-platform-http-main</p> <p>Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.</p> <p>This issue affects Apache Camel: from 4.8.0 before 4.22.0.</p> <p>The camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legiti…</p> <p><strong>Affected:</strong> Maven: org.apache.camel:camel-platform-http-main</p> <p>Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.</p> <p>This issue affects Apache Camel: from 4.8.0 before 4.22.0.</p> <p>The camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legiti…</p> https://vulnerability.circl.lu/vuln/ghsa-fpm2-m4qq-wghr https://vulnerability.circl.lu/vuln/rhsa-2026:71675 <p>jetty-security: Eclipse Jetty: Authentication bypass via Digest authentication encoding collision jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections org.bouncycastle/bc-java: org.bouncycastle/bc-lts-java: Bouncy Castle for Java: Cryptographic signature bypass in RSA PKCS#1 verification vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects camel-jms: camel-sjms: camel-amqp: camel-mina: camel-netty: camel-netty-http: camel-vertx-http: camel-infinispan: camel-leveldb: camel-cassandraql: camel-consul: camel-sql: Apache Camel: Information disclosure via deserialization of untrusted data camel-aws2-sqs: Apache Camel: Camel-AWS2-SQS: Inbound message attributes are mapped into the Exchange without an inbound HeaderFilterStrategy, allowing a message sender to inject Camel control headers camel-nats: Apache Camel: Camel-NATS: Inbound NATS message headers are mapped into the Exchange without a configured HeaderFilterStrategy, allowing a client that can publish to the subject to inject Camel control headers camel-solr: Apache Camel: Camel-Solr: The SolrParam. and SolrField. Exchange header prefixes used non-Camel-prefixed names that bypass the HTTP header filter, allowing an HTTP client to inject Solr query parameters (server-side request forgery) and document fields org.apache.sshd/sshd-core: Apache MINA SSHD: Unauthorized command execution due to improper certificate validation org.apache.cxf/cxf:…</p> <p>jetty-security: Eclipse Jetty: Authentication bypass via Digest authentication encoding collision jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections org.bouncycastle/bc-java: org.bouncycastle/bc-lts-java: Bouncy Castle for Java: Cryptographic signature bypass in RSA PKCS#1 verification vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects camel-jms: camel-sjms: camel-amqp: camel-mina: camel-netty: camel-netty-http: camel-vertx-http: camel-infinispan: camel-leveldb: camel-cassandraql: camel-consul: camel-sql: Apache Camel: Information disclosure via deserialization of untrusted data camel-aws2-sqs: Apache Camel: Camel-AWS2-SQS: Inbound message attributes are mapped into the Exchange without an inbound HeaderFilterStrategy, allowing a message sender to inject Camel control headers camel-nats: Apache Camel: Camel-NATS: Inbound NATS message headers are mapped into the Exchange without a configured HeaderFilterStrategy, allowing a client that can publish to the subject to inject Camel control headers camel-solr: Apache Camel: Camel-Solr: The SolrParam. and SolrField. Exchange header prefixes used non-Camel-prefixed names that bypass the HTTP header filter, allowing an HTTP client to inject Solr query parameters (server-side request forgery) and document fields org.apache.sshd/sshd-core: Apache MINA SSHD: Unauthorized command execution due to improper certificate validation org.apache.cxf/cxf:…</p> https://vulnerability.circl.lu/vuln/rhsa-2026:71675