Genie cache bug leaked garage doors to random Home Assistant users

A Genie cache bug pushed strangers’ Aladdin Connect garage doors into Home Assistant for about 18 hours on September 6, 2026. One user with a single door counted 425. Users timed each stranger’s stay and found a hard ceiling near 300 seconds, the default cache lifetime on AWS API Gateway . I rebuilt the same leak on a stock nginx cache.

What happened to Aladdin Connect on September 6?

At 03:43:25 UTC on September 6, one Home Assistant install created its first foreign garage door. A second install did the same two seconds later. In that same second, each owner’s real door went unavailable. Both timestamps come from matt-putz’s report and AYapejian’s report on GitHub.

Home Assistant itself was not the cause. The bug hit versions 2026.8.3 and 2026.9.0, on HA OS and Docker installs alike, and nobody had restarted or reloaded anything. Meanwhile, the Aladdin Connect phone app from Genie kept showing and opening each owner’s real door the whole time.

The issue itself, Aladdin Connect Spontaneously Creating Doors , collected about 70 comments. On r/homeassistant , the thread Aladdin Connect integration suddenly adding random garage doors drew 88 votes and 44 comments. Commenters there counted 78, 200+, 245, 249 and 253 foreign doors.

A second thread, I somehow am connected to 258 Aladdin Connect doors? , went up on September 11, five days after the fix. Replies pointed the poster back to the first thread, and nobody has opened a new GitHub issue. It isn’t clear whether that is a fresh leak or 258 leftover entities on an install that never reloaded.

Genie contacted Home Assistant contributor Jamie Magee, who posted the vendor’s account in the issue:

The same comment says the extent of the data exposure and any effect on door commands were still unconfirmed. Genie has not published a post-mortem or a status page note.

What did Home Assistant users see of other people’s doors?

Each foreign door arrived as a full Home Assistant cover entity. It came with open and close buttons plus the door’s live open or closed state, cloud link status and backup battery level. Strangers saw each door with the same buttons its owner had.

Many owners had named their doors after their street address. One user saw a door named after a street address in Arizona. That turns a garage door’s state into a record of when the people at that address leave and come home.

If you saw other people’s doors, assume your own door sat in someone else’s Home Assistant too, as matt-putz pointed out in his report.

The first Reddit poster, u/_golden_brown_, tried to open one foreign door, and Home Assistant said it would not open. The same user later warned others not to use a full address as a door name.

Could anyone open a stranger’s door?

Nobody knows. waterfalls11 posted screenshots of foreign doors with controls that looked live. However, slotdawg sent one close command to a random door, and its state never changed. Others, such as moriahmorgan , saw the foreign doors as unavailable.

Users who bridge Home Assistant to Alexa woke up to a stream of “ready to control” announcements for doors named things like “Left.” forslundc shut it all down after 13 of them. The user with 600+ entities wondered aloud what “Alexa, open my garage doors” would have done.

Every new foreign device also fired a device_registry_updated event, so AYapejian had an unfiltered automation fire about 67 times overnight.

Why did Home Assistant users see other people’s garage doors?

A cache answers repeat questions without asking the database again. To decide whether two questions are “the same,” it looks at a key. If the key is just “list my doors” and leaves out who is asking, the first person’s answer goes to everyone who asks next.

Genie wanted the cache because Home Assistant polls the Aladdin Connect cloud every 15 seconds for each account. That’s 5,760 requests a day per door owner.

What users measured

matt-putz sent 67 direct GET /v1/devices requests with his own login token. For at least 197 seconds, every reply was the same stranger’s three-door household, byte for byte, with the same ETag. Across 104 foreign households, the length of each stranger’s stay peaked at 300 to 314 seconds (31 of 103 stays). None lasted longer, and no household ever came back.

On a separate install, AYapejian logged 49 households in about two hours, with a median gap of 135 seconds and nothing past about 300. His own door came back for exactly one 15-second poll at 05:07:56 UTC. Most likely, that one request slipped through to the real database just as the cache turned over.

matt-putz also predicted that, if one shared cache was to blame, every install would see the same strangers in the same five-minute windows. The prediction held when alexmbright saw the same address-named door that forslundc saw, on a different install.

Which AWS setting fits the numbers

API Gateway response caching keeps answers for 300 seconds by default, up to a maximum of 3,600. It caches only GET requests unless told otherwise, and it builds the key only from the request parameters you pick. Leave the Authorization header out of that key, and every caller shares one cached answer.

The integration’s source shows every Home Assistant install sending its own login token plus the same hard-coded partner API key to one API Gateway endpoint. A cache keyed on that partner key, or on nothing but the path, would hand one household to every install.

matt-putz saw X-Cache: Miss from cloudfront on every reply and read that as “no cache here.” The same AWS page warns that CloudFront’s X-Cache header can’t tell you whether API Gateway’s own cache served the answer.

A second setting has the same fingerprint: Lambda authorizer result caching remembers who you are instead of what you got. AWS’s own examples set it to 300 seconds, and it caches by whatever identity source is configured. If that source was the shared partner key, the first user checked became everyone’s identity for five minutes. Genie only said “API Gateway caching,” so both remain possible.

The last row is my own reading of the AWS docs. Which setting Genie changed decides the command question.

Why Homebridge users were spared

The Aladdin Connect app never showed foreign doors. u/kylewhirl saw no stray doors with the Homebridge plugin, and bschatzow fell back to Homebridge while Home Assistant was broken. Both fit a cache keyed on something only Home Assistant installs share, most likely that partner key. Genie hasn’t confirmed that.

The first guess was the 2023 bug

A self-described pen tester on Reddit, u/Extreme-Edge-9843, called it an insecure direct object reference (39 votes). That bug class means asking for someone else’s device on purpose. The timing data points elsewhere: nobody asked for anyone else’s doors, and the cache handed them out anyway.

Omegapoint’s writeup on API Gateway header smuggling and cache confusion covers an earlier API Gateway flaw. Duplicate headers tricked the authorizer cache into reusing a policy until AWS patched it. Contributor arcivanov put the blame on design : the cache Genie built never checked whose token it was answering.

Reproducing the Genie cache bug on a stock nginx cache

To check how little it takes, I built the leak in the cache-key-leak folder of the benchmarks repo. A tiny Python API, origin.py , returns a different door list for each bearer token. In front of it, nginx 1.30.4 runs with proxy_cache turned on.

The location block in leak.conf has no proxy_cache_key line at all.

location /v1/ {
    proxy_pass http://127.0.0.1:18081;
    proxy_cache api;
    proxy_cache_valid 200 300s;
    add_header X-Cache-Status $upstream_cache_status always;
}

Stock nginx caches replies to requests that carry an Authorization header without complaint. It ignores the shared-cache rule in RFC 9111 that says it shouldn’t, so no special setting was needed. run.sh builds nginx into a local folder and runs four stages:

git clone https://github.com/botmonster/benchmarks.git
cd benchmarks/cache-key-leak
./run.sh --yes

In stage one, Alice, Bob and Carol each ask for their own doors inside the 300-second window:

alice  asks -> own doors                (X-Cache-Status: MISS)
bob    asks -> LEAK: alice's doors      (X-Cache-Status: HIT)
carol  asks -> LEAK: alice's doors      (X-Cache-Status: HIT)
alice  asks -> own doors                (X-Cache-Status: HIT)
origin log:
  11:19:06 origin answered for alice

Stage two scales the Home Assistant pattern down. poll_sim.py runs 40 clients polling about once a second for 90 seconds, against a 5-second cache. 97% of the 3,274 polls came back with someone else’s doors.

Fourteen different accounts got handed out. Each one lasted 5.7 to 6.1 seconds, which is the cache lifetime plus up to one poll of lag. Scale that up and it is the 300-to-314-second peak Home Assistant users measured.

The broken version looked healthy, with a high hit rate and an empty error log. On a cost dashboard, the leak looks like the caching project working.

Three ways to fix it

• Put the token in the key. One line in fixed-key.conf gives every user their own entry, and Alice’s second request still hits the cache.
• Mark per-user replies private. When the origin sends Cache-Control: private, nginx stores nothing and every request goes through.
• Cache below the login check. Resolve the account first, then use the account ID as the key, so each entry belongs to one customer.

The one-line fix from the first option:

proxy_cache_key $scheme$proxy_host$request_uri$http_authorization;

Genie is the vendor that said yes to Home Assistant

Jamie Magee flagged a license problem with the old Aladdin Connect code in 2024. Genie then relicensed its Python SDK in 2025. The integration was re-added to Home Assistant later that year, with Genie’s own account listed as code owner. Setup needs a Home Assistant Cloud subscription for the login step.

Chamberlain went the other way: it blocked third-party myQ access , and Home Assistant removed the myQ integration in release 2023.12.

With that history in mind, moriahmorgan didn’t blame Genie for wanting lower cloud bills. cefoster0 said Genie’s support was why they bought three new Genie openers. On Reddit, u/cbarth3 noted that Genie openers still work with a plain relay, and that Genie shipped an integration where Chamberlain locked people out. u/amd2800barton argued (29 votes) that full local control would save Genie more bandwidth than any cache.

Caching was a fair response to polling. The lasting fix is a push model, so nobody has to poll every 15 seconds in the first place. Genie told Jamie Magee it is looking into a callback API. The change also went out over the US Labor Day weekend, as codebykat noted .

The second cross-account leak at Aladdin Connect in three years

In a 2024 advisory , Rapid7’s Deral Heiland listed CVE-2023-5879, CVE-2023-5880 and CVE-2023-5881 in the Aladdin Connect retrofit kit and Android app. The same advisory described a service API flaw: a logged-in user could ask for other device IDs and get other customers’ data. Genie said its own penetration test caught that one, and the fix went in about a month before Rapid7 reported it.

All The Things Best drew the same line between the two incidents.

What should Aladdin Connect owners do now?

• Reload the integration, or delete it and add it back. After Genie’s rollback, that alone cleared the foreign doors . You don’t need a new password, because the integration logs in through OAuth. Revoking the app link and signing in again is the cleaner step.
• Purge leftover foreign devices from the device registry and the recorder database.
• Check .storage/homeassistant.exposed_entities and turn off “expose new entities” for Alexa, Google Assistant and Assist, so the next surprise device can’t become voice-controlled.
• Clean up Alexa with the Alexa Device Manager extension from the Chrome Web Store, which worked for users in the thread. Its bulk delete stops after about 60 devices with a 429 error that lasts about 10 minutes.
• Filter automations that trigger on device_registry_updated by event_data.
• Consider a local path. ratgdo has a dry-contact mode for non-Chamberlain openers, and Tailwind is another option. A relay plus a reed switch also works, as in the Shelly garage door guide . Genie offers no local API.

Genie still hasn’t said whether someone else’s Home Assistant could have opened your door during those 18 hours. Until it does, plan as if it could have, and give your opener a local control path that no cloud cache can mix up.