This article reports on a critical FaceTime privacy vulnerability enabling non-consensual audio and video eavesdropping on incoming calls before recipients can answer. The article identifies the violation, documents its scope and mechanics, and reports on Apple's commitment to remediate it, effectively advocating for recognition of this as a serious privacy and security threat (Articles 12, 3) while demonstrating journalistic free expression (Article 19).
That's a pretty huge flaw. Millions if not billions of people can suddenly remotely spy on almost any other ios or mac anywhere in the world, just by knowing their email address or phone number?
Perhaps Apple should simply pull the plug on the facetime servers for now.
I'm always curious how a bug like this ships. I mean QA & Testing should catch it, sure. But even before then. Some engineer wrote code for FaceTime that has it open the microphone before the call is accepted. And transmit the audio over the network before the call is accepted. Who did that? And why? I'm not suggesting malice but I do wonder at the lack of defensive programming.
I wonder if the Apple representative who said this would be "fixed later this week" realizes this allows any attacker to wiretap any iPhone user (that has the vuln)
An quick stop for the possbile privacy disaster for Apple is to stop group facetime call at once but not wait for later this week for bug fix.
Could image that quite some one might already try to peek for privacy using this.
I would like to bring up something that happened to someone I know during WhatsApp call. Person A was in US and person B in India and were audio calling through Whastapp on something work related. Person A starts hearing someone else on his side, nothing unexpected on Bs side. A started a new call and everything was fine. A said it reminded him of the crosstalk that was common during the landline days. Could it be a bug or was someone listening and forgot to turn off their mic? No idea.
The other day my friend Alice (not real name) attempted a FaceTime call to Bob. To both our surprise my phone rang with a FaceTime call from Alice (and as far as we know, Bob never received the call). Holding both our phones together, Alice phone was showing a call to Bob while my phone was showing a call from Alice. A very strange fluke which makes me wonder how robust the FaceTime code is.
I just called my friend who was already on a call talking to his brother. He could hear me and his brother but his brother and I couldn't hear each other.
I was also able to call him, have him hang up and then see his video and hear his audio. He couldn't hear me, but I could hear and see everything.
Fun story: I tested this bug, initiating a call from my phone and then joining it on my Mac. After I had ended the call, the Mac's camera LED stayed on, even though the FaceTime app was not showing a video preview (in fact it had no windows open). Was it transmitting? Who knows! State management seems to be a mess all over the place.
It may be entirely unrelated, however this is the exact sort of behaviour you would expect to see associated with providing compatibility with Australia's newly introduced AABill, or to implement GCHQ's ghost participant proposal (https://www.lawfareblog.com/principles-more-informed-excepti...).
Premature optimization, perhaps. Don’t optimize by sending audio too early (as others have suggested) and why should I be able to add my own number to the conversation if I that number is the call’s initiator? Makes no sense.
Perhaps their NSA PRISM code got mixed up with their user facing code? I'm not just joking, we all know Apple only pays lip service to privacy and got caught red-handed during the Snowden leaks.
Rumor mill: FaceTime bug was submitted to Apple on 20 January 2019 by a concerned mother after .. her 14-year-old son discovered it.
>My teen found a major security flaw in Apple’s new iOS. He can listen in to your iPhone/iPad without your approval. I have video. Submitted bug report to @AppleSupport...waiting to hear back to provide details. Scary stuff! #apple #bugreport @foxnews
I encountered a bug a while back — when I would connect to a dial-out call to get onto my company’s conference service from its app, while using a pair of cheap Bluetooth headphones (I’ve upgraded since then!) the mute button didn’t work.
As in, the mute button would be clearly activated, but my audio still carried through to the call. As in, I discovered this in quite an embarrassing way.
I filed a radar but never got a real response about it. Really there appears to be a strong need at Apple to ensure QA is checking for confirmations of user interaction. As I haven’t experienced anything like this since I’m still with them but these types of problems are the very thing that would lead me to shake my deep investment in the Apple ecosystem.
Anyone who has filed a few rdars knows it is thankless work. The amount of work you have to invest for anyone to even look at your bug is high. In the instance of this particular bug, I wouldn’t be surprised if at least part of the reason it took a week and a half to handle since it was reported was that the initial reply to the reporter was “please send us the exact steps to reproduce” and then nothing was done until the bug reporter replied back. I wouldn’t be surprised to learn there were even a few iterations of this, since I personally experienced it.
Then, your bug gets looked at. But you don’t know anything about its status. Until anything from a few days to a few months later, it gets closed as a duplicate. Of course there is no way to know in advance that the bug was already opened, and that you could save an hour of work time instead of making a minimal reproducible version of your app which reproduces the bug.
Unless Apple decides they face significant legal exposure over the bug somehow I don't see them doing that. It would attract so much more attention that it would almost certainly not be worth it economically.
I wonder if they (executives? engineers? the company itself?) could be charged with aiding and abetting wiretapping or something now that they know it's happening and are letting their servers keep doing it.
Why would this be any more reputationally damaging than the numerous other bugs with iPhone behavior?
It’s not like iPhones have a reputation for not having bugs; it seems like every version has a passcode bypass or a DoS-via-iMessage. By some standards, this is worse (remotely triggerable, leaks audio/video), but in other cases it’s not as bad: the attacker’s Apple ID ends up in the call logs of the affected person.
Are there prior examples of any phone manufacturer being reputationally damaged by vulnerabilities like this? Heck, Samsung’s phones literally caught fire and they’re still selling phones just fine.
Is it just me, or is such a phrase applicable to Apple far too many times in the past several years? I think their engineering is losing quality or is falling behind on what they have to cover.
It reminds me of this MacOS bug from last year, where simply hitting the login box over and over with no password would eventually bypass the security entirely:
Not sure if this was intentional but in security, Alice and Bob wre the names in hypotheticals for the attacker and unwitting victim since the RSA paper.
Apple has shipped versions of its Mail program that delete email without warning¹ and versions of the Finder or OS X that delete² files. And much more. Yet their reputation is intact: the masses still believe that they put out quality software. They are truly the Teflon corporation.
It might trigger the bug to just invite any additional participant (say, a second phone the attacker possesses), in which case blocking only inviting oneself is not sufficient.
My theory is that the server routes messages to everyone who has been invited to the call, even if they have not accepted it. One message might be "participant left," in which case if you are the last one, the call ends.
Another would be "participant joined." The bug would center around the fact that the logic for handling a "participant joined" message does not check if the call has been accepted and makes an unexpected transition to a state that it should not be in.
The "participant joined" code likely handles the case that the new participant was already present on the call. Why? Apple wants to support seamlessly transitioning your call from one device to another. That's why blocking might not be so straightforward from the server side.
This means your camera was in use by some application. Whether that video left your device is harder to ascertain, but you can try quitting FaceTime to see if the light turns off.
iPhones already have a "mute" slider switch. When I first looked into iPhones (after years of Androids), my instant reaction upon seeing the slider switch was "Ah! FINALLY! I can feel at peace in the knowledge that software vulnerabilities are powerless to hack my camera or microphone!"
Of course, stupidly, the slider doesn't "mute" my camera or microphone, but only my speaker. For Apple to modify this slider so that it mutes my camera and microphones would require the daunting addition of two transistors. And the act of such a simple modification would put an end to the incredibly creepy, Orwellian possible reality that we all risk taking a part in every time we glance at the familiar tiny screens we have become so intimately glued to.
Come on this is an overreaction. It’s a bug plain and simple. A bad one for sure but still Apple disabled the feature (allegedly) while they push a fix out. Shit happens.
As someone who bought an iPhone specifically for privacy reasons, I'm not really upset about this. What I'm concerned about is passive, mass-scale corporate surveillance, not a one-off bug that allows an individual with mal-intent to listen through my microphone for a few seconds and also let me know about it.
It generally happens because you don’t follow a defined state machine. An example of how this might happen is when starting the call the microphone isn’t opened. Then you add someone else to the Group FaceTime, the event handler for they didn’t stop to consider if the call is active (just assumed it is) and now the code for that handler opens a new port to the microphone so that it can encrypt the audio stream differently for that recipient.
Super easy and not remotely malicious. It’s a failed state check.
The actual bug here might be different but that’s an easy example. But it may also effectively be the bug since all the examples mention adding yourself to the call.
Something similar happened to me: I got a FaceTime call and both my phone and an iPhone nearby rang! Both contacts were known to the caller, but the AppleIDs were of course different.
My guess is that it’s an unfortunate combination of several problems:
- audio and video capture has to start going before call is actually established at signaling level, in order to minimize call establishment delay. Audio maybe going through Bluetooth, for example, and waking up Handsfree mode of BT may take 1-2 sec
- most of the group calling functionality was developed by a separate team, and group calling signaling may be loosely integrated at UI level, where, once UI triggers a switch to a group call - internally, the whole new library may kick in and get the current 1-1 call state transferred to it.
- when this “transfer” happens, the state of the first 1-1 call gets affected (at either local or remote side (due to signaling), which leads to either remote side think that the call was answered (a lack of protection in the call signaling state machine to ensure it was users UI action) or local side thinks it’s ok that remote users answers the call (in this case FT must have streamed audio even during 1-1 call establishment phase)
- lack of a check for your own phone number added to a call. This, due to having the same IDs/tokens twice in a group call, may lead to unexpected call signaling state machine switch
- lack of manual testing with focus on edge cases (like the described flow to repro the bug may not be the main flow for how users start group calls on FT)
I never worked at Apple, but I built VoIP stuff for the past 20 years.
If the mother did in fact submit a ticket a week ago, it's pretty shameful that the escalation / verification process took more than a week for a bug of this severity.
Interesting twitter account. First tweet 1/1/19, few followers, mostly politics, then a major bug report (not only in discovery but in knowing how to go through the reporting process). Not saying it’s fake at all - it looks 100% legitimate - but it adds some extra bit of weirdness to this story. Quite the providence, and a really bad bug. (edited for clarity)
This is the core provision addressed. Article identifies and reports on a direct privacy violation: unauthorized audio/video access to personal communications without consent or knowledge. Every element—bug description, reproduction steps, scope analysis—emphasizes violation of privacy rights.
FW Ratio: 67%
Observable Facts
Article headline frames the core issue: 'Major iPhone FaceTime bug lets you hear the audio of the person you are calling ... before they pick up.'
Article explicitly states the privacy violation: 'you can listen in to soundbites of any iPhone user's ongoing conversation without them ever knowing that you could hear them.'
Article notes lack of notification: 'There is no indication on the recipient's side that you could hear any of their audio.'
Article describes second privacy violation: 'if the person presses the Power button from the Lock screen, their video is also sent to the caller — unbeknownst to them.'
Article characterizes as rights violation: 'this poses a pretty big privacy problem.'
Page source includes Google AdSense ad code, indicating tracking infrastructure.
Inferences
By identifying non-consensual audio/video access as privacy violation, the article advocates for recognition and protection of privacy rights per Article 12.
The article's detailed documentation of the violation and its scope signals deep concern for privacy as a fundamental right.
The site's ad-tracking infrastructure creates structural irony given the article's privacy focus.
Article identifies and reports on a serious security vulnerability threatening personal liberty and security. It advocates for recognizing this threat and treating it with urgency.
FW Ratio: 60%
Observable Facts
Article states: 'A significant bug has been discovered in FaceTime and is currently spreading virally over social media.'
Article describes: 'The bug lets you call anyone with FaceTime, and immediately hear the audio coming from their phone — before the person on the other end has accepted or rejected the incoming call.'
Article reports Apple's response: 'Apple says the issue will be addressed in a software update.'
Inferences
By identifying the security threat and reporting on Apple's commitment to fix it, the article advocates for protection of personal security and liberty.
The article's treatment of the bug as 'significant' and 'spreading' signals serious concern about a threat to personal security.
Article is itself an exercise of free expression and the right to seek, receive, and impart information. Demonstrates independent investigation and reporting on a significant technology issue.
FW Ratio: 57%
Observable Facts
Article is published without paywall on 9to5Mac, providing free public access.
Article represents original reporting: '9to5Mac has reproduced the FaceTime bug with an iPhone X calling an iPhone XR.'
Article is authored and attributed to Benjamin Mayo, identifying the reporter.
Article contains specific technical information enabling readers to understand and protect themselves.
Inferences
By independently investigating and reporting on a significant technology security issue, the article exemplifies the exercise of free expression and the right to impart information.
The free, unrestricted access to the article supports the principle of free flow of information regardless of payment barriers.
Publication on a reputable news platform demonstrates institutional support for free expression on matters of public concern.
Article discusses remedies and effective recourse: Apple's software fix, interim offline measures, and user mitigations, advocating for the principle of effective remedy.
FW Ratio: 60%
Observable Facts
Article reports: 'Apple has taken Group FaceTime offline in an attempt to address the issue in the interim.'
Article states: 'Apple has said the issue will be fixed in a software update later in the week.'
Article advises users: 'if you are concerned, you should disable FaceTime in iOS Settings.'
Inferences
By reporting Apple's commitment to fix the bug and interim measures, the article frames the issue as requiring remedy and effective recourse.
The article empowers readers with immediate mitigation options, supporting access to remedy.
Article acknowledges potential for abuse of vulnerability, advocating for awareness of misuse risk. However, providing detailed reproduction steps also enables potential abuse.
FW Ratio: 50%
Observable Facts
Article explicitly warns: 'The damage potential here is real. You can listen in to soundbites of any iPhone user's ongoing conversation without them ever knowing that you could hear them.'
Article provides step-by-step exploitation instructions: 'Start a FaceTime Video call... Whilst the call is dialling, swipe up from the bottom...'
Inferences
The article advocates for awareness of the abuse potential of the vulnerability, signaling concern about preventing misuse.
Provision of detailed reproduction steps creates dual effect: enables user protection but also enables potential abuse, reflecting tension in security vulnerability reporting.
The article invokes justice and security by identifying and reporting a violation of personal privacy and security, aligning with the Preamble's commitment to dignity and justice.
FW Ratio: 67%
Observable Facts
Article frames the bug discovery as a justice issue: headline states 'Major iPhone FaceTime bug lets you hear the audio of the person you are calling.'
Article reports on remedy: 'Apple has said the issue will be fixed in a software update.'
Inferences
By framing a privacy violation as requiring immediate justice and remedy, the article aligns with the Preamble's commitment to human dignity and justice.
Site uses Google AdSense tracking, which contradicts the article's privacy focus, creating structural tension between editorial advocacy and platform practice.
build 1ad9551+j7zs · deployed 2026-03-02 09:09 UTC · evaluated 2026-03-02 10:41:39 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.
:format(webp)/cdn.vox-cdn.com/uploads/chorus_image/image/61159115/prism-slide-4.1419979622.0.jpg){kind=link}