Yesterday CVE-2026-33701 was
published: a critical (CVSS 9.3) deserialization flaw in the OpenTelemetry
Java agent (io.opentelemetry.javaagent:opentelemetry-javaagent before
2.26.1). If an application runs with the agent attached and exposes a JMX/RMI
management port, a crafted message can lead to remote code execution. The fix
is to upgrade the agent or disable its RMI integration.
Several people asked whether Vidocq applications are exposed through Humboldt, our MicroProfile Telemetry implementation. Short answer: no. Longer answer below — including the part that matters more than this one CVE.
Why this one doesn’t reach us
We audited every POM in the ecosystem. The vulnerable artifact — the instrumentation agent — appears nowhere: not in Humboldt, not in the runtime, not in any of the 16 families.
That is not luck; it is architecture. Humboldt implements the telemetry pipeline itself — tracing, metrics, logs, W3C propagation, OTLP/HTTP export — as regular build-time-wired Vidocq code. There is no bytecode agent, no runtime instrumentation, no RMI integration. Attaching the OpenTelemetry agent to a Vidocq application is neither needed nor recommended: telemetry is built in.
For completeness: our zero-dependency rule has a handful of documented
exceptions, and the OpenTelemetry API is one of them (applications code
against the standard opentelemetry-api, plus a pure-annotations jar for
@WithSpan). Those artifacts contain no instrumentation code and are not
involved in this CVE — but they are exactly the kind of thing we watch
advisories for, which is how this post came to exist.
The part we won’t gloss over
It would be easy to stop here and let "we rewrote everything, therefore we are safe" hang in the air. That would be dishonest.
Rewriting a stack from scratch does not make vulnerabilities disappear — it moves the responsibility for them onto us. Chappe parses HTTP/1.1, HTTP/2 and TLS records off the wire. Champollion parses attacker-supplied JSON. Cervantes validates JWTs. This is precisely the kind of code where CVEs are born, and ours has had fewer eyes on it than OpenTelemetry’s. One day, an advisory will carry a Vidocq component name, and when it does, there will be no upstream to point at.
What we can honestly claim is a different trade-off, not immunity:
-
A small, known attack surface. Zero runtime dependencies means the code that runs is code we wrote, reviewed and can patch in hours — not a transitive graph nobody fully reads. And the short list of exceptions is short enough to actually monitor.
-
A behavioural safety net. 1,868 MicroProfile 7.1 TCK tests and the Jakarta TCK suites run against the assembled runtime. TCKs are not security tests, but they pin behaviour down and catch whole classes of regressions.
-
A supply chain we can vouch for. Every commit on
mainis GPG-signed and server-verified, merges are fast-forward only through a signing bot, and contributions pass CLA/DCO/signature gates.
What we are putting in place
Finding our own vulnerabilities before others do is now an explicit workstream, not a hope:
-
a security policy (
SECURITY.md) in our governance repository, with a private disclosure channel — report first, publish after the fix; -
advisory monitoring on the few third-party artifacts we do ship;
-
adversarial testing where it hurts: fuzzing the protocol and format parsers (HTTP framing in Chappe, JSON in Champollion, JOSE handling in Cervantes) is at the top of that list;
-
and the same rule we apply to bugs and benchmarks: findings get tracked and published, not quietly patched.
If you believe you have found a security issue in any Vidocq component, please reach out privately to the maintainers rather than opening a public issue — the disclosure channel above will make that path explicit.
No triumphalism, then: this week the architecture did its job, and we will enjoy that for about a day. The real work is making sure that when the CVE has our name on it, we are the ones who found it first.
