Threat Intelligence Database

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (826e81131e7b2a296324d469c10f1e44d5b33683703c8a2e0f101a8674c1cfcf) The package impersonates the Tink open-banking SDK (name @tink/tink-link-core, description 'Enterprise-grade client core for open banking', homepage github.com/tink-link/core) but its actual behavior is host reconnaissance and DNS exfiltration. The package.json install script runs `node index.js`, and both the install entry and main entry load lib/core.js, which reads os.userInfo().username, os.hostname(), and process.cwd(), joins them with a prefix and a hardcoded domain as DNS labels, and issues a dns.resolve4() lookup. The destination hostname and module/API names are reconstructed at runtime from hex byte arrays via Buffer.from(...).toString('utf8') in lib/b02e30.js and lib/6ad264.js — the decoded domain is oob.algamil7x.xyz and the label prefix is tinkcore. Module names 'os','dns','process' and API names 'userInfo','hostname','cwd','resolve4' are loaded via module.constructor._load with hex-decoded strings to hide them from static review. DNS-based egress bypasses HTTP proxy and firewall controls. The beacon fires automatically on `npm install` (via the install lifecycle script) and again on `require()` of the package, giving the attacker installer username, hostname, and current working directory for every affected environment.

### Summary The OTLP log gRPC exporter loads TLS settings from environment variables but does not apply them when creating gRPC transport credentials. Operators who rely on `OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE`, `OTEL_EXPORTER_OTLP_CERTIFICATE`, or related client certificate variables for CA pinning or mTLS get a connection that falls back to system roots and omits the env-supplied client certificate. A network attacker who can intercept or spoof the collector connection with a system-trusted certificate can read or alter log telemetry. Introduced in commit: d99c76f ### Details The affected code is in `exporters/otlp/otlplog/otlploggrpc`. `newConfig` resolves env-based TLS configuration into `cfg.tlsCfg` at `exporters/otlp/otlplog/otlploggrpc/config.go:106-116`. The finding also identifies `loadEnvTLS` at `config.go:451-492` as the code that builds a `*tls.Config` containing `RootCAs` and client certificates from `OTEL_EXPORTER_OTLP[_LOGS]_CERTIFICATE` and `OTEL_EXPORTER_OTLP[_LOGS]_CLIENT_CERTIFICATE`/`KEY`. However, `newGRPCDialOptions` in `exporters/otlp/otlplog/otlploggrpc/client.go:83-92` only checks `cfg.gRPCCredentials` and `cfg.insecure`. When neither is set, which is the normal env-only TLS configuration path, it uses `credentials.NewTLS(nil)`. That default trusts the host system root CAs and contains no env-supplied client certificate. The finding evidence reports no other `tlsCfg` use in the package, so env-based CA pinning and mTLS settings are loaded but not enforced. ### PoC [validation-artifact.zip](https://github.com/user-attachments/files/27493589/validation-artifact.zip) The validation artifact contains a ready-to-run test at `validation-artifact.zip:./poc_env_tls_ignored_test.go` and brief instructions at `validation-artifact.zip:./README.md`. From a checkout of `pellared/opentelemetry-go` at commit `d99c76f`, with Go module dependencies available: ```sh FINDING_DIR=/path/to/02-e6e2897a969c8191b260f243fbc99ebd-log-grpc-exporter-ignores-env-tls-certs-bypassing-mtls-pinning cd /path/to/opentelemetry-go git checkout d99c76f tar -xOf validation-artifact.tar ./poc_env_tls_ignored_test.go > exporters/otlp/otlplog/otlploggrpc/poc_env_tls_ignored_test.go cd exporters/otlp/otlplog/otlploggrpc GO111MODULE=on go test -v -run TestEnvTLSIgnored -count=1 ``` The test generates a private CA and a TLS gRPC logs server certificate signed by that CA. It sets: ```sh OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://127.0.0.1:<test-port> OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE=<temp-dir>/ca.pem ``` Expected output includes an `unknown authority` failure for the first export call even though the env certificate points to the server CA, followed by a passing test after the same `cfg.tlsCfg` is explicitly wired through `WithTLSCredentials`: ```text === RUN TestEnvTLSIgnored poc_env_tls_ignored_test.go:...: export error (expected due to ignored tlsCfg): ... x509: certificate signed by unknown authority --- PASS: TestEnvTLSIgnored PASS ``` This demonstrates that the env CA is parsed into `cfg.tlsCfg` but ignored by the default gRPC dial path. ### Impact This is improper TLS certificate validation and endpoint authentication caused by ignoring configured trust material. Users of the OTLP log gRPC exporter who configure TLS, CA pinning, or mTLS through environment variables are impacted when they do not also supply explicit `WithTLSCredentials`. TLS still occurs with system roots, but the intended private CA pinning and client certificate authentication are bypassed. An attacker with a suitable network position and a system-trusted certificate for the collector endpoint can intercept or tamper with log telemetry that operators expected to be protected by the configured CA or mTLS policy.

### Summary OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK `TracerProvider` is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs. The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log. Exporter `MarshalLog` implementations that caused this configuration to be included in internal logs were introduced by [`a1fff3c`](https://github.com/open-telemetry/opentelemetry-go/commit/a1fff3c2588c783d1f3f6fd2315aa2660fc6d330). ### Details When `sdk/trace.NewTracerProvider` constructs a provider, it records a `TracerProvider created` internal Info event containing the provider configuration. In affected versions, the configuration's `MarshalLog` methods recursively include: 1. the provider's span processors; 2. each processor's span exporter; and 3. for the OTLP trace exporter, its client configuration. This causes the following values to be present in the event: - OTLP trace gRPC: the configured endpoint; - OTLP trace HTTP: the configured endpoint and the `Insecure` flag; and - Zipkin: the complete collector URL. OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with `otel.SetLogger`. The required `logr` verbosity is version-dependent: - versions 1.5.0 through 1.14.x use `V(1)` for this Info event; and - versions 1.15.0 through 1.44.0 use `V(4)`. OTLP header configuration is not part of the marshaled object, so credentials supplied with `WithHeaders` or the corresponding environment variables are not exposed. The documented OTLP `WithEndpoint` input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format. ### Proof of concept The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging: ```go package main import ( "bytes" "context" "fmt" "github.com/go-logr/logr/funcr" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/zipkin" sdktrace "go.opentelemetry.io/otel/sdk/trace" ) func main() { var logs bytes.Buffer otel.SetLogger(funcr.New(func(_, args string) { _, _ = logs.WriteString(args) }, funcr.Options{Verbosity: 4})) exporter, err := zipkin.New( "http://user:[email protected]:9411/api/v2/spans?token=secret", ) if err != nil { panic(err) } tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter)) _ = tp.Shutdown(context.Background()) fmt.Println(logs.String()) } ``` The `TracerProvider created` event contains: ```text http://user:[email protected]:9411/api/v2/spans?token=secret ``` For versions before 1.15.0, set `funcr.Options{Verbosity: 1}` instead. ### Impact This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs. There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path. ### Remediation Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in [`3a1412d`](https://github.com/open-telemetry/opentelemetry-go/commit/3a1412d2b3bc4e4231fbeac2ed42117ae541bb38) stops recursively marshaling exporter and client configuration and records their types instead. If an immediate upgrade is not possible: - keep OpenTelemetry internal logging below the Info verbosity described above; - do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and - restrict access to existing logs and rotate any credentials that may already

## Summary Steeltoe's Consul discovery client parses the `secure` metadata field on each registered service instance using `bool.Parse`, which throws on any value other than `true` or `false`. A single service instance registered with a malformed `secure` value (for example `yes` or `1`) aborts construction of the entire instance list for that service, making the service undiscoverable. When `GetAllInstancesAsync` is used, one malformed instance in any service can abort enumeration across all services. This is the same "one malformed field aborts the whole batch" availability class as [CVE-2026-50196](https://github.com/advisories/GHSA-j8ph-6fxj-g533), but affecting the Consul discovery client. ## Impact Any principal that can register a service in the Consul catalog can trigger a service-discovery outage for all Steeltoe applications resolving that service. The outage affects all instances of the targeted service — not just the malformed one — and persists until the offending registration is removed. ## Affected configuration - Application uses `ConsulDiscoveryClient` (any deployment). - The Consul catalog contains at least one service instance with a `secure` metadata value that is not `true` or `false`. - Mixed-platform environments where non-.NET clients register services with non-standard metadata values are more likely to encounter this condition. ## Mitigations If an immediate upgrade is not possible: - Audit the Consul catalog for service registrations with non-standard `secure` metadata values. - Restrict write access to the Consul service registration API to trusted services.

## Summary Steeltoe's Eureka discovery client deserializes the registry response as a single unit. If any registered instance contains a field value that cannot be parsed (for example, an unrecognized `actionType`, a non-boolean value for `isCoordinatingDiscoveryServer`, or a non-numeric timestamp), deserialization of the entire registry fails. All Steeltoe Eureka clients connected to that registry then receive an empty or stale instance list until the malformed registration is removed. This is a related but distinct issue from [CVE-2026-50196](https://github.com/advisories/GHSA-j8ph-6fxj-g533), which addressed only the `DataCenterInfo.name` field. ## Impact Any principal that can register or update a service instance in the Eureka registry can trigger a service-discovery outage for all Steeltoe applications connected to the same registry. The outage persists until the offending registration is removed. ## Affected configuration * Application uses `EurekaDiscoveryClient` (any deployment, including self-hosted Eureka). * The registry contains at least one service instance with an unrecognized value in a field such as `actionType`, `status`, `isCoordinatingDiscoveryServer`, or timestamp fields. * Mixed-platform environments — for example, Java or Spring services co-existing in the same Eureka registry — are more likely to encounter this condition. ## Mitigations If an immediate upgrade is not possible: * Audit the Eureka registry for registrations containing non-standard field values, particularly those originating from non-.NET clients. * Restrict write access to the Eureka registration API to trusted services.

The NeuVector admission webhook silently excludes containers from policy evaluation when their image path matches one of three hardcoded service mesh sidecar images. Since the image path is entirely controlled by the workload author, any user capable of deploying workloads can evade admission deny rules simply by naming their image path after one of these sidecar images.

Authorised users of outside applications behind the same corporate identity provider (IdP), for example, a wiki, a ticketing system, an expenses tool, or anything they legitimately hold an account on can log into their system via SAML SSO. The IdP issues an assertion to them. If that assertion is presented to NeuVector, NeuVector accepts it because the only thing distinguishing "an assertion for NeuVector" from "an assertion for the wiki" is the element, and the `NotInAudience` warning that reports the mismatch is never read.

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.18.55. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:65852 Security Fix(es): * github.com/cri-o/cri-o: Fix Bypass for CVE-2022-4318 — /etc/passwd Injection via HOME env (CVE-2026-15809) * github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object (CVE-2026-34986) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.18 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html-single/updating_clusters/index#updating-cluster-cli.

Collector with the supported components for a Red Hat build of OpenTelemetry Security Fix(es): * net/mail: golang: net/mail: Denial of Service via pathological email address parsing (CVE-2026-42499) * net/mail: golang: Go net/mail: Denial of Service via crafted email inputs (CVE-2026-39820) * mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * github.com/open-telemetry/opentelemetry-go: go.opentelemetry.io/otel/baggage: go.opentelemetry.io/otel/propagation: OpenTelemetry-Go: Denial of Service via oversized baggage headers (CVE-2026-41178) * encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818) * net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860) * net/http: golang: Go net/http: Unencrypted HTTP/2 connections vulnerable to Denial of Service (CVE-2026-56853) * html/template: golang: Go html/template: Cross-Site Scripting via pathological input (CVE-2026-56858) * crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862) * encoding/xml: golang: Go: Denial of Service via XML decoding recursion depth issue (CVE-2026-56859) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Collector with the supported components for a Red Hat build of OpenTelemetry Security Fix(es): * net/mail: golang: net/mail: Denial of Service via pathological email address parsing (CVE-2026-42499) * net/mail: golang: Go net/mail: Denial of Service via crafted email inputs (CVE-2026-39820) * mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * github.com/open-telemetry/opentelemetry-go: go.opentelemetry.io/otel/baggage: go.opentelemetry.io/otel/propagation: OpenTelemetry-Go: Denial of Service via oversized baggage headers (CVE-2026-41178) * encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818) * net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860) * net/http: golang: Go net/http: Unencrypted HTTP/2 connections vulnerable to Denial of Service (CVE-2026-56853) * html/template: golang: Go html/template: Cross-Site Scripting via pathological input (CVE-2026-56858) * crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862) * encoding/xml: golang: Go: Denial of Service via XML decoding recursion depth issue (CVE-2026-56859) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.