• lapcat 2 hours ago |
    > Apple told 404 Media it deployed a patch for the issue on July 3, which the company says has fully resolved the issue.

    > Now Apple says it has been fixed, we can add that, in simple terms, it required sending a target Hide My Email user a message that got rejected as spam.

    I would note that Mac Mail app (I haven't tested iOS Mail) still has an Apple Account email address disclosure vulnerability, though this requires the user to reply to a maliciously crafted email. The vulnerability affects all users of Mail app, even if they don't use Hide My Email! https://lapcatsoftware.com/articles/2026/7/9.html

  • argee an hour ago |
    I have a question I wasn’t sure how to ask HN that is tangentially related to this. I’m the developer of an app where people can add other users to their workspaces, via email. The way this currently works is that your email gets added to the workspace and then when you log in with that email, you get access.

    Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I be using urls with invite codes instead of associating the email itself with access? I’m a little hesitant to do that since the code would have to persist in session and the business logic would have to occur on the login portal, since the mobile/desktop apps don’t share web cookies. Is deep linking the answer?

    • Rumudiez an hour ago |
      email addresses are not good primary or foreign keys, so yes you should be using IDs of one form or another. this shouldn't affect your authentication scheme (cookies vs bearer tokens or what have you), just authorization. if you've muddied the two, you'll have some debt to resolve and this issue could just be a valuable tip-off to that
      • hawtads 42 minutes ago |
        I think OP is referring to the initial sign up based on an invite link, not the database storage itself.

        It depends whether you want to check the invite code against the invitee's email. It very much depends on the application. For most use cases, just verifying the code is fine and accept any email addresses that posses it.

        Essentially ask yourself this, if you change the UI a bit and allow any user to sign up with any email, and the workspace joining is done via a code they enter after login, is that acceptable for your product design and security posture.

        • Rumudiez 7 minutes ago |
          okay, I have that use case as well and it is driven by an invite code. it works well for new sign-ups and existing users, and you can even just let the user copy the link and send it themselves if they're on discord or something else. no email required for pseudonymous sharing, bonus feature to send an email invite if it is given
  • a9ex an hour ago |
    So how did the vulnerability work exactly?
    • culi an hour ago |
      • j79 16 minutes ago |
        Looks like that was the original article, which didn't have much details about how the exploit worked.

        > 404 Media is not revealing the exact details of the vulnerability because it can still be exploited as of Monday, when 404 Media verified the issue with one of our own hidden email addresses.

        However, based on the current article:

        > Now Apple says it has been fixed, we can add that, in simple terms, it required sending a target Hide My Email user a message that got rejected as spam. “We don't know how often hidden email addresses were leaked in email logs. For many major email hosts, the leak was triggered simply by an email being automatically rejected as spam, even if it was a legitimate message. Such emails probably didn't make it to your inbox, so you can’t review your spam folder to learn whether you were affected,” Murphy and EasyOptOut co-founder Ben Weiner said in a new statement.

        My guess is that if an e-mail was rejected as Spam, the response had the actual e-mail included. However, based on the next paragraph:

        > “The bug that caused Apple's Hide My Email to leak hidden email addresses to senders has been fixed. However, we don't think the risk to Hide My Email users has been eliminated. Because non-malicious emails could bounce, revealing your hidden email address, and because mail transfer logs are often retained, we'd assume that any hidden email address linked to a Hide My Email address created before July 7, 2026, may have been exposed and could still be in third-party logs,” they added.

        It seems even bounced e-mails could leak your actual e-mail.

        • nashashmi 11 minutes ago |
          [delayed]