<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T17:18:51.173814+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-66908</id>
    <title>fkie_cve-2026-66908</title>
    <updated>2026-09-28T17:18:51.208216+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-66908"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-fpm2-m4qq-wghr</id>
    <title>GHSA-fpm2-m4qq-wghr — Apache Camel-platform-http-main: when JWT authentication was configured with a keystore but no issuer or audience, the…</title>
    <updated>2026-09-28T17:18:51.208356+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-fpm2-m4qq-wghr"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/rhsa-2026:71675</id>
    <title>RHSA-2026:71675 — Red Hat Security Advisory: Red Hat Build of Apache Camel 4.18.4 for Spring Boot release.</title>
    <updated>2026-09-28T17:18:51.208444+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <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>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/rhsa-2026:71675"/>
  </entry>
</feed>
