oscerd opened a new pull request, #26420:
URL: https://github.com/apache/camel/pull/26420
## What
Stops two message headers from steering security decisions in the
`camel-spiffe` producer.
## Why
`SpiffeProducer` read both the operation and the audience from the message
**in preference to** the endpoint configuration. Reproduced against a route
configured as a validator
(`operation=validateJwtSvid&audience=spiffe://example.org/my-service`) with a
mocked `WorkloadApiClient`:
```
configured audience = spiffe://example.org/my-service
VALIDATED AGAINST = spiffe://example.org/ATTACKER-CHOICE ←
CamelSpiffeAudience wins
OPERATION FLIPPED TO MINT = true ← body =
minted token,
validateJwtSvid never called
```
**The audience is the check, not a parameter.** For `validateJwtSvid` it is
what binds the token to *this* workload — the `aud` claim check. Letting the
message choose it means a JWT-SVID minted for a different service validates
successfully and the route treats the caller as authenticated. Same shape as
CAMEL-24281 / CVE-2026-66908, where platform-http-main did not enforce
`iss`/`aud`.
**A validator could be turned into a minter.** `CamelSpiffeOperation:
fetchJwtSvid` against a validator endpoint made the workload mint and return
its *own* JWT-SVID — a credential disclosure rather than just a bypass.
This is defense in depth rather than a reachable-by-default vulnerability: a
well-behaved consumer applies a `HeaderFilterStrategy` blocking `Camel*`, so
the obvious HTTP path is already closed. It matters because the component's
whole purpose is workload identity — and because the sibling component already
takes the safer position:
> The path is taken from the endpoint only: it is deliberately not
overridable by a message header, so an inbound message cannot pick which policy
judges it. — `OpaEndpoint#policyPath`
## What changed
- **`validateJwtSvid` uses the configured audience only.**
`CamelSpiffeAudience` is ignored for that operation.
- **`fetchJwtSvid` still honours the header** — minting a token for a named
audience is a genuine per-message parameter, and narrowing that would be a
pointless regression.
- **New `allowOperationHeader` option, default `false`,** gating
`CamelSpiffeOperation`. Marked `security = "insecure:dev"`, so it is picked up
by the security-policy framework — the generated `SecurityUtils` now carries
`allowoperationheader`, meaning `camel.main.profile=prod` will flag a route
that enables it.
- Header javadoc on `SpiffeConstants` updated so both constants state when
they are honoured, and a **Security notes** section added to the docs mirroring
`opa-component.adoc`.
One detail worth flagging: the "at least one audience is required" error
previously told the operator to set `CamelSpiffeAudience`. On the validation
path that header is now ignored, so the message is per-caller — pointing at a
header that does nothing would send someone down a dead end.
## Testing
Four new tests in `SpiffeHeaderOverrideTest`, covering both directions — the
header ignored where it is pinned, and still honoured where it is legitimate:
- validation ignores the audience header
- a fetch still honours it
- the operation header cannot turn a validator into a minter
- the operation header works when the route opts in
The two security-critical ones were confirmed to **fail with the fix
reverted**, then pass with it restored. The 7 pre-existing `SpiffeProducerTest`
cases are unchanged and still green. Full reactor build green, with the
catalog, both DSL mirrors and `SecurityUtils` regenerated.
`main` only. `camel-spiffe` is new in the unreleased 4.23.0, so no released
version is affected, no security advisory is needed, and the
`allowOperationHeader` default could be chosen freely.
_Claude Code on behalf of @oscerd_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
