Summary

Chinese AI company DeepSeek exposed an unprotected database containing over a million unencrypted chat logs, API keys, and other sensitive data.

Security researchers at Wiz discovered the vulnerability and alerted DeepSeek, which promptly took the database offline.

It’s unclear how long the data was exposed or if others accessed it before Wiz.

DeepSeek, which gained viral popularity since its December launch, has not commented.

    • Nomecks@lemmy.ca
      link
      fedilink
      arrow-up
      30
      arrow-down
      2
      ·
      1 day ago

      The kind of company who develops an AI for 4% the cost of everyone else

      • Aurenkin@sh.itjust.works
        link
        fedilink
        arrow-up
        8
        ·
        1 day ago

        I don’t know, it doesn’t feel like a cost thing to me. If even one second of thought was given to security this could have been prevented basically for free.

          • Aurenkin@sh.itjust.works
            link
            fedilink
            arrow-up
            5
            arrow-down
            1
            ·
            1 day ago

            Technically correct but that’s like saying it takes effort to set up a passcode on your phone. Yes but it’s basically as close to zero as you can get and the return makes it a no brainer. Data breaches also cost money to remediate and can cause potentially trust destroying reputational damage.

            • Nomecks@lemmy.ca
              link
              fedilink
              arrow-up
              3
              ·
              23 hours ago

              It’s a no brainer if you’re paying people enough to understand the problem.

    • Corngood@lemmy.ml
      link
      fedilink
      arrow-up
      6
      ·
      1 day ago

      It wasn’t at rest according to the blog post:

      we found a publicly accessible ClickHouse database linked to DeepSeek, completely open and unauthenticated, exposing sensitive data. It was hosted at oauth2callback.deepseek.com:9000 and dev.deepseek.com:9000.

      So probably either a service that was meant to be bound on loopback or a firewall issue.

      I guess that shows how dangerous it is to have something secured by the ‘nobody should be able to access this port’ method.