Monthly
The embedded browser in JetBrains desktop IDEs - IntelliJ IDEA, PyCharm, PhpStorm, RubyMine, WebStorm, GoLand, Rider, CLion, DataGrip, RustRover and DataSpell - continues to trust revoked intermediate certificates, so an attacker holding a man-in-the-middle position on an HTTPS connection opened from that browser can present a chain anchored in a revoked eMudhra intermediate and have it accepted, exposing or altering data the user believes is protected by TLS. Reachability is narrow: the victim must actually load an HTTPS resource in the embedded browser, the attacker must be able to intercept that specific TLS session, and a revoked-but-previously-issued eMudhra intermediate must be available, so ordinary coding activity that never touches the embedded browser is not affected. No public exploit identified at time of analysis, exploitation has not been confirmed, and the issue is prioritized for remediation this week rather than as an emergency; JetBrains has published fixed builds for every affected product line.
CPython's ssl module validates TLS certificate chains that anchor to known-compromised eMudhra CA certificates, so anyone holding that CA's key material can impersonate arbitrary TLS servers to unpatched Python clients. Every Python application that relies on the default verification path (ssl.create_default_context() or an SSLContext without its own OCSP/CRL checking) is affected, which is CPython's default behaviour; the fix adds a hard-coded denylist of distrusted certificates enforced regardless of SSLContext policy. Exploitation is targeted rather than opportunistic, requiring the compromised CA key plus a man-in-the-middle or server-impersonation position against the victim's connection; no public exploit identified at time of analysis, and the vendor-tracked priority label is act_now.
Electron before 42.11.16, 43.8.1, 44.9.1 and 45.0.0-beta.6 fails to enforce the blocklist for a set of compromised eMudhra intermediate certificates, so a TLS chain terminating in one of those intermediates is still accepted by Chromium networking and by Node.js tls, https and fetch. An attacker who already holds a leaf certificate issued under one of those intermediates and who can intercept the victim app's network traffic can impersonate a TLS server to that app, breaking both confidentiality and integrity of the connection; the CVSS vector scores this 7.4 with AC:H, unauthenticated (PR:N) and no user interaction, reflecting that the MITM position is the binding constraint. Apps that make no network connections are not affected, and the vendor states there are no app-side workarounds - only an update to a patched Electron release closes the gap. No public exploit code has been identified at time of analysis, and the issue is not in CISA KEV, so the practical risk is a conditional interception scenario rather than a broadly exploited one.
Certificate revocation bypass in the Netty netty-handler-ssl-ocsp module (versions before 4.1.136.Final, and 4.2.0.Final through 4.2.15.Final) lets an on-path attacker replay a stale, expired-but-GOOD OCSP response to make OcspServerCertificateValidator accept a certificate that has since been revoked. A missing return statement after the freshness check causes execution to fall through and still fire a VALID OcspValidationEvent even after flagging the response as out-of-date. Publicly available exploit code exists (a PoC unit test is embedded in the GHSA advisory); the issue is not listed in CISA KEV and no EPSS score was provided.
Certificate revocation bypass in forgekeep/nebula-mesh before 0.7.1 lets a blocked, offboarded, or compromised host keep full mesh connectivity because the per-CA blocklist is computed and shipped by the server but never applied by the agent. The agent decodes the updates response's Blocklist field and discards it, and the config generator has no field to emit pki.blocklist, so Nebula's only revocation control never reaches any peer's config.yml. Rated CVSS 8.1; no CISA KEV listing, but a benign proof-of-concept test is published and the fix is available in v0.7.1.
Certificate revocation bypass in Rockwell Automation ControlLogix 5580, CompactLogix 5380, GuardLogix 5580, Compact GuardLogix 5380, and 1756-EN4TR (EN4) communication modules allows a network-based attacker to establish a CIP Security connection using a certificate whose issuing intermediate CA has been revoked. Because the controller does not honor the Certificate Revocation List (CRL) for a revoked intermediate, an attacker holding such a certificate can present it as trusted and bypass CIP Security authentication. No public exploit identified at time of analysis; the vendor rates it CVSS 4.0 8.2 (High).
A logic error in AWS-LC's CRL (Certificate Revocation List) distribution point validation causes the cryptographic library to incorrectly reject partitioned CRLs as out of scope, allowing revoked certificates to bypass certificate revocation checks. This authentication bypass vulnerability affects AWS-LC versions before 1.71.0 and AWS-LC-FIPS versions before 3.3.0, potentially allowing attackers to use revoked certificates for unauthorized access to systems that rely on AWS-LC for certificate validation. No active exploitation has been reported in KEV, and no EPSS score is available yet.
Certificate chain validation in Go Toolchain 1.26.x before 1.26.10 and 1.27.x before 1.27.3 can return chains that include a small set of intermediate CA certificates the Go security team has decided to distrust, so an unauthenticated remote attacker who can intercept TLS traffic and present a certificate chaining through one of those intermediates could impersonate a trusted endpoint. This is a defensive trust-store and verification change in crypto/x509 Verify rather than a code-execution flaw; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, and no public exploit, KEV entry, EPSS score, or CWE is provided. Upgrade to Go 1.27.3 or 1.26.10 and rebuild to apply the chain filter.
Secure Boot integrity bypass in Windows 10, Windows 11, and Windows Server 2016 through 2025 lets an authenticated local attacker with administrator or SYSTEM privileges load a boot component that Secure Boot should reject, because the boot chain fails to properly check certificate and bootloader revocation (CWE-299). The issue is rated CVSS 4.4 (AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N) - it requires pre-existing high privilege and Secure Boot enabled, and it can only undermine boot-chain integrity, with no confidentiality or availability loss. No public exploit identified at time of analysis, and Microsoft has shipped vendor patches; see remediation for exact fixed builds.
Certificate revocation checking in wolfSSL builds that enable both OCSP and CRL can be silently bypassed, allowing a certificate that the loaded CRL explicitly lists as revoked to be accepted during a TLS/DTLS handshake. Only applications that define both HAVE_OCSP and HAVE_CRL (for example --enable-ocsp --enable-crl, or bundles such as --enable-all, --enable-nginx, --enable-haproxy, --enable-openvpn, --enable-strongswan) and that actually call both wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL() with a CRL loaded are exposed; OCSP-stapling-only applications are not affected. The CVSS vector indicates the attacker must be positioned as an authenticated peer (PR:L) presenting a crafted certificate, and the independent assessment rates this LOW priority: no public exploit code has been identified at time of analysis and the stacked build-time and configuration prerequisites make practical exploitation unlikely, though the resulting integrity impact is real for affected deployments.
The embedded browser in JetBrains desktop IDEs - IntelliJ IDEA, PyCharm, PhpStorm, RubyMine, WebStorm, GoLand, Rider, CLion, DataGrip, RustRover and DataSpell - continues to trust revoked intermediate certificates, so an attacker holding a man-in-the-middle position on an HTTPS connection opened from that browser can present a chain anchored in a revoked eMudhra intermediate and have it accepted, exposing or altering data the user believes is protected by TLS. Reachability is narrow: the victim must actually load an HTTPS resource in the embedded browser, the attacker must be able to intercept that specific TLS session, and a revoked-but-previously-issued eMudhra intermediate must be available, so ordinary coding activity that never touches the embedded browser is not affected. No public exploit identified at time of analysis, exploitation has not been confirmed, and the issue is prioritized for remediation this week rather than as an emergency; JetBrains has published fixed builds for every affected product line.
CPython's ssl module validates TLS certificate chains that anchor to known-compromised eMudhra CA certificates, so anyone holding that CA's key material can impersonate arbitrary TLS servers to unpatched Python clients. Every Python application that relies on the default verification path (ssl.create_default_context() or an SSLContext without its own OCSP/CRL checking) is affected, which is CPython's default behaviour; the fix adds a hard-coded denylist of distrusted certificates enforced regardless of SSLContext policy. Exploitation is targeted rather than opportunistic, requiring the compromised CA key plus a man-in-the-middle or server-impersonation position against the victim's connection; no public exploit identified at time of analysis, and the vendor-tracked priority label is act_now.
Electron before 42.11.16, 43.8.1, 44.9.1 and 45.0.0-beta.6 fails to enforce the blocklist for a set of compromised eMudhra intermediate certificates, so a TLS chain terminating in one of those intermediates is still accepted by Chromium networking and by Node.js tls, https and fetch. An attacker who already holds a leaf certificate issued under one of those intermediates and who can intercept the victim app's network traffic can impersonate a TLS server to that app, breaking both confidentiality and integrity of the connection; the CVSS vector scores this 7.4 with AC:H, unauthenticated (PR:N) and no user interaction, reflecting that the MITM position is the binding constraint. Apps that make no network connections are not affected, and the vendor states there are no app-side workarounds - only an update to a patched Electron release closes the gap. No public exploit code has been identified at time of analysis, and the issue is not in CISA KEV, so the practical risk is a conditional interception scenario rather than a broadly exploited one.
Certificate revocation bypass in the Netty netty-handler-ssl-ocsp module (versions before 4.1.136.Final, and 4.2.0.Final through 4.2.15.Final) lets an on-path attacker replay a stale, expired-but-GOOD OCSP response to make OcspServerCertificateValidator accept a certificate that has since been revoked. A missing return statement after the freshness check causes execution to fall through and still fire a VALID OcspValidationEvent even after flagging the response as out-of-date. Publicly available exploit code exists (a PoC unit test is embedded in the GHSA advisory); the issue is not listed in CISA KEV and no EPSS score was provided.
Certificate revocation bypass in forgekeep/nebula-mesh before 0.7.1 lets a blocked, offboarded, or compromised host keep full mesh connectivity because the per-CA blocklist is computed and shipped by the server but never applied by the agent. The agent decodes the updates response's Blocklist field and discards it, and the config generator has no field to emit pki.blocklist, so Nebula's only revocation control never reaches any peer's config.yml. Rated CVSS 8.1; no CISA KEV listing, but a benign proof-of-concept test is published and the fix is available in v0.7.1.
Certificate revocation bypass in Rockwell Automation ControlLogix 5580, CompactLogix 5380, GuardLogix 5580, Compact GuardLogix 5380, and 1756-EN4TR (EN4) communication modules allows a network-based attacker to establish a CIP Security connection using a certificate whose issuing intermediate CA has been revoked. Because the controller does not honor the Certificate Revocation List (CRL) for a revoked intermediate, an attacker holding such a certificate can present it as trusted and bypass CIP Security authentication. No public exploit identified at time of analysis; the vendor rates it CVSS 4.0 8.2 (High).
A logic error in AWS-LC's CRL (Certificate Revocation List) distribution point validation causes the cryptographic library to incorrectly reject partitioned CRLs as out of scope, allowing revoked certificates to bypass certificate revocation checks. This authentication bypass vulnerability affects AWS-LC versions before 1.71.0 and AWS-LC-FIPS versions before 3.3.0, potentially allowing attackers to use revoked certificates for unauthorized access to systems that rely on AWS-LC for certificate validation. No active exploitation has been reported in KEV, and no EPSS score is available yet.
Certificate chain validation in Go Toolchain 1.26.x before 1.26.10 and 1.27.x before 1.27.3 can return chains that include a small set of intermediate CA certificates the Go security team has decided to distrust, so an unauthenticated remote attacker who can intercept TLS traffic and present a certificate chaining through one of those intermediates could impersonate a trusted endpoint. This is a defensive trust-store and verification change in crypto/x509 Verify rather than a code-execution flaw; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, and no public exploit, KEV entry, EPSS score, or CWE is provided. Upgrade to Go 1.27.3 or 1.26.10 and rebuild to apply the chain filter.
Secure Boot integrity bypass in Windows 10, Windows 11, and Windows Server 2016 through 2025 lets an authenticated local attacker with administrator or SYSTEM privileges load a boot component that Secure Boot should reject, because the boot chain fails to properly check certificate and bootloader revocation (CWE-299). The issue is rated CVSS 4.4 (AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N) - it requires pre-existing high privilege and Secure Boot enabled, and it can only undermine boot-chain integrity, with no confidentiality or availability loss. No public exploit identified at time of analysis, and Microsoft has shipped vendor patches; see remediation for exact fixed builds.
Certificate revocation checking in wolfSSL builds that enable both OCSP and CRL can be silently bypassed, allowing a certificate that the loaded CRL explicitly lists as revoked to be accepted during a TLS/DTLS handshake. Only applications that define both HAVE_OCSP and HAVE_CRL (for example --enable-ocsp --enable-crl, or bundles such as --enable-all, --enable-nginx, --enable-haproxy, --enable-openvpn, --enable-strongswan) and that actually call both wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL() with a CRL loaded are exposed; OCSP-stapling-only applications are not affected. The CVSS vector indicates the attacker must be positioned as an authenticated peer (PR:L) presenting a crafted certificate, and the independent assessment rates this LOW priority: no public exploit code has been identified at time of analysis and the stacked build-time and configuration prerequisites make practical exploitation unlikely, though the resulting integrity impact is real for affected deployments.