Report 066 · Luxury Home Security
When someone says a smart lock was hacked, the picture in your head is a person at the door doing something clever to the lock. Four advisories published this year say that is the least likely version. They land on four different layers of one access-control system, and only one of them is anywhere near a door.
Ask most people what their access control consists of and they will name a lock. Maybe a keypad, maybe a card reader. One object, at one door.
Now trace what has to happen for that door to open. A credential lives in a phone or on a card. An app talks to a cloud service. A management server somewhere in a utility room holds the rules about who is allowed where and when, and pushes those rules out. A controller on the wall receives them. And at the very end of the chain, a small actuator closes a circuit and releases the strike.
That is five or six products from five or six companies, and any single one of them, misbehaving, opens the door. The lock is not the system. The lock is the last inch of it.
I went and read a year of CISA advisories covering these products, the same government feed I used for the camera post. What came back was almost a diagram. Four advisories, four layers, four completely different failure modes.
Advisory ICSA-26-148-04, republished by CISA on May 28, 2026 from an ABB security advisory, covers the ABB Busch-Welcome 2 Wire Door Opener Actuator. This is the least glamorous device in the chain: the switch actuator that fires the door release in a two-wire door entry system, the kind installed across apartment buildings, gated developments and larger homes. Headquarters Switzerland, deployment listed as worldwide.
CVE-2025-7705 is described in full as "authentication bypass due to compatibility mode enabled by default." The weakness class is CWE-489, Active Debug Code. The impact statement is one sentence and it is the only one in this whole set that says the quiet part:
"An attacker who successfully exploited this vulnerability could gain physical, unauthorized access to a Building where the product is installed."
Two things about this. First, nobody misconfigured anything. Compatibility mode was on by default, which means the exposure shipped from the factory in the correct, as-designed state. Second, look at the remediation, because it is unlike any other fix I have quoted on this beat. There is no firmware. ABB's instruction is a physical procedure performed on site: while the system is running, toggle the mode switch on the product from "Door-Open" to "Light" mode, wait one second, switch it back, then power-cycle the system. The advisory says that on reboot "the system will recalibrate itself during boot up and will correct the misconfiguration automatically."
Someone has to walk to the device and flip a switch. You cannot push that. It will not arrive overnight while you sleep. For a property with a dozen entry points, that is a work order, a ladder and an afternoon, and it is the reason this class of fix has an install rate close to zero in the field.
Now the part that matters most. This advisory carries a CVSS v3.1 base score of 6.8, medium. It is the lowest score of the four, and it is the only one that directly opens a physical door.
The reason that 6.8 is not a contradiction is in the vector string, which for this advisory begins AV:P. Attack Vector: Physical. The scoring system is telling you the attacker has to be at the device. Confidentiality, integrity and availability impacts are all rated high; what pulls the number down is the difficulty of reaching it.
That is a legitimate thing to measure and it is not the thing a homeowner is asking. CVSS answers "how exploitable is this, in general, across all deployments." An owner is asking "what happens to me if it goes wrong." Those questions have different answers, and the score only ever addresses the first.
I made the same argument about laboratory detection limits in a report on what "not detected" means: the number is a property of the measuring apparatus, not of the thing being measured. A CVSS score is a property of the rubric. Which is easy to demonstrate, because the third advisory in this set is scored by two different rubrics and comes out medium under one and high under the other.
Advisory ICSA-26-204-01, released July 23, 2026, covers Johnson Controls C-CURE 9000 and the victor application server. C-CURE 9000 is enterprise-grade access control, the platform behind badge systems at corporate campuses, and it turns up on large estates and family offices for exactly the reason you would expect: it is what integrators know. Headquarters Ireland, worldwide deployment. The advisory carries a headline CVSS v3.1 score of 9.6, critical, the highest of the four, across three CVEs.
CVE-2026-21655 is the one to read closely:
"Under certain circumstances, successful exploitation of this vulnerability could allow an unauthenticated attacker on the adjacent network to achieve arbitrary code execution on the C-CURE 9000 or victor application server, as well as connected clients (e.g., workstations of physical security personnel). Such an attack could impact physical security controls."
Unauthenticated. Adjacent network. Arbitrary code execution on the access-control server and on the workstations of the people watching the cameras. Nobody in this scenario ever approaches a door. They get onto the network, and from there they own the thing that decides which credentials are valid and the screens showing whether anything is wrong.
Give Johnson Controls credit where it is due, because this beat has published enough vendor silence to make the contrast worth stating. There is a real fix, version 3.20 and later for the application server, and for the web component the advisory notes the fix "has been validated through independent retest." That is the process working.
What interests me more is the mitigation list, because almost none of it is about patching. Isolate the servers on a dedicated network segment. Restrict access to port 8999 to only authorized systems. Firewall rules blocking unnecessary inbound connections. Least privilege on the server process. Application whitelisting. Monitoring for anomalous process creation by a specific named executable. That is an architecture, and it is the same architecture CISA recommends for cameras. The access-control server belongs on its own island for precisely the reasons the camera does, and in most residential installations I have seen, it is sitting on the house network next to a smart TV.
Advisory ICSA-26-197-07, released July 16, 2026, covers SALTO ProAccess Space, the management software behind a very widely deployed electronic access control line. Headquarters Spain, worldwide deployment. CVE-2026-11889, weakness class CWE-639, Authorization Bypass Through User-Controlled Key.
The summary states that successful exploitation "allows an authenticated attacker to escalate privileges and access spaces outside their assigned partition, within the same Salto ProAccess Space installation or system." It requires valid operator credentials and requires the partition feature to be turned on. The advisory is careful about this and so am I: "installations without partitioning are not affected."
Partitioning is worth explaining, because on a large property it is the entire point of buying software like this. You have a household, and separately you have staff, and separately you have trades and a property manager and possibly a guest wing that a family member controls. You do not want the landscaping contractor's scheduling manager to be able to see, let alone open, the primary residence. So you create partitions, and the software promises they are separate.
The flaw is in the promise. And SALTO's own remediation guidance is, to their credit, unusually honest about what that means:
"If feasible, disable the partitioning feature and operate under a single partition. When strong tenant separation is required, consider running separate Space instances (isolated environments) rather than relying solely on logical partitioning."
Read that as a general principle, because it is one. A logical partition is a promise made by software. Physical separation is a fact about the world. They feel equivalent right up until the code that enforces the promise has a bug, at which point one of them is still true and the other never was. When the separation genuinely matters, buy the fact rather than the promise. That is not a criticism of SALTO, who found it, fixed it in 6.13 and then told customers the uncomfortable thing. It is a criticism of how the rest of us read the word "partition."
This advisory is also the cleanest illustration of the scoring point from earlier: CVSS v3.1 rates it 6.5, medium. CVSS v4.0 rates the identical flaw 7.1, high. Same vulnerability, two rubrics, two answers.
Advisory ICSA-26-209-06, released July 28, 2026, covers the igloohome Smart Lock Mobile Application. Headquarters Singapore, worldwide deployment. CVE-2026-16581, weakness class CWE-540, Inclusion of Sensitive Information in Source Code, affecting the Android app version 3.2.3 and prior:
"In igloohome Smart Lock Mobile App versions 3.2.3 and prior, an Inclusion of Sensitive Information in Source Code vulnerability could allow an unauthorized actor to access functions or backend services that were not sufficiently protected by authentication controls."
The lock itself is not the subject. The app is, and the reason that matters is that an Android application is a file anybody can download and take apart. Looking inside a shipped app is not an attack requiring proximity, credentials or skill. It is reading.
Then read the remediation, which is the most interesting sentence in this entire set:
"igloohome have enhanced the access control mechanisms on backend services to ensure that only properly authenticated and authorized requests can interact with sensitive functionality. No user interaction is needed."
The problem was in the app on your phone. The fix was made on servers you do not own, cannot see, and were never told about. Nothing was asked of the owner and nothing was required of them, which sounds like unambiguous good news and mostly is.
Sit with the other half of it anyway. The security posture of your front door changed materially, twice, and you had visibility into neither event. You did not know it was weak and you do not know it is fixed, except that a government agency published a note about it. Compare the camera post, where the failure was a vendor who never answered. Here the vendor answered so completely that the owner was never part of the transaction. Both are, in a specific sense, the same fact: the thing determining whether your door is secure is not in your house.
In targeting you do not attack the armor. You attack the link. The armor is the part the designer thought about hardest, and it is usually genuinely good; the link is the part that had to exist for the system to function, is owned by somebody else, and got specified in a hurry.
Line these four up and the pattern is exact. The armor here is the bolt, and the bolt is fine. The links are a compatibility mode left on at the factory, a Windows application server reachable from an adjacent network, a partition rule enforced in software, and an API endpoint in somebody else's cloud. None of those requires being at the door. Three of them do not require being on the property at all.
Which extends the point I made about smart lock revocation. There the lesson was that encryption is not access control. Here it is one step out: the lock is not the system. You can buy an excellent lock, install it correctly, and have the door opened by a deserialization bug on a server in the basement.
Five decisions, none of which require becoming a network engineer, and all of which are cheaper before installation than after.
Draw the chain. Write down every product that sits between a person and an open door: the credential, the app, the cloud service, the management server, the controller, the actuator. Vendor and version for each. Most owners cannot produce this list, and you cannot check an advisory feed against equipment you cannot name.
Segment the access-control server. It belongs on its own network with no path to anything else, exactly as the cameras do. This is the single highest-value change on the list and it is what the vendor mitigations themselves lead with.
When separation actually matters, use separate systems. Not partitions, not roles, not permissions within one installation. The vendor said it plainer than I could.
Ask what lives in somebody else's cloud. Which functions stop working if the vendor's backend goes away, and which security decisions are being made there rather than on your property. You are entitled to that answer before you buy, and how a company handles the question tells you most of what you need to know.
Keep a mechanical fallback that works when all of this is down. Every one of these layers can fail, and the failure mode you want is a door you can still open with a key, not a door that has quietly decided everyone is authorized.
The design work behind that layer, deciding what each device is allowed to reach and how quickly an anomaly is recognized as one, is the part I actually build. To be exact about my role: I help design the AI security systems for a veteran-owned (SDVOSB) home-security company run by fellow veterans. I do not own that company and earn nothing from this link; I flag it because it is a field I work in and not only write about. Full policy here.
These are ICS advisories covering commercial and prosumer equipment. All four list deployment as worldwide, and all four are named above with their vendors and affected versions. Nothing here says a specific installation is vulnerable, and I am not claiming any particular property is exposed.
Three of the four have real fixes available: version 3.20 for C-CURE 9000, 6.13 for ProAccess Space, and a backend change already deployed by igloohome. The fourth has a documented on-site procedure. By the standards of this beat, that is a good year. The structural point does not depend on any of them being unpatched. It depends only on where they landed, which was at four separate layers of a system most owners think of as one object.
And the inversion I keep restating holds here too. An advisory existing for a brand means a researcher looked at that brand and a coordination process ran. SALTO, ABB, Johnson Controls and igloohome are all, on this evidence, companies that get audited and respond. A brand with no advisories has not been shown to be clean. Far more often, nobody has looked.
Every serious conversation about access control ends up being a conversation about how many organizations have to be competent at once for your door to stay shut. On a modern estate that number is not one. It is the lock company, the software company, the integrator who configured the partitions, and whoever operates the cloud service the app talks to.
You cannot make all of them competent. You can decide how much each of them is trusted with, and you can insist that the separations you are relying on are real ones rather than settings. Then a bad year at any one vendor is an inconvenience instead of an open door.
Scope note: all four are ICS advisories covering commercial and prosumer equipment, with deployment listed as worldwide in each case. This report makes no claim about the security of any specific installation, nor about any product not named in these advisories, and the absence of an advisory for a brand is explicitly not evidence that the brand is secure. Where a fix exists it is stated above. The targeting analogy in the section on links versus armor is the author's own professional background and is not sourced to CISA.
U.S. Army combat veteran (Counter-IED / Electronic Warfare), peer-reviewed researcher in microwave spectroscopy, and founder & CEO of Shroombiosis. Consults on laboratory operations, AI, and supplement formulation.