The relationship between macOS and privacy has experienced some tense moments in recent years, from holes exposing sensitive data to controversies over how Apple validates which apps run on the Mac. It's no small feat; when we talk about disk access, passwords, or personal metadata, we're talking about the most valuable things we store on our computers.
The objective of this article is to put things in order and review, in detail and using clear language, the major incidents and vulnerabilities that have come to light: a TCC bypass dubbed Sploitlight, the High Sierra root scandal, problems with the T2 chip, the BuggyCow attack, the Keychain password breach demonstrated by Patrick Wardle, and the debate over OCSP traffic in Big Sur, as well as the Intelligent Tracking Prevention flaws in Safari. And, of course, what Apple has done and what you can do.
Sploitlight: The TCC bypass that set off alarm bells
Sploitlight is the name Microsoft researchers gave to a flaw that allowed users to bypass Apple's Transparency, Consent, and Control (TCC) system. The TCC ensures that an app doesn't access personal information without permission, but someone found a way around it.
What was at stake? According to researchers, the vulnerability could leak particularly sensitive information managed by Apple: precise location, photo and video metadata, preferences, search history, and even automatic email summaries. In short, exactly the kind of data anyone would be worried about imagining falling into the wrong hands.
Apple reacted quickly and closed the breach before it became public. With the March 15.4st macOS 15.4 and iOS 31 updates, data redaction and symbolic link validation were improved, directly targeting the vectors that enabled the bypass.
The background reading is clearNo matter how secure a platform's reputation is, the attack surface exists, and constant updating and review habits must be maintained. Technology protects, yes, but active vigilance is irreplaceable.
Passwords on the Run: From Key Managers to Wardle Tests
There was a particularly delicate period for Mac users. In this case, the issue of exposed passwords in key managers was discussed. Within this context, researcher Patrick Wardle explained and demonstrated how, using code or a malicious app, it was possible to access the system's keychain and uncover all passwords.
Keychain stores credentials in a database Protected by the user's master password (the same one used to unlock the system). Wardle demonstrated with a video how he could extract passwords from services as diverse as social networks and online banking. In his explanation, he even indicated that the recovered entries were not effectively encrypted against the intended attack.
Important nuance of riskFor the attack to succeed, the machine must be infected with malware and bypass Gatekeeper's protection. Common infection routes are well known: email attachments, fraudulent pop-ups, or corrupted apps. Gatekeeper, in fact, requires explicit permission before installing suspicious software.
Apple, as reported at the time, investigated the matter. No immediate announcements. While patches were being released, the guideline was the same as always: download only from authorized sources (e.g., reliable sources), heed Gatekeeper warnings, and keep the system up to date. The ideal scenario, as several sources suggested, was a corrective patch in subsequent versions.
IOKit and the kernel under the microscope: Ilja van Sprundel's research
Ilja van Sprundel of IOActive uncovered another front: : issues in Mac OS X that targeted IOKit and kernel functionality. His presentation at Hack in the Box (Amsterdam) was to detail how to manipulate elements of IOKit to chain vulnerabilities with system-wide impact.
The reasonable doubt then was the scope: how intrinsic the relationship with the hardware was and how far-reaching the dependencies were. Even the conference organizers acknowledged that the complete impact map was complex and that the outlook wasn't exactly promising.
Apple was notified and a responsible release was requested. At the time, the company didn't comment publicly, but it was assumed to be working on mitigations. This type of responsible disclosure process is key to ensuring patches arrive on time and without giving away bad actors.
The T2 chip: a guardian with a weak point
Since 2017, many Macs have incorporated the T2 chip., a coprocessor of its own design that offloads tasks from the main CPU: audio, storage management, I/O interfaces and, above all, cryptographic functions, secure boot and authentication with Touch ID within the Secure Enclave.
The controversy erupted when researchers confirmed that T2 was vulnerable to a combination of exploits originally developed for the iPhone, known as checkm8 and blackbird. The result was code execution on the chip itself, opening the door to high-level access to the system and its files.
To make matters worse, it was pointed out that the problem was hardware-related., so in theory there wouldn't be a definitive software fix. The underlying explanation was a developer interface that was left exposed and allowed access to firmware update mode without the expected barriers.
However, the attack is not trivial.: It requires advanced knowledge and training, although ironPeak has shown that a USB-C device running popular iPhone jailbreak software was enough to exploit the vulnerability on a Mac. Yes, even a cable can be a Trojan.
The hygiene recommendation is simple and effectiveConnect only trusted USB-C accessories and flash drives, don't accept cables or flash drives from dubious sources, and completely avoid borrowed ones. This is an increasingly exploited attack vector.
The High Sierra Mistake: Logging in as root without a password
Rarely has a bug caused as much alarm as the macOS High Sierra bug. This allowed users to log in as root without entering a password. This gave them complete control over the computer and, therefore, posed a very high risk to any user who hadn't corrected the configuration.
Apple reacted with Security Update 2017-001, which was automatically deployed on systems running version 10.13.1. The Internet Security Office classified the issue as highly critical, noting the privileged nature of the root account.
The root of the error was in the configurationThe root account, which should be disabled by default, was left active with a blank password; after several attempts, the system granted access. A fatal combination that made the attack trivial even without technical knowledge.
While waiting for the patch, Apple advised securing the root account Enabling it and setting a strong password. A quick step, but one with a significant security payoff, is always a good idea to review when something seems odd about the permissions.
BuggyCow: writing to disk behind the system's back
Project Zero, Google's security team, published a vulnerability in macOS Dubbed BuggyCow, it was an issue related to the Copy-on-Write (CoW) process, where memory and data are transferred to disk under certain conditions without proper notification to the macOS permissions management subsystem.
After notifying Apple and waiting the required 90 days Without a satisfactory response, Project Zero published the report and a proof of concept in the Chromium repository. The idea was to demonstrate how an attacker could modify files on disk without the system noticing in time.
Wired explained it with a very graphic analogy: like picking up a suitcase at the airport without checking the contents. The user assumes nothing has changed, but the reality is that the interior may have been altered. This mismatch is precisely what BuggyCow exploits.
To carry out the attack, malware is required on the machine., even if it only has basic permissions at first. At the time of its disclosure, Apple hadn't released a definitive patch, adding pressure to expedite the fix.
Big Sur, OCSP, and trustd: covert telemetry or security monitoring?
With the release of macOS 11 Big Sur came another clashDuring a service outage, researcher Jeffrey Paul claimed that macOS was sending Apple an identifier for every app you opened, along with the date, time, Mac model, internet provider, city, and state. He also reported that the trustd daemon was even bypassing VPNs and that the request was made unencrypted via OCSP.
Paul's argument went further, suggesting that, in practice, Apple would know when you work, what you run and how often, and that on Macs with M1 chips the platform would end up as closed as on iOS, where it is not possible to cryptographically disable parts of the system.
Another researcher, Jacopo Jannone, provided context.By analyzing the traffic, he concluded that macOS wasn't sending a hash of the apps, but rather opaque information from the developer's certificate, consistent with OCSP's native role in Gatekeeper. He argued that using plaintext HTTP avoids complexities and potential loops when validating certificates.
That does not mean that, with enough effort, it cannot be inferred which applications have been opened by mapping certificates to specific apps. But exfiltrating a list of apps is not the same as correlating certificate data, and that nuance is relevant to assessing the real risk.
Safari and ITP: When anti-tracking opens new trails
Safari's Intelligent Tracking Prevention (ITP), powered by machine learning techniques, attempts to reduce cross-site tracking by limiting how cookies and headers are used on domains classified as prevalent. To do this, it accumulates strikes when cross-site requests are detected, and, when a threshold is reached, applies restrictions.
Google researchers showed several problemsAny website could force strikes on an arbitrary domain to add it to a user's ITP list, and that list, with its unique status, could be interrogated to infer browsing history. In the worst-case scenario, that list could become a cross-site fingerprint, a trick similar to the one already known with HSTS.
The December updates mitigated many of these vectors.But, according to Google, the list approach and the potential for footprinting present a deeper challenge. There were no clear signs of exploitation in the wild, but the message is unequivocal: even the most sophisticated anti-tracking systems can open unexpected loopholes.
Good practices and useful resources to reduce your exposure
In addition to the patches Apple releases, your behavior makes a difference.Here's a set of concrete actions, aligned with the incidents we've seen, to keep risk at bay without going crazy.
- Update as soon as patches are available: Bugs like Sploitlight, BuggyCow, or High Sierra rooting prove that fixes arrive and are effective when installed in time.
- Be careful what you connect via USB-CWith the T2, we saw that a cable can be the vector. Avoid accessories of dubious origin and never use anything you find lying around.
- Download only from trusted sources and heed Gatekeeper alerts: you'll reduce the risk of malware gaining the foothold it needs to exploit vulnerabilities.
- Strengthens privileged accountsIf you have root enabled, secure it with a strong password and periodically review permissions and profiles.
If you need a quick hardening guide for macOS, consult the public recommendations available to users, such as those disseminated by the cybersecurity agency: download PDF.
Close the loop with backups and prudent browsing habitsRegular backups, reasonable distrust of attachments or pop-ups, and a critical eye on the permissions you grant to apps. It's not glamorous, but it works.
The recent history of macOS shows that serious holes, improvable design decisions, and rapid reactions from Apple coexist.Nothing is black or white. Between TCC bypasses, notorious stumbles like rooting, hardware vulnerabilities in T2, memory tricks like BuggyCow, keychain attacks, and the eternal tug-of-war between security and privacy controls in mechanisms like OCSP or ITP, the key remains a combination of updates, judgment, and best practices. Those who do their homework greatly reduce risk and keep their privacy safe without sacrificing the benefits of the ecosystem.
