Planck Defense uses Rently to control physical access to our own building, so when we analyzed it under Rently’s responsible disclosure program, the target was our own front door and our own account. The resident app showed us the two codes we manage. The API behind it, asked about our own property, returned every code the property had, including the master PIN the app never shows a resident. It is now public as CISA advisory ICSA-26-237-01 / CVE-2026-75960, and Rently has patched it. Planck Defense · Offensive Security Team · August 28, 2026 · 8 min read Advisory at a glance.CVE-2026-75960 · CISAICSA-26-237-01· CWE-522 Insufficiently Protected Credentials · CVSS v3.18.1 High, v4.08.7 High· Rently Smart Home ≤ 20.1.0 · patched server-side, no user action required · no known public exploitation · reported to CISA by the Planck Defense team. There is often a quiet gap between what an app shows you and what its API actually returns. Usually the difference is cosmetic. Here, the difference was a master PIN that opens every door in the building. This is the story of the Rently smart-lock vulnerability we found and reported, CVE-2026-75960: how the app hid the master PIN while the API handed it over, how we confirmed it on our own property, the honest conversation about how serious it really was, and what any team shipping an API can take from it. It is a first-hand account, written by the team that reported the issue to CISA. Rently’s mobile app pins its TLS certificate to stop anyone from inspecting its traffic, which is a sensible piece of hardening. As part of a routine mobile assessment, and only ever against our own account and our own property, we bypassed the pinning with Frida instrumentation so we could observe the API the app talks to. Authentication was solid: every request required a valid bearer token, and unauthenticated requests were rejected cleanly. The problem was never authentication. It was what the server chose to send back once you were authenticated. Inside the resident app, our property looked exactly as expected: the two access codes we had set up, and nothing else. But an app is only a view. To see what the platform actually holds, you have to look at the API that populates that view. The property-scoped endpoint that fills a property’s device screen returned far more than the app displayed. For our own property, the response carried the complete code table: not two entries, but a full set of slots. A couple we recognised as ours. Most we had never created and could not find anywhere in the app. And in one slot sat the property’smaster PIN, the code a property manager uses, in plaintext, handed straight to a resident’s authenticated session. Illustrative reconstruction. All values are masked and fabricated; real codes, addresses, and identifiers are omitted. The app was filtering; the API was not. That distinction is the heart of the finding. Client-side filtering is a user-experience choice, not an access control. Anything the server sends, a determined user can read, no matter what the app chooses to render. A code in a JSON response is a data-exposure finding. We wanted to know whether it was more than that, so we validated it against the only property we had any right to test: our own. First, attribution. Two of the returned codes matched the codes visible in our own app, confirming the response really did belong to our property. Then, impact. We took the master code the app had never shown us and entered it onour own lock. The door opened, and moments later Rently’s own app sent a push notification confirming that a master code had been used to grant entry. During coordination, the vendor initially felt the score was too high, on the view that this was an access-escalation issue that required app access and touched one property at a time. It is a fair instinct, and worth answering directly, because it surfaces in almost every disclosure. CVSS is scored on the worst case, not the best.A resident holding the lowest meaningful privilege who can extract a master-level override code they were never provisioned is, by definition, performing both horizontal and vertical privilege escalation. A master PIN is not a personal code; it is the property-wide override a manager holds, so a single leak is a whole-building exposure rather than a one-unit one. When the asset behind the control is a physical door, and the people on the other side of it, that is a catastrophic failure of access control, not a minor escalation. CISA scored it 8.1 (v3.1) and 8.7 (v4.0), High. After the vendor first reported the issue resolved, we retested. Master codes werestill exposed, this time through a sibling endpoint the initial fix had not covered. This is the most important operational lesson in the case:fixing the instance is not fixing the class.The same over-exposure pattern lived on more than one endpoint. Reporting the incomplete fix prompted the vendor to run a full analysis across their API and deploy a ...