Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel JIRA component.
The camel-jira producers read their operation parameters - the issue key, project key, transition id, summary, type, assignee, components, watchers, link type, work-log minutes and others - from Exchange message headers. The header constants defined in JiraConstants (for example ISSUE_KEY = IssueKey, ISSUE_PROJECT_KEY = ProjectKey, ISSUE_TRANSITION_ID = IssueTransitionId, LINK_TYPE = linkType) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a jira: producer, any HTTP client could therefore supply these headers and override the values the route intended, driving JIRA operations against the configured JIRA instance with the endpoint's configured service-account credentials - for example deleting or transitioning an arbitrary issue (via IssueKey / IssueTransitionId), creating an issue in a different project (via ProjectKey), modifying issue fields, adding or removing watchers, or logging work. The operations are bounded by what the configured service account is permitted to do. No credentials are required from the attacker when the bridging consumer is unauthenticated.
This issue affects Apache Camel: from 4.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, routes that drive JIRA operations via the raw header names must use the CamelJira* names (for example CamelJiraIssueKey) instead of the old values. For deployments that cannot upgrade immediately, strip the camel-jira control headers from any untrusted ingress before the jira: producer (for example removing the IssueKey, ProjectKey, IssueTransitionId and related headers at the start of the route), and set the required JIRA operation parameters from a trusted source.
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
The EG score (5.3): severity, escalated by confirmed exploitation. This CVE's 5.3 is its impact severity (EG Severity), not escalated.
- EG Severity
- 5.3 MEDIUMCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.GitHub Security Advisory CVSS
- EG Likelihood
- 0.6% within 30 daysSource: FIRST EPSS (model v2026.06.15, score date 2026-10-24). FIRST's exploitation probability, not an EchelonGraph model.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- SSVC Track at medium mission impactTrack at low or medium mission impact; Attend at high (mission-essential systems).CISA BOD 26-04: 14 days if the affected system is publicly exposed; 60 days if it is not.Each input and its source, and whom BOD 26-04 binds: the SSVC and BOD 26-04 blocks below.
SSVC (CISA's decision table, applied by EchelonGraph)Track at low or medium mission impact; Attend at high (mission-essential systems).
A fix is available. Apply it within your standard update timelines at low or medium mission impact and sooner than that at high.
Exploitation none (CISA Vulnrichment) · Automatable yes (CISA Vulnrichment) · Technical impact partial (CISA Vulnrichment). All three are CISA's SSVC values (Vulnrichment). EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table
BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; 60 days if it is not.
The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable yes (CISA Vulnrichment) · Technical impact partial (CISA Vulnrichment). Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it