OpenTelemetry.Exporter.Instana CVE-2026-44213
MEDIUMSeverity by source
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
Network MitM requires positioning on proxy path (AC:H) with no credentials (PR:N); primary impact is confidentiality of API key and telemetry, not integrity.
Primary rating from Vendor (https://github.com/open-telemetry/opentelemetry-dotnet-contrib).
CVSS VectorVendor: https://github.com/open-telemetry/opentelemetry-dotnet-contrib
Lifecycle Timeline
3DescriptionCVE.org
Summary
The OpenTelemetry.Exporter.Instana NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the INSTANA_ENDPOINT_PROXY environment variable.
If a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker.
Details
The Transport.ConfigureBackendClient() method creates an HttpClient instance that completely disables TLS server certificate validation if the INSTANA_ENDPOINT_PROXY is configured with a valid proxy URL with no ability to re-enable it.
Impact
If the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process' configuration to be changed to add an attacker-provided value for INSTANA_ENDPOINT_PROXY then all Instana telemetry could be read by an unauthorized party and the service's Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address.
Mitigation
The proxy configured by the INSTANA_ENDPOINT_PROXY environment variable must be malicious or be possible to be subject to a MitM attack.
Workarounds
Do not configure the INSTANA_ENDPOINT_PROXY environment variable.
Remediation
#4153 refactors HttpClient creation so that TLS certificate validation is no longer disabled by default when using a proxy.
In environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option:
builder.AddInstanaExporter((options) =>
{
options.HttpClientFactory = () =>
{
var handler = new HttpClientHandler()
{
#if NET
ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,
#else
ServerCertificateCustomValidationCallback = static (_, _, _, _) => true,
#endif
};
return new HttpClient(handler, disposeHandler: true);
};
});Resources
AnalysisAI
TLS certificate validation is unconditionally disabled in the OpenTelemetry.Exporter.Instana NuGet package (versions <= 1.0.7) whenever the INSTANA_ENDPOINT_PROXY environment variable is set to any valid proxy URL, exposing all outbound telemetry and the Instana API key to network-level man-in-the-middle interception. The Transport.ConfigureBackendClient() method hard-codes this insecure behavior with no mechanism for callers to re-enable validation without upgrading. No public exploit has been identified and EPSS is negligible (0.01%, 0th percentile), but successful exploitation yields silent, persistent credential and observability data theft.
Technical ContextAI
The affected component is pkg:nuget/opentelemetry.exporter.instana, a .NET contrib package that exports OpenTelemetry spans to IBM Instana backends. The root cause is CWE-295 (Improper Certificate Validation): the Transport.ConfigureBackendClient() method at src/OpenTelemetry.Exporter.Instana/Implementation/Transport.cs lines 132-158 creates an HttpClient instance with ServerCertificateCustomValidationCallback set to unconditionally return true whenever INSTANA_ENDPOINT_PROXY contains a valid proxy URL. This bypass is hardcoded - consumers of the package cannot re-enable validation. All telemetry traffic and the bearer API key transmitted to the Instana backend traverse this unvalidated TLS channel, making any proxy endpoint or network hop between the application and the proxy a viable interception point.
RemediationAI
Upgrade to OpenTelemetry.Exporter.Instana version 1.1.0, which was released to address this issue via PR #4153 (https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153), refactoring HttpClient creation so TLS certificate validation is enabled by default when using a proxy. As an immediate workaround with no code change required, remove the INSTANA_ENDPOINT_PROXY environment variable from all deployment configurations - this prevents the vulnerable code path from executing entirely; the trade-off is that proxy-dependent network paths for Instana telemetry will no longer function. After upgrading, rotate the Instana API key as a precaution if INSTANA_ENDPOINT_PROXY was previously configured, since any key transmitted through a compromised proxy may already be stolen. If proxy bypass is legitimately required for local development after upgrading to 1.1.0, the advisory documents an opt-in HttpClientFactory pattern using DangerousAcceptAnyServerCertificateValidator that should be restricted to non-production environments only.
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-wfr5-454p-mjc2