SURIQ
Apache Camel, the integration framework that wires enterprise systems together, disclosed a flaw in its Solr connector that lets an outside web request walk past a security filter it was supposed to run into. Tracked as CVE-2026-48203, the bug sits in camel-solr, the component that forwards messages into an Apache Solr search server. Two vulnerability trackers cannot agree on how bad it is. The CISA-run assessment on the NVD record scores it 9.1 and calls it critical; Apache's own advisory rates it medium. That gap is the story, and resolving it tells you whether to move today or schedule the upgrade for this sprint.
Andrea Cosentino of the Camel project posted the advisory to the oss-security mailing list on July 5, crediting Yu Bao of PayPal for the report. On July 17 the same maintainer published a working reproducer that stands up a vulnerable route and demonstrates both halves of the bug. Nobody has reported exploitation in the wild, but a public reproducer moves the clock forward for everyone.
The bug is a header prefix that forgot to say "Camel"
Camel filters HTTP headers at the boundary between an inbound web request and the internal message it builds. The job of HttpHeaderFilterStrategy is to stop request headers from smuggling internal control values into a route, and it does that by blocking header names in the Camel and camel namespace. Anything named outside that namespace is treated as ordinary data and passed through.
The Solr connector named its control headers outside that namespace. It reads any inbound header whose name starts with SolrParam. and folds it into the outgoing Solr query, and any header starting with SolrField. into the document it indexes. Because neither prefix begins with Camel, the filter never touches it. So in a route that bridges an HTTP consumer into a solr producer, a remote client can set a header like SolrParam.shards or SolrParam.stream.url and make the Solr server issue requests to a location the attacker chooses. That is a server-side request forgery: the search server, not the attacker, makes the outbound call, from inside your network. The SolrField. half lets the same request write arbitrary fields into indexed documents, quietly corrupting search data.
Is it a 9.1 or a medium?
Both numbers are defensible, and the difference is entirely about your route topology. The 9.1 rating describes the worst reachable case: a route reachable over the network, needing no login and no user interaction, where an HTTP consumer like platform-http feeds a Solr producer with nothing authenticating the caller. In that shape any stranger on the network can drive the injection, and read or corrupt whatever the search server can touch, which is why the score runs high. Apache's medium reflects the more common reality, that many Camel deployments either do not expose such a bridge to untrusted callers or gate it behind authentication first.
So skip the argument over the label and answer the question that actually sets your risk: does an untrusted HTTP request reach a route that ends in a solr producer, and is the consumer in front of it unauthenticated? If yes, this is a critical you should treat as one. If the only people who can reach that route are already trusted, your exposure is real but lower, and a scheduled upgrade is a fair call. This is the same kind of credential-and-request exposure we walked through for the Grafana MCP server token leak: the CVSS number is a ceiling, and your own wiring decides how close you sit to it.
Affected and fixed versions
| Release stream | Affected | Upgrade to |
|---|---|---|
| 4.0.0 to 4.14.x (LTS) | below 4.14.8 | 4.14.8 |
| 4.15.0 to 4.18.x | below 4.18.3 | 4.18.3 |
| 4.19.0 to 4.20.x | below 4.21.0 | 4.21.0 |
The affected builds are everything below 4.14.8 on the long-term-support line, everything below 4.18.3 on the 4.18 line, and everything below 4.21.0 on the current line. Red Hat, which ships Camel in its own integration products, tracked the same issue in advisory RHSA-2026:17668, so enterprise consumers of those builds have a separate patch to pull.
Patch first, then rename the headers you actually use
Upgrade to 4.14.8 on the long-term-support line, 4.18.3 on the 4.18 line, or 4.21.0 on current. The fix moves the control prefixes into the filtered namespace, which has a side effect you have to plan for: after upgrading, any route that legitimately sets Solr parameters or fields through the raw prefixes must switch from SolrParam. and SolrField. to CamelSolrParam. and CamelSolrField.. Grep your route definitions for the old prefixes before you roll the upgrade, or those routes stop passing the values you meant to send.
If you cannot upgrade this week, the interim control is to strip any header matching SolrParam. or SolrField. from untrusted sources before the message reaches the solr producer, using a header-removal step in the route. Then hunt for signs the gap was used: audit which routes bridge an HTTP consumer into a Solr producer, and on the Solr side watch for outbound requests to hosts it has no business calling, the tell of an injected shards or stream.url, plus indexed documents carrying fields no legitimate client would write. A validation-time injection like this leaves thin forensic traces, so the durable signal is the anomalous outbound call and the unexpected document field, which is the kind of behavior a threat hunting program is meant to surface. Sequencing the upgrade against the rest of your queue by real exposure rather than the raw 9.1 is exactly what vulnerability detection done well is for.
The pattern is bigger than one connector
Camel's header filter is an allowlist keyed on a single word. It trusts that every control header a component cares about is named in the Camel namespace, and it lets everything else through as data. That assumption held only as long as every connector obeyed the naming convention, and camel-solr did not. Any other component that reads inbound headers under a non-Camel prefix has the same shape of exposure waiting in it. Camel's HTTP header handling was also at the root of a widely covered flaw in March 2025, which is a hint that the real work is not chasing each CVE but auditing which header prefixes are allowed to cross your HTTP boundaries at all. Fix this one by upgrading. Fix the class by treating your integration framework's header filter as a security boundary and checking what it actually lets past.