CVE-2026-43866 (GCVE-0-2026-43866)

Vulnerability from cvelistv5 – Published: 2026-07-06 08:35 – Updated: 2026-07-06 19:10
VLAI
Title
Apache Camel, Apache Camel: Camel JMS - CVE-2026-40860 fix bypass via DefaultExchangeHolder
Summary
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component. JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it. This issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes.
Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-07-06 19:09 UTC
CWE
  • CWE-502 - Deserialization of Untrusted Data
Assigner
apache CNA under the mitre root
CNA scorecard B 76/100 over 1078 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
Apache Software Foundation Apache Camel Affected: 3.0.0 , < 4.14.8 (semver)
Affected: 4.15.0 , < 4.18.3 (semver)
Affected: 4.19.0 , < 4.21.0 (semver)
guessed Create a notification for this product.
Credits
gaorenyusi Andrea Cosentino
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "LOW",
              "baseScore": 7.3,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "LOW",
              "integrityImpact": "LOW",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-43866",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-06T19:09:40.858071Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-06T19:10:00.576Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-jms",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.14.8",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.18.3",
              "status": "affected",
              "version": "4.15.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.21.0",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-sjms",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.14.8",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.18.3",
              "status": "affected",
              "version": "4.15.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.21.0",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "gaorenyusi"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eDeserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.\u003c/p\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eJmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it.\u003c/span\u003e\u003cbr\u003e\u003cp\u003eThis issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\u003c/p\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes.\u003c/span\u003e\u003cbr\u003e"
            }
          ],
          "value": "Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.\n\nJmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it.\nThis issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-502",
              "description": "CWE-502 Deserialization of Untrusted Data",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-06T08:35:04.935Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-43866.html"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel, Apache Camel: Camel JMS - CVE-2026-40860 fix bypass via DefaultExchangeHolder",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-43866",
    "datePublished": "2026-07-06T08:35:04.935Z",
    "dateReserved": "2026-05-04T11:44:06.700Z",
    "dateUpdated": "2026-07-06T19:10:00.576Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-43866",
      "date": "2026-10-27",
      "epss": "0.00654",
      "percentile": "0.51102"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "collectionURL": "https://repo.maven.apache.org/maven2",
                "defaultStatus": "unaffected",
                "packageName": "org.apache.camel:camel-jms",
                "product": "Apache Camel",
                "vendor": "Apache Software Foundation",
                "versions": [
                  {
                    "lessThan": "4.14.8",
                    "status": "affected",
                    "version": "3.0.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.18.3",
                    "status": "affected",
                    "version": "4.15.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.21.0",
                    "status": "affected",
                    "version": "4.19.0",
                    "versionType": "semver"
                  }
                ]
              },
              {
                "collectionURL": "https://repo.maven.apache.org/maven2",
                "defaultStatus": "unaffected",
                "packageName": "org.apache.camel:camel-sjms",
                "product": "Apache Camel",
                "vendor": "Apache Software Foundation",
                "versions": [
                  {
                    "lessThan": "4.14.8",
                    "status": "affected",
                    "version": "3.0.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.18.3",
                    "status": "affected",
                    "version": "4.15.0",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.21.0",
                    "status": "affected",
                    "version": "4.19.0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "security@apache.org"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "CA3AF588-FD31-49A3-A209-C6E4708CF12E",
                    "versionEndExcluding": "4.14.8",
                    "versionStartIncluding": "3.0.0",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "0AEE4159-4465-4ACD-B94A-1E4682C85270",
                    "versionEndExcluding": "4.18.3",
                    "versionStartIncluding": "4.15.0",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "1C2A1A7A-FADC-470F-8265-FA126AFD94ED",
                    "versionEndExcluding": "4.21.0",
                    "versionStartIncluding": "4.19.0",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.\n\nJmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it.\nThis issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes."
          },
          {
            "lang": "es",
            "value": "Vulnerabilidad de deserializaci\u00f3n de datos no confiables en Apache Camel, componente JMS de Apache Camel.\n\nJmsBinding.extractBodyFromJms() en camel-jms - y el JmsBinding equivalente en camel-sjms - deserializa la carga \u00fatil de un ObjectMessage JMS entrante a trav\u00e9s de jakarta.jms.ObjectMessage.getObject() siempre que la opci\u00f3n mapJmsMessage est\u00e9 habilitada (el valor predeterminado) y Camel act\u00fae como un consumidor JMS. El endurecimiento CVE-2026-40860 a\u00f1adi\u00f3 una verificaci\u00f3n de clase post-deserializaci\u00f3n que rechaza clases fuera de la lista de permitidos predeterminada java.;javax.;org.apache.camel.**;!*. Sin embargo, org.apache.camel.support.DefaultExchangeHolder en s\u00ed reside en el espacio de nombres org.apache.camel.** de la lista de permitidos, por lo que un ObjectMessage cuyo objeto de nivel superior es un DefaultExchangeHolder pasa la verificaci\u00f3n. El lado receptor luego llama a DefaultExchangeHolder.unmarshal() en \u00e9l sin requerir que la opci\u00f3n transferExchange est\u00e9 habilitada - un l\u00edmite de confianza asim\u00e9trico, ya que el lado emisor controla el manejo de ObjectMessage y transferExchange pero el lado receptor no lo hizo - escribiendo cada campo no nulo del contenedor en el Exchange: el cuerpo del mensaje, los encabezados IN y OUT, las propiedades del intercambio, las variables, el ID del intercambio y la excepci\u00f3n. Un atacante que puede publicar un ObjectMessage en una cola o tema consumido por una aplicaci\u00f3n Camel afectada puede, por lo tanto, inyectar un estado de Exchange arbitrario utilizando solo tipos java.lang y java.util universalmente confiables, sin requerir una cadena de gadgets de deserializaci\u00f3n, para manipular el enrutamiento y los encabezados, las propiedades del intercambio y el manejo de errores. El mismo manejo se aplica a camel-sjms y camel-sjms2, y a los componentes de la familia JMS construidos sobre JmsComponent y JmsBinding: camel-amqp, camel-activemq y camel-activemq6. Esto es un bypass de la correcci\u00f3n CVE-2026-40860 en lugar de un defecto en ella.\nEste problema afecta a Apache Camel: desde 3.0.0 antes de 4.14.8, desde 4.15.0 antes de 4.18.3, desde 4.19.0 antes de 4.21.0; Apache Camel: desde 3.0.0 antes de 4.14.8, desde 4.15.0 antes de 4.18.3, desde 4.19.0 antes de 4.21.0.\n\nSe recomienda a los usuarios actualizar a la versi\u00f3n 4.21.0, que corrige el problema. Si los usuarios est\u00e1n en la rama de versiones LTS 4.14.x, se sugiere que actualicen a 4.14.8. Si los usuarios est\u00e1n en la rama de versiones 4.18.x, se sugiere que actualicen a 4.18.3. Despu\u00e9s de la actualizaci\u00f3n, el manejo de ObjectMessage JMS est\u00e1 deshabilitado por defecto en camel-jms, camel-sjms y los componentes de la familia JMS (una nueva opci\u00f3n objectMessageEnabled por defecto es false a nivel de componente y de endpoint), por lo que un ObjectMessage entrante - incluyendo una carga \u00fatil de DefaultExchangeHolder - ya no se deserializa a menos que la opci\u00f3n est\u00e9 expl\u00edcitamente habilitada; solo establezca objectMessageEnabled=true cuando el destino JMS consumido sea alimentado exclusivamente por productores confiables. Para implementaciones que no pueden actualizarse inmediatamente, restrinja el acceso de publicaci\u00f3n a las colas y temas consumidos por Camel a productores confiables a trav\u00e9s de la autorizaci\u00f3n del broker JMS, y no exponga consumidores JMS que mapeen cuerpos de ObjectMessage a redes no confiables; una lista de permitidos de deserializaci\u00f3n del proveedor JMS no mitiga este bypass espec\u00edfico porque la carga \u00fatil creada utiliza solo clases universalmente confiables."
          }
        ],
        "id": "CVE-2026-43866",
        "lastModified": "2026-10-25T15:10:00.147",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "LOW",
                "baseScore": 7.3,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "LOW",
                "integrityImpact": "LOW",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 3.4,
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-43866",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-06T19:09:40.858071Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-07-06T09:16:35.913",
        "references": [
          {
            "source": "security@apache.org",
            "tags": [
              "Mitigation",
              "Vendor Advisory"
            ],
            "url": "https://camel.apache.org/security/CVE-2026-43866.html"
          }
        ],
        "sourceIdentifier": "security@apache.org",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-502"
              }
            ],
            "source": "security@apache.org",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Important",
      "current_release_date": "2026-08-13T22:02:59+00:00",
      "cve": "CVE-2026-43866",
      "id": "CVE-2026-43866",
      "initial_release_date": "2026-07-06T08:35:04.935000+00:00",
      "product_status:fixed": "1",
      "product_status:known_not_affected": "1",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43866.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "cvssV3_1": {
                  "attackComplexity": "LOW",
                  "attackVector": "NETWORK",
                  "availabilityImpact": "LOW",
                  "baseScore": 7.3,
                  "baseSeverity": "HIGH",
                  "confidentialityImpact": "LOW",
                  "integrityImpact": "LOW",
                  "privilegesRequired": "NONE",
                  "scope": "UNCHANGED",
                  "userInteraction": "NONE",
                  "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
                  "version": "3.1"
                }
              },
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-43866",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "yes"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-07-06T19:09:40.858071Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-07-06T19:09:56.676Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "collectionURL": "https://repo.maven.apache.org/maven2",
              "defaultStatus": "unaffected",
              "packageName": "org.apache.camel:camel-jms",
              "product": "Apache Camel",
              "vendor": "Apache Software Foundation",
              "versions": [
                {
                  "lessThan": "4.14.8",
                  "status": "affected",
                  "version": "3.0.0",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.18.3",
                  "status": "affected",
                  "version": "4.15.0",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.21.0",
                  "status": "affected",
                  "version": "4.19.0",
                  "versionType": "semver"
                }
              ]
            },
            {
              "collectionURL": "https://repo.maven.apache.org/maven2",
              "defaultStatus": "unaffected",
              "packageName": "org.apache.camel:camel-sjms",
              "product": "Apache Camel",
              "vendor": "Apache Software Foundation",
              "versions": [
                {
                  "lessThan": "4.14.8",
                  "status": "affected",
                  "version": "3.0.0",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.18.3",
                  "status": "affected",
                  "version": "4.15.0",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.21.0",
                  "status": "affected",
                  "version": "4.19.0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "finder",
              "value": "gaorenyusi"
            },
            {
              "lang": "en",
              "type": "remediation developer",
              "value": "Andrea Cosentino"
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003cp\u003eDeserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.\u003c/p\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eJmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it.\u003c/span\u003e\u003cbr\u003e\u003cp\u003eThis issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\u003c/p\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes.\u003c/span\u003e\u003cbr\u003e"
                }
              ],
              "value": "Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.\n\nJmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it.\nThis issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes."
            }
          ],
          "metrics": [
            {
              "other": {
                "content": {
                  "text": "important"
                },
                "type": "Textual description of severity"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-502",
                  "description": "CWE-502 Deserialization of Untrusted Data",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-07-06T08:35:04.935Z",
            "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
            "shortName": "apache"
          },
          "references": [
            {
              "tags": [
                "vendor-advisory"
              ],
              "url": "https://camel.apache.org/security/CVE-2026-43866.html"
            }
          ],
          "source": {
            "discovery": "UNKNOWN"
          },
          "title": "Apache Camel, Apache Camel: Camel JMS - CVE-2026-40860 fix bypass via DefaultExchangeHolder",
          "x_generator": {
            "engine": "Vulnogram 0.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "assignerShortName": "apache",
        "cveId": "CVE-2026-43866",
        "datePublished": "2026-07-06T08:35:04.935Z",
        "dateReserved": "2026-05-04T11:44:06.700Z",
        "dateUpdated": "2026-07-06T19:10:00.576Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.