Skip to content

How I Found a Flaw in Apple’s API

Cache Poisoning in Apple’s iTunes API

Connor Quigley ·

In July 2026, I found a cache-poisoning vulnerability in Apple’s iTunes Lookup API.

A single request could leave the wrong permission in a shared cache. The next website asking for the same URL could get that permission too, and its browser would refuse to let the page read the data.

The bug

Apple’s API returns public catalog information. Each response includes a CORS header telling the browser which website is allowed to read it.

The API copied the requesting website’s origin into that permission. But the cache reused the response for other origins, still carrying the first website’s permission. A successful response could become unusable to the next caller.

The response was missing Vary: Origin, which tells a cache that the requesting origin matters when choosing a saved response.

How I proved it

I kept the URL fixed and changed the Origin header between requests. The first response allowed origin A. The next request used origin B, but the cache returned the saved response: still allowing A.

I reversed the order and got the same result. Whichever origin went first supplied the permission that came back on later cache hits.

A fresh response could look correct, while a saved response carried a permission meant for someone else. Under the browser’s CORS rules, that mismatch prevents the page from reading the data.

  1. First request
    Origin Arequests URLCache MISSresponse savedAllows Amatches caller
  2. Next request · same URL
    Origin Brequests URLCache HITresponse reusedStill allows Awrong origin
Figure 1. Same URL, different origin. The cache returns A’s permission to B. Simplified from the original header tests.

Why it mattered

The shared cache gave a single request reach beyond its sender. Other websites requesting that exact URL through the affected cache entry could receive the poisoned permission too. A page using the API for app information could lose access to that response until the cached copy was replaced.

The API could still return HTTP 200, its normal success status. A check that only looked for a successful response could miss the failure happening in the browser.

I reproduced the behavior across additional lookup and search paths. The finding concerned availability of public catalog data, not access to private accounts.

Apple’s fix

I sent Apple the report on July 5 and expanded it with affected lookup and search variants on July 9. After investigating, Apple addressed the issue with a service update.

On November 12, I retested six path and query combinations with 24 requests. The three supplemental paths produced six cache hits across different origins. Each returned a public wildcard permission without allowing credentials, so it no longer tied the cached response to the first caller.

The public /lookup and /search routes returned Vary: Origin and appropriate permissions too, although those requests were cache misses. The original mismatch did not recur in the tested requests.