Apache Camel JIRA CVE-2026-48206

Exploitation requires three concurrent conditions to all be true simultaneously. First, the target Apache Camel application must include the camel-jira component at an affected version (4.0.0-4.14.7, 4.15.0-4.18.2, or 4.19.0-4.20.x). Second, a Camel route must be configured to connect an HTTP consumer endpoint (such as platform-http, camel-servlet, or any HTTP-based consumer) upstream of a jira: producer - this HTTP-to-JIRA bridging pattern is the indispensable deployment prerequisite; Camel applications that use camel-jira without an HTTP consumer in the same route are not exploitable via this vector. Third, the HTTP consumer endpoint must be reachable by the attacker, and when the consumer is unauthenticated, no attacker credentials are required whatsoever; if the consumer requires authentication, the attacker must possess valid credentials for that consumer (reducing but not eliminating risk, since authenticated but lower-privileged users could still drive elevated JIRA operations). What limits exploitation: the set of JIRA operations available to the attacker is strictly bounded by the permissions of the configured JIRA service account and cannot be escalated beyond those permissions; the attacker must know or guess valid JIRA identifiers (issue keys in the format PROJECT-NNN, project keys, transition IDs); and deployments where the HTTP consumer is on a private network inaccessible to external clients are not reachable by external attackers.

No CVSS vector was provided by the Apache Camel security team or NVD at time of analysis; the vulnerability is designated MODERATE severity by the project. Real-world risk is conditional on a specific architectural pattern and is best understood through that lens. When an Apache Camel application exposes an unauthenticated HTTP consumer endpoint bridged directly to a jira: producer - a not-uncommon integration pattern in enterprise automation - the attack requires no credentials, no special tooling, and only basic knowledge of HTTP headers, making exploitation trivially low-complexity. The impact ceiling is bounded by the configured service account's JIRA permissions, but service accounts used for automation are frequently granted broad project-level access, meaning the practical impact could include bulk issue manipulation or data corruption. The vulnerability is absent from CISA KEV, no public proof-of-concept code has been identified, and EPSS data is unavailable, suggesting exploitation has not been observed at scale. The risk is substantially lower for deployments where the HTTP consumer requires authentication, operates on a private network, or does not front a jira: producer. The conditional nature of exploitation (the bridging route must exist and the consumer must be accessible to the attacker) means this is a genuine moderate-priority issue for affected architectures rather than an emergency for all Apache Camel users.

An attacker identifies a publicly reachable Apache Camel platform-http endpoint that bridges to a jira: producer in an enterprise integration environment. They send an HTTP POST request augmented with headers 'IssueKey: SEC-412' and 'IssueTransitionId: 31', which pass through HttpHeaderFilterStrategy unfiltered and propagate into the Exchange, causing the JIRA producer to transition issue SEC-412 to 'Resolved' using the service account's credentials - with no authentication from the attacker. No public exploit code has been identified, but the attack requires only an HTTP client and knowledge of valid JIRA issue keys, which are typically predictable sequential strings (e.g., PROJ-1, PROJ-2) and may be discoverable via JIRA's public REST API or prior access.