Monthly
Unauthenticated attackers who know a registered device's serial number can obtain that device's MDM client certificate and private key from OCO-Server's Apple MDM enrollment endpoint and then impersonate the device on all subsequent MDM traffic. The /api-mdm.php/profile handler verifies enrollment plists with openssl_pkcs7_verify(..., PKCS7_NOVERIFY, ...), so an arbitrary self-signed certificate satisfies the check and the SERIAL/UDID claims in the payload are trusted without being bound to the signer; the response returns a PKCS#12 bundle containing a certificate with CN=<serial> issued by the server's internal MDM device CA together with its private key, and the victim's mobile_device row is overwritten with the attacker-chosen UDID. Affects OCO-Server 1.2.0 through 1.2.2 (the MDM feature was introduced in 1.2.0); version 1.2.3 fixes the issue. Reported by GitHub_M and rated act_now by vuln.today priority; no public exploit identified at time of analysis, active exploitation is not confirmed, and the reporter states a proof of concept and full reproduction evidence were offered privately under coordinated disclosure.
Man-in-the-middle interception and modification of NT OneAPP client-server communications is possible because the application fails to validate both the server certificate and hostname. Network-adjacent, unauthenticated attackers who already hold a position on the traffic path - such as a rogue Wi-Fi access point or compromised LAN segment - can present an arbitrary certificate and read or alter sessions. No public exploit was identified at time of analysis, and exploitation is bounded by the requirement to intercept live traffic; the independent assessment rates this as adjacent-network, high-complexity, with high confidentiality and integrity impact.
TLS client-configuration reuse in Traefik Proxy 2.11.0 through 2.11.57 and 3.0.0 through 3.7.13 allows an unauthenticated client to bypass a backend service's configured root CAs, SNI/server name, and certificate verification. When one backend issues an NTLM or Negotiate (Kerberos) challenge, Traefik stores the resulting round tripper in a client-connection slot that is not keyed by ServersTransport; an attacker who arms that slot can then reach a different service over the same keep-alive connection and inherit the wrong TLS client settings, undermining trust in the downstream backend rather than in Traefik itself. Exploitation is conditional - it requires connection-reuse timing, an NTLM/Kerberos-authenticating backend, and multiple services with divergent ServersTransport TLS settings behind the same proxy - and no public exploit code or active exploitation has been identified at time of analysis; vendor fixes are available in 2.11.58 and 3.7.14.
Client-certificate authentication bypass in Apache Traffic Server (8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0) lets an unauthenticated remote attacker resume a previously negotiated TLS session against an SNI virtual host that is configured with the verify_client STRICT policy, reaching backends that should have demanded a client certificate. The attacker only needs to first establish a resumable session on a virtual host that does not require client certificates, then resume it against the protected host; deployments that do not use verify_client STRICT, or that do not share session state across SNI hosts, are not exposed. No public exploit code or active exploitation has been identified at time of analysis, and the practical risk is concentrated in multi-tenant TLS-termination front ends that mix mutual-TLS and non-mTLS virtual hosts on the same instance.
TLS client-certificate cross-contamination in Apache Traffic Server 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 lets an outbound (origin-facing) transaction configured to present one client certificate instead reuse a pooled TLS session that was authenticated with a different client certificate, so the origin may see, authorize, and log the wrong client identity. The issue only manifests where ATS is configured for outbound mutual TLS with more than one distinct client certificate while the default outbound session-sharing/pooling policy is left enabled; deployments without outbound client certificates, with a single client identity, or with session sharing disabled are not affected. Apache assigned the maximum CVSS 3.1 score of 10.0, while this assessment scores it AV:N/AC:H because triggering the wrong reuse depends on session-pool state and timing rather than an attacker-injected payload; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis. Vendor-released patches exist in 9.2.16, 10.1.5, and 10.2.1.
FreeRDP proxy deployments that lack a target-certificate verification module can be tricked into accepting a self-signed or wrong-hostname certificate, letting a network-positioned attacker impersonate the RDP target and receive proxied session data. The flaw affects FreeRDP 2.0.0 before 3.32.0 and is rated 7.6 HIGH; the assessed CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. Exploitation requires proxy mode, no configured verification module, and an on-path position on the proxy's outbound connection; no public exploit identified at time of analysis.
TLS certificate verification in the OpenTelemetry Python OTLP/HTTP exporter is silently disabled when the OTEL_EXPORTER_OTLP_CERTIFICATE environment variable is set to an empty string, allowing an unauthenticated on-path attacker to impersonate the OTLP collector and read or tamper with exported traces, metrics and logs - including the authentication headers configured via OTEL_EXPORTER_OTLP_HEADERS. Only deployments running opentelemetry-exporter-otlp-proto-http 1.5.0 through 1.44.x that export over TLS to a remote collector and carry this specific misconfiguration (empty string rather than unset or a valid CA bundle path) are exposed, and exploitation additionally requires the attacker to occupy a man-in-the-middle position on the export path. There is no CISA KEV listing and no public exploit identified at time of analysis, so this is a genuine but conditional risk rather than an emergency: the vendor has released a fix in 1.45.0.
Certificate pinning and custom TLS identity checks can be silently bypassed in undici versions 4.0.0 through 6.29.0, 7.0.0 through 7.30.0, and 8.0.0 through 8.12.1 because the Agent dispatcher drops function-valued tls options such as checkServerIdentity during a JSON deep clone before per-origin pool creation. An unauthenticated man-in-the-middle attacker who can present a certificate satisfying Node.js default hostname and chain validation but that the application's custom callback would have rejected can then be accepted, affecting request, fetch, and setGlobalDispatcher paths plus EnvHttpProxyAgent direct and no-proxy routes when applications rely on function-valued TLS verification. This is a conditional security-control bypass rather than a broad remote-code or data-theft flaw; no public exploit identified at time of analysis and no CISA KEV active exploitation is reported, while vendor-released patches are available in undici 6.29.1, 7.30.1, and 8.12.2.
Eclipse Vert.x's HTTP client (io.vertx:vertx-core) caches SSL contexts using a cache key that does not fully capture the SSL semantics of the requested properties, so a caller asking for a context with hostname/endpoint-identification validation can be handed a cached context that silently ignores it - a TLS trust-decision failure affecting versions 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0. The issue is unauthenticated (CVSS vector PR:N/UI:N) but rated high attack complexity because exploitation additionally requires the application to create multiple SSL contexts with differing security properties and an attacker to hold a man-in-the-middle network position to abuse the resulting loss of certificate verification. There is no public exploit identified at time of analysis and no CISA KEV listing; the advisory-driven CVSS 4.0 score is 9.1, while the independent v3.1 assessment rates it lower (High, ~7.4) with AC:H, reflecting the configuration-dependent and MITM-gated prerequisites.
Dell Terraform Provider for Redfish versions before 1.6.2 exposes Redfish BMC traffic, including credentials, to man-in-the-middle interception because TLS certificate verification is unconditionally disabled in its base HTTP transport. This critical-severity flaw (CVSS 9.0) allows an unauthenticated remote attacker who occupies a MITM position to capture or alter sensitive Redfish API communications, though exploitation is condition-gated to active provider-to-BMC traffic windows and is materially lower risk on trusted, isolated management segments. No public exploit identified at time of analysis; Dell recommends upgrading to 1.6.2.
Unauthenticated attackers who know a registered device's serial number can obtain that device's MDM client certificate and private key from OCO-Server's Apple MDM enrollment endpoint and then impersonate the device on all subsequent MDM traffic. The /api-mdm.php/profile handler verifies enrollment plists with openssl_pkcs7_verify(..., PKCS7_NOVERIFY, ...), so an arbitrary self-signed certificate satisfies the check and the SERIAL/UDID claims in the payload are trusted without being bound to the signer; the response returns a PKCS#12 bundle containing a certificate with CN=<serial> issued by the server's internal MDM device CA together with its private key, and the victim's mobile_device row is overwritten with the attacker-chosen UDID. Affects OCO-Server 1.2.0 through 1.2.2 (the MDM feature was introduced in 1.2.0); version 1.2.3 fixes the issue. Reported by GitHub_M and rated act_now by vuln.today priority; no public exploit identified at time of analysis, active exploitation is not confirmed, and the reporter states a proof of concept and full reproduction evidence were offered privately under coordinated disclosure.
Man-in-the-middle interception and modification of NT OneAPP client-server communications is possible because the application fails to validate both the server certificate and hostname. Network-adjacent, unauthenticated attackers who already hold a position on the traffic path - such as a rogue Wi-Fi access point or compromised LAN segment - can present an arbitrary certificate and read or alter sessions. No public exploit was identified at time of analysis, and exploitation is bounded by the requirement to intercept live traffic; the independent assessment rates this as adjacent-network, high-complexity, with high confidentiality and integrity impact.
TLS client-configuration reuse in Traefik Proxy 2.11.0 through 2.11.57 and 3.0.0 through 3.7.13 allows an unauthenticated client to bypass a backend service's configured root CAs, SNI/server name, and certificate verification. When one backend issues an NTLM or Negotiate (Kerberos) challenge, Traefik stores the resulting round tripper in a client-connection slot that is not keyed by ServersTransport; an attacker who arms that slot can then reach a different service over the same keep-alive connection and inherit the wrong TLS client settings, undermining trust in the downstream backend rather than in Traefik itself. Exploitation is conditional - it requires connection-reuse timing, an NTLM/Kerberos-authenticating backend, and multiple services with divergent ServersTransport TLS settings behind the same proxy - and no public exploit code or active exploitation has been identified at time of analysis; vendor fixes are available in 2.11.58 and 3.7.14.
Client-certificate authentication bypass in Apache Traffic Server (8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0) lets an unauthenticated remote attacker resume a previously negotiated TLS session against an SNI virtual host that is configured with the verify_client STRICT policy, reaching backends that should have demanded a client certificate. The attacker only needs to first establish a resumable session on a virtual host that does not require client certificates, then resume it against the protected host; deployments that do not use verify_client STRICT, or that do not share session state across SNI hosts, are not exposed. No public exploit code or active exploitation has been identified at time of analysis, and the practical risk is concentrated in multi-tenant TLS-termination front ends that mix mutual-TLS and non-mTLS virtual hosts on the same instance.
TLS client-certificate cross-contamination in Apache Traffic Server 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 lets an outbound (origin-facing) transaction configured to present one client certificate instead reuse a pooled TLS session that was authenticated with a different client certificate, so the origin may see, authorize, and log the wrong client identity. The issue only manifests where ATS is configured for outbound mutual TLS with more than one distinct client certificate while the default outbound session-sharing/pooling policy is left enabled; deployments without outbound client certificates, with a single client identity, or with session sharing disabled are not affected. Apache assigned the maximum CVSS 3.1 score of 10.0, while this assessment scores it AV:N/AC:H because triggering the wrong reuse depends on session-pool state and timing rather than an attacker-injected payload; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis. Vendor-released patches exist in 9.2.16, 10.1.5, and 10.2.1.
FreeRDP proxy deployments that lack a target-certificate verification module can be tricked into accepting a self-signed or wrong-hostname certificate, letting a network-positioned attacker impersonate the RDP target and receive proxied session data. The flaw affects FreeRDP 2.0.0 before 3.32.0 and is rated 7.6 HIGH; the assessed CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. Exploitation requires proxy mode, no configured verification module, and an on-path position on the proxy's outbound connection; no public exploit identified at time of analysis.
TLS certificate verification in the OpenTelemetry Python OTLP/HTTP exporter is silently disabled when the OTEL_EXPORTER_OTLP_CERTIFICATE environment variable is set to an empty string, allowing an unauthenticated on-path attacker to impersonate the OTLP collector and read or tamper with exported traces, metrics and logs - including the authentication headers configured via OTEL_EXPORTER_OTLP_HEADERS. Only deployments running opentelemetry-exporter-otlp-proto-http 1.5.0 through 1.44.x that export over TLS to a remote collector and carry this specific misconfiguration (empty string rather than unset or a valid CA bundle path) are exposed, and exploitation additionally requires the attacker to occupy a man-in-the-middle position on the export path. There is no CISA KEV listing and no public exploit identified at time of analysis, so this is a genuine but conditional risk rather than an emergency: the vendor has released a fix in 1.45.0.
Certificate pinning and custom TLS identity checks can be silently bypassed in undici versions 4.0.0 through 6.29.0, 7.0.0 through 7.30.0, and 8.0.0 through 8.12.1 because the Agent dispatcher drops function-valued tls options such as checkServerIdentity during a JSON deep clone before per-origin pool creation. An unauthenticated man-in-the-middle attacker who can present a certificate satisfying Node.js default hostname and chain validation but that the application's custom callback would have rejected can then be accepted, affecting request, fetch, and setGlobalDispatcher paths plus EnvHttpProxyAgent direct and no-proxy routes when applications rely on function-valued TLS verification. This is a conditional security-control bypass rather than a broad remote-code or data-theft flaw; no public exploit identified at time of analysis and no CISA KEV active exploitation is reported, while vendor-released patches are available in undici 6.29.1, 7.30.1, and 8.12.2.
Eclipse Vert.x's HTTP client (io.vertx:vertx-core) caches SSL contexts using a cache key that does not fully capture the SSL semantics of the requested properties, so a caller asking for a context with hostname/endpoint-identification validation can be handed a cached context that silently ignores it - a TLS trust-decision failure affecting versions 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0. The issue is unauthenticated (CVSS vector PR:N/UI:N) but rated high attack complexity because exploitation additionally requires the application to create multiple SSL contexts with differing security properties and an attacker to hold a man-in-the-middle network position to abuse the resulting loss of certificate verification. There is no public exploit identified at time of analysis and no CISA KEV listing; the advisory-driven CVSS 4.0 score is 9.1, while the independent v3.1 assessment rates it lower (High, ~7.4) with AC:H, reflecting the configuration-dependent and MITM-gated prerequisites.
Dell Terraform Provider for Redfish versions before 1.6.2 exposes Redfish BMC traffic, including credentials, to man-in-the-middle interception because TLS certificate verification is unconditionally disabled in its base HTTP transport. This critical-severity flaw (CVSS 9.0) allows an unauthenticated remote attacker who occupies a MITM position to capture or alter sensitive Redfish API communications, though exploitation is condition-gated to active provider-to-BMC traffic windows and is materially lower risk on trusted, isolated management segments. No public exploit identified at time of analysis; Dell recommends upgrading to 1.6.2.