This is an automated email from the ASF dual-hosted git repository. oscerd pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/camel-website.git
commit 02a30df1c7f31416277916214d05e0f44f62f365 Author: Andrea Cosentino <[email protected]> AuthorDate: Fri Sep 4 09:09:41 2026 +0200 Added CVE-2026-85245 Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_013qz9ir11vuQYfQApzwHAHD Signed-off-by: Andrea Cosentino <[email protected]> --- content/security/CVE-2026-85245.md | 21 ++++++++++++++++++++ content/security/CVE-2026-85245.txt.asc | 35 +++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+) diff --git a/content/security/CVE-2026-85245.md b/content/security/CVE-2026-85245.md new file mode 100644 index 00000000..a320d090 --- /dev/null +++ b/content/security/CVE-2026-85245.md @@ -0,0 +1,21 @@ +--- +title: "Apache Camel Security Advisory - CVE-2026-85245" +date: 2026-08-31T10:00:00+02:00 +url: /security/CVE-2026-85245.html +draft: false +type: security-advisory +cve: CVE-2026-85245 +severity: MEDIUM +summary: "Camel-Thrift: cross-exchange data disclosure - unmarshalling deserialized into the shared defaultInstance rather than a copy, so fields set by one message remained visible to the next" +description: "The Thrift data format unmarshalled incoming data into the shared defaultInstance of the target type rather than into a fresh copy, and returned that shared object as the exchange body. Because the instance is shared process-wide, state written while unmarshalling one message stayed on the object and was visible to every later message that used the same type. Fields absent from a later payload retained the previous message's values, so content belonging to one sender could [...] +mitigation: "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. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages. For deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to th [...] +credit: "This issue was discovered by Claude Security Scan Tool" +affected: "From 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1." +fixed: 4.18.5, 4.22.1 and 4.23.0 +--- + +The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24442 refers to the various commits that resolved the issue, and has more details. + +The fix was merged on main in https://github.com/apache/camel/pull/25823 (commit c52d3cfa1c343a49261d77a5213dba92244a38f6), backported to camel-4.22.x in https://github.com/apache/camel/pull/25940 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb) and to camel-4.18.x in https://github.com/apache/camel/pull/25942 (commit af1efbcccf5882b1ef0094db718972da3190e7e9). + +The issue is classified as CWE-488 Exposure of Data Element to Wrong Session. The camel-4.14.x line reached end of life before this fix and does not receive it; deployments on 4.14.x should move to 4.18.5 or later. diff --git a/content/security/CVE-2026-85245.txt.asc b/content/security/CVE-2026-85245.txt.asc new file mode 100644 index 00000000..5797802c --- /dev/null +++ b/content/security/CVE-2026-85245.txt.asc @@ -0,0 +1,35 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA512 + +- --- +title: "Apache Camel Security Advisory - CVE-2026-85245" +date: 2026-08-31T10:00:00+02:00 +url: /security/CVE-2026-85245.html +draft: false +type: security-advisory +cve: CVE-2026-85245 +severity: MEDIUM +summary: "Camel-Thrift: cross-exchange data disclosure - unmarshalling deserialized into the shared defaultInstance rather than a copy, so fields set by one message remained visible to the next" +description: "The Thrift data format unmarshalled incoming data into the shared defaultInstance of the target type rather than into a fresh copy, and returned that shared object as the exchange body. Because the instance is shared process-wide, state written while unmarshalling one message stayed on the object and was visible to every later message that used the same type. Fields absent from a later payload retained the previous message's values, so content belonging to one sender could [...] +mitigation: "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. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no state carries between messages. For deployments that cannot upgrade immediately, copy the unmarshalled body into a new instance immediately after the data format runs, and do not retain references to th [...] +credit: "This issue was discovered by Claude Security Scan Tool" +affected: "From 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1." +fixed: 4.18.5, 4.22.1 and 4.23.0 +- --- + +The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24442 refers to the various commits that resolved the issue, and has more details. + +The fix was merged on main in https://github.com/apache/camel/pull/25823 (commit c52d3cfa1c343a49261d77a5213dba92244a38f6), backported to camel-4.22.x in https://github.com/apache/camel/pull/25940 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb) and to camel-4.18.x in https://github.com/apache/camel/pull/25942 (commit af1efbcccf5882b1ef0094db718972da3190e7e9). + +The issue is classified as CWE-488 Exposure of Data Element to Wrong Session. The camel-4.14.x line reached end of life before this fix and does not receive it; deployments on 4.14.x should move to 4.18.5 or later. +-----BEGIN PGP SIGNATURE----- + +iQEzBAEBCgAdFiEEJ2Y0ButtuvUpHyYV406fOAL/QQAFAmqabrUACgkQ406fOAL/ +QQDnrQf9GSy1Qtmfph5Z4MfmdCJNOHqU1YBulGbioq0ohJDkab2MNpA0kH18MayA +VsoeLG0/8/xhcI2ga+KduUsGb8CPgivpHJsJ+vFl9TjfJ0gPI2O6g6owsUR5FJnA +V/u6997hVqx8J9jGB0dijQZfDPyV4+RwMvbDjpEJTq0gtazeMO3SBLysr7bSpoW3 +dHIz9yUIFhGYtqkBUVGrBlvAVEYfhVpIDB8QT3AlM9D+tW8r4q9OaAOsvslLpRd5 +rbdBrv840WS4n59o/49cNXOI1UNjBBvLjghIc8KBmADsfz+nVIlV8Ft2z8LlVDrQ +0vM7ZDsUg49HT3kyz8AzJoNIvnUh7w== +=/zyo +-----END PGP SIGNATURE-----
