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 · CISA ICSA-26-237-01 · CWE-522 Insufficiently Protected Credentials · CVSS v3.1 8.1 High, v4.0 8.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’s master 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 on our 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 were still 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 proper server-side fix for all users. Always verify a fix yourself, and always assume a flaw class appears in more than one place.
Throughout, the vendor engaged constructively and CISA coordinated the process end to end. The issue is fixed, and that is the outcome that matters. Our thanks to both for a clean coordination.
None of this is exotic. It is the same discipline that decides whether an ordinary API is a well-documented interface or an extraction tool, here with a lock on the end of it. If you want to know what your own API authorizes, that is precisely the question agentic pentesting is built to answer.
CVE-2026-75960 is an insufficiently protected credentials vulnerability (CWE-522) in Rently Smart Home versions 20.1.0 and earlier, published by CISA as advisory ICSA-26-237-01. A property-scoped API endpoint returned a property's full set of smart-lock PIN codes, including the property's master PIN, to any authenticated user, even though the resident app displays only the user's own codes. It was rated CVSS v3.1 8.1 and v4.0 8.7 (High), and Rently has patched it server-side.
It was a data-exposure and authorization failure. The API returned data the resident app deliberately hides: the full code table for the property, including the master PIN, because the server never scoped its response to what the requesting resident is allowed to see. CISA classifies it as insufficiently protected credentials (CWE-522), and in OWASP API terms it is broken object property level authorization, returning fields a caller should not receive. Because the lock codes came back in plaintext, a data-exposure bug turned into a physical-access one.
CISA reports no known public exploitation targeting this vulnerability at the time of publication. It was found and reported through coordinated disclosure, tested only against the researcher's own property and account, and fixed before the advisory was published.
Scope every response to the requester: return only the data the authenticated user is entitled to, and enforce object-level authorization on every resource-scoped endpoint before returning it. Never rely on the app to hide fields the API still sends, and never return plaintext secrets such as lock codes, return a count or masked values instead. Test for it by authenticating as one account and requesting another account's objects across every endpoint, which is exactly what agentic API penetration testing does.
A close cousin: the API authorization flaws scanners miss, explained in full.
Read → GuideSpec-driven testing of every operation, with cross-account authorization at its core.
Read → PolicyHow we report what we find, and how to report something to us.
Read →The same class of flaw, on your own attack surface, before someone else finds it. Point Operator at your API and see what it proves.