The vulnerability arises when the Apache Camel JIRA component accepts non‑Camel‑prefixed message headers as operation parameters. Because these headers bypass the HTTP header filter, an HTTP client can set values such as IssueKey or ProjectKey without providing authentication. The attacker then causes the Jira producer to perform arbitrary operations—creating, deleting, transitioning, or modifying issues—using the service‑account credentials configured on the endpoint. The potential damage is limited only by the service account’s permissions; however, the ability to create or delete issues without any credentials can be critical, especially in environments using audit logs or compliance requirements. This flaw relies on improper input validation (CWE‑20) and an authorization bypass via user‑controlled input (CWE‑639).

Apache Camel JIRA component is affected across several release streams. For the 4.0.x series the issue exists from 4.0.0 up to but not including 4.14.8. In the 4.15.x series the vulnerability is present from 4.15.0 through 4.18.2, and in the 4.19.x series it exists from 4.19.0 through 4.20.9. Users on any of these streams should verify their current version against these ranges.

The EPSS score is reported as less than 1 %, indicating a very low probability of exploitation at present. The vulnerability is not listed in the CISA KEV catalog, but the lack of a need for credentials and the clear path from an unauthenticated HTTP consumer to JIRA operations make it a high‑impact concern for environments that expose the Camel JIRA bridge. The attack vector is an HTTP request to a route that bridges an unsecured consumer into the jira: producer, where the attacker supplies the vulnerable headers. If a service account has extensive permissions, the damage can be extensive. The risk is therefore governed more by the potential impact than by the likelihood indicated by EPSS.