That Apple has a huge focus on security is no secret. For years, the company has professed a series of privacy and security standards worldwide that it strictly enforces, whether it’s shielding iPhone components to prevent theft or strengthening online protection for children and teens. However, a flaw has just been discovered that affected Apple’s Passwords app, exposing credentials for nearly three months.
This is revealed by both the duo of iOS researchers and developers nicknamed Mysk and the media 9to5Mac, which discovered an HTTP security problem in the application from its launch in iOS 18 until it was patched in iOS 18.2. This problem would have left the passwords of the service users unprotected against phishing attacks all this time, redirecting HTTP requests to malicious websites.
The Passwords app in question was sending unencrypted requests for logos and icons associated with users’ stored passwords. An attacker on the same Wi-Fi network and with privileged access could redirect a user’s traffic to a phishing site where login information could be stolen. However, Apple eventually patched this flaw in iOS 18.2.
Problem with the Passwords app
Mysk researchers reveal the flaw in a video that’s barely 50 seconds long, in which the problem can be seen being “activated.” The key lies in the app’s ability to change a vulnerable password; since its launch, Passwords has warned users about compromised or easy-to-guess passwords, offering them the option to change them.
This is where the app allows access to the password-changing website via an insecure HTTP protocol. “This allowed an attacker with privileged network access to easily intercept and redirect requests to a phishing website,” the developers explain. The Passwords app makes an HTTP request to open the link, without using the encrypted HTTPS protocol. A privileged user on a malicious network can redirect these requests to send the victim to a fake website, which can then be used to steal their login information.
Apple's Passwords app was vulnerable to phishing attacks in iOS versions prior to 18.2. Its functionality to change a password from within the app used to open an account's website via insecure HTTP by default. This allowed an attacker with privileged network access to easily… pic.twitter.com/VrqFWSk4z1
— Mysk 🇨🇦🇩🇪 (@mysk_co) March 18, 2025According to 9to5Mac, the issue originated with the release of Passwords as a standalone app in iOS 18 and was fixed in the iOS 18.2 update. Mysk claims that Apple recently deleted the security report, preventing them from discussing the flaw earlier. As if that weren’t enough, there will be no bounty for the discovery of this flaw, according to Apple, because it doesn’t meet “the impact criteria” or fall “into any of the eligible categories.”
In addition to all this, the developer duo makes a correction: this bug would not have been present for months, but years. “Apple Passwords had been using insecure HTTP by default since the feature to detect compromised passwords was introduced in iOS 14. The dedicated Passwords app in iOS 18 was essentially a repackage of the old password manager that was in Settings, and which retained all of its bugs,” they report from X (formerly Twitter).
If the developers were able to discover the problem, it was after reviewing the Privacy Report provided by one of the duo’s iPhone members. In that report, Mysk discovered that Passwords had contacted 130 different websites using the insecure HTTP protocol. They discovered that the app not only obtained account icons and logos via HTTP, but also opened password reset pages using this same standard.
This, in Mysk’s eyes, was quite unusual. “We were surprised that Apple didn’t implement HTTPS by default for such a sensitive app. Additionally, Apple should offer an option for security-conscious users to completely disable icon downloads,” the developers explain. “I’m uncomfortable with my password manager constantly pinging every website I have a password for, even though the requests Passwords sends don’t include any IDs.”
It’s worth noting that most websites today allow unencrypted HTTP connections, although they often automatically redirect these connections to HTTPS using 301 redirects. Passwords already made these requests over HTTP, leading to this secure redirect to HTTPS. Under most common circumstances, this wouldn’t pose a problem, as password changes are performed on an encrypted page.
The problem arises when using public networks, which are easily hacked and, in many cases, are controlled by attackers. They can intercept initial HTTP requests before they are redirected, manipulating traffic and directing the victim to a malicious website that mimics the software developer’s site. For example, if a user wants to change their Microsoft account password and an attacker intercepts their request, they can be taken to a website copied from Microsoft and obtain their login credentials.