Screen Time refused my app. Its service returned my Safari URLs.

The same app got two different answers about my Safari browsing records. Through the ordinary Screen Time framework, it was refused before the request left the app. From the system service holding those records, it received the URLs. The caller had not acquired any new authority between those results. The refusal was genuine. So were the URLs.

That contrast is the substance of my Screen Time finding, now covered by CVE-2026-112616. The restriction existed, but it ran inside the requesting app. The service releasing the data did not enforce the equivalent restriction. Apple's own software was correctly telling a cooperative caller to stop, then assuming that every caller would have passed through that conversation.

The returned addresses included the parts after the website's name: paths and query strings. Those are the portions that can distinguish a visit to a search engine from what someone searched for, or a visit to a large website from the particular page they viewed. I did not need the contents of a webpage to demonstrate a privacy failure. The recorded address was already private information my app was not authorized to receive.

The comparison mattered more than the successful result

I compared the two routes in the same app, without the Screen Time privileges that would authorize the read. The ordinary framework refused access before contacting the service; the service returned the recorded Safari URLs. Holding the caller and requested information constant left a specific discrepancy to explain: the app-facing check was being enforced, but the service was not making the corresponding decision.

The result reproduced on an iPhone and an iPad. On the iPad, I also confirmed it with a distribution-signed build that could not be debugged, ruling out dependence on that development convenience. Distribution signing describes the tested app’s configuration; it does not mean the app passed App Store review.

The rejection happened too early to protect the records

Screen Time's framework and its background service perform different jobs. The framework supplies code that an app uses to work with the feature. That code runs inside the app's process. The background service is a separate operating-system process with access to the records. Calling both of them “Screen Time” is perfectly reasonable in a product description; for this bug, the distinction is everything.

The supported framework checked whether the requesting app was entitled to ask about the selected browser's records. For an app that did not meet that requirement, it failed immediately. My analysis established that this refusal happened locally, before any request reached the service. It was a caller check, not a service deciding that a particular requester could not have the data.

The refusal lived in code running inside my app. That can catch a developer’s mistake, but it cannot constrain an app willing to avoid that code. The component with access to the records was the service, so that was where an independent caller check had to run.

The service could identify the app on the connection. Instead, on this path it selected the requested records without establishing the caller’s right to receive them. Knowing which records an app wants is not a reason to give it those records.

This is also why describing the issue as a Screen Time user-permission toggle bypass would be wrong. The failed check concerned the identity and role of the calling app. It was not a consent setting that I changed, tricked someone into accepting, or persuaded the system to forget. Moving the discussion to which switch a user should have turned off would assign the user a decision the implementation needed to make itself.

A URL is not just the name of a website

The difference between a domain and a full address can be the difference between knowing that someone used a search engine and knowing what they searched for. On sites that include the query in the URL, the search itself travels with the address. A hypothetical medical search makes the stakes clear: an ordinary-looking domain may be followed by a path or query identifying a condition or treatment. How much an address reveals depends on the site and on which visits Screen Time recorded; the receiving app does not need the page’s contents to learn something private.

The negative results help define the source. Other application categories I examined did not return content, and a Private Browsing visit did not appear in the Screen Time records. I obtained no page titles or page contents, cookies, credentials, underlying Safari history database, cross-user or cross-device records. There was no demonstrated write operation or account takeover. Those are limits of this finding; they do not alter the successful read of the recorded Safari URLs. Nor did these captures establish a complete history of every browsing session; they establish the addresses this service recorded and returned.

Fixing the decision where the data leaves

The threat model begins with an app running on the device. My research did not show a website or a remote stranger reading Screen Time over the Internet. It showed that an installed app without the necessary authority could receive private records from a local system service. Installation does not entitle an app to another app’s private records.

For the service, the essential decision is whether the verified caller may receive the selected records. That decision has to be enforced where the records are released. A framework can make the same check earlier for convenience, but the service cannot inherit a successful decision merely because the framework normally makes one. The application asking for access is not a reliable witness to whether its own request passed validation.

That is the architectural correction my report called for. Apple's advisory describes the shipped repair more generally: improved access control for an authorization issue that could let an app obtain sensitive user data. The public entry establishes the fixed-release coverage and impact; it does not describe the internal patch.

Apple’s Screen Time advisory for CVE-2026-112616

Apple lists the fix in the following releases, published October 26, 2026. These are the vendor’s supported-platform entries; my device testing described above was on iPhone and iPad.

• iOS 27.2 and iPadOS 27.2

• macOS Golden Gate 27.2

• visionOS 27.2

Install the applicable supported update and let it finish. The public entry does not report active exploitation; my tests establish the flaw, not whether someone used it against other people.

Apple credits Drin Raci of sentry.security, Chris Bailey - Short Circuit, Mustafa Calap (@ordinal0, dbg.re), Robert Mindo, N.M.Praveen Nawarathne (@zblockrat), Ilya Andr (andrd3v), and Sindre Sorhus. I appreciate the other researchers’ contributions and thank Apple’s security and engineering teams for addressing the issue.

Apple’s published Screen Time credits

The seven Apple CVEs credited to Short Circuit this October

Related: Spotlight checked a search, then widened its access

Apple’s advisories checked October 26, 2026.