Login
You're viewing the slime.global public feed.
  • Filippo Valsordafilippo@abyssdomain.expert
    Oct 20, 2026, 2:23 PM

    🚨 Six WebPKI Intermediate CAs are compromised.

    This is bigger than Heartbleed, but a client-side issue.

    Anything that verifies certificates against public roots, like most TLS clients, is/was affected.

    Details, live test, patched versions and workarounds at emudhra.we-have-a-problem.com

    Act now.

    💬 5🔄 89⭐ 51

Replies

  • Leah Neukirchenleah@blahaj.social
    Oct 20, 2026, 2:28 PM

    @filippo the AAA Certificate Services domains still connect after updating to NSS 3.131.1, is that update only a partial fix?

    💬 2🔄 0⭐ 1
  • Cassandrichdalias@hachyderm.io
    Oct 20, 2026, 2:41 PM

    @leah @filippo Wow, AAA Certificate Services was supposed to be distrusted a year ago. Alpine has it removed from ca-certificates but Firefox on Alpine still had it.

    💬 1🔄 1⭐ 2
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Oct 20, 2026, 2:31 PM
    Their page to test if a client is affected is severely broken. For me it reported that my browser was safe without even conducting the test.
    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Oct 20, 2026, 6:24 PM
    Same problem regardless of whether I visit the site in Chromium or Firefox.
    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Oct 20, 2026, 6:34 PM
    It does try to access each URL. But they fail before it gets to the TLS handshake, so it never reaches the validation it's intended to test.

    And then it reports the browser is safe. I presume they report every failure as a success and not only those where it fails during certificate validation.

    A correct output would be:
    - A successful connection is reported as unsafe
    - A connection failed due to the TLS certificate is reported as safe
    - A connection failed for any reason is reported as inconclusive
    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Oct 20, 2026, 6:56 PM
    Here is what I get in Firefox.

    I tried with and without DNS64 to see if there was a difference. The final output is identical in both cases.

    Without DNS64 it reports success instantly without conducting the tests.

    With DNS64 there is a noticeable delay while the test is running before the results are displayed. I think it is performing the actual test in that case, but the network tab doesn't show a useful error code in Firefox like it does in Chromium.
    Image attached toot
    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 1
  • kasperdkasperd@westergaard.social
    Oct 21, 2026, 2:32 PM
    In the case of Android I am not sure in which cases the application is responsible for the trust and in which cases Android itself takes care of it.
    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 2
  • 💬 1🔄 0⭐ 0
  • Buttered Jortsajn142@infosec.exchange
    Oct 20, 2026, 5:21 PM

    @filippo curl.exe is fixed, but Invoke-WebRequest (what curl is aliased to in PowerShell) and the latest Edge Browser with CRLSet 6498.2026.10.1 are still vulnerable (back half of CRLSet looks like a date, if so then this is from the first of October, and attempting to update CRLSet returns "up-to-date")

    Edit: Screenshots

    Screenshot of the difference in behavior between curl (alias for Invoke-WebRequest) and curl.exe within PowerShell
    Screenshot showing up-to-date Edge, CRLSets, and failing tests.
    💬 1🔄 1⭐ 1
  • Buttered Jortsajn142@infosec.exchange
    Oct 20, 2026, 6:27 PM

    @filippo likewise, the two files used to automatically update the Windows-level cert store haven't been updated since August 2026 and September 2025(!!!).

    💬 0🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Oct 20, 2026, 9:15 PM
    The test on that page is definitely broken. I found that under some circumstances it will report that the browser is safe without actually conducting the test.
    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • kasperdkasperd@westergaard.social
    Oct 20, 2026, 9:23 PM
    Now that I have learned how those keys were compromised I am wondering if certificate transparency logs offer any protection here.

    Anyone could forge certificates using the weak keys without adding them to any certificate transparency log. If clients reject certificates that are not in the logs, then an adversary would have to submit forged certificates to a transparency log. And doing so would increase the risk of being discovered.

    Regardless of what it does to forged certificates the certificate transparency logs could however be used to search for weak keys on legitimate certificates. You can do that wearing a hat of any color.
    💬 0🔄 0⭐ 0