Report 131 · Luxury Home Security
In March 2024 the U.S. cyber agency published a 9.1-out-of-10 advisory about a hardcoded password in a smart-lock app, and the coverage said attackers could remotely unlock doors. Eight weeks later CISA revised the same advisory to 4.3. The interesting part is not that a number moved. It is which part of the story the revision touched, and which part it left exactly where it was.
If you own an access-control system, at some point you will read a headline that says a researcher can open your door. Sometimes that is true. Often the headline is a compressed version of a document that says something narrower, and occasionally the document itself changes after the headline is written.
The clearest worked example I know is CISA advisory ICSA-24-067-01, about the Chirp Access mobile app. It is two and a half years old now, and I am not writing about it as news. I am writing about it because the full revision history is public, both endpoints are quotable, and it teaches the single most useful skill an owner of connected security hardware can have: reading a vulnerability advisory instead of reading about one.
On 7 March 2024, CISA published the advisory and assigned it a CVSS score of 9.1 out of 10. The description of the problem, as reported contemporaneously by Brian Krebs, read:
Chirp Access improperly stores credentials within its source code, potentially exposing sensitive information to unauthorized access
That sentence is accurate and also nearly content-free about impact. "Credentials" could mean an unlock token. It could mean an analytics key. The 9.1 did the interpretive work for most readers, and 9.1 in the CVSS range means critical. The coverage that followed went where you would expect, toward remote unlocking of doors.
The underlying credential was a hardcoded value named BEACON_PASSWORD, sitting in the app's source. The researcher who found it, Matt Brown, is a senior systems development engineer at Amazon Web Services, and he reported it to Chirp in March 2021.
The advisory went through three revisions: Update A on 23 April 2024 (mitigations), Update B on 25 April (feedback integrated into multiple sections), and Update C on 2 May 2024, which updated the risk evaluation and the CVE description. The scores on the live page today are CVSS v3.1 4.3, vector AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, and CVSS v4 2.3.
The current vulnerability overview describes a genuinely different event from the one in the headlines:
An attacker within Bluetooth range could change configuration settings within the Bluetooth beacon, effectively disabling the application's ability to notify users when they are near a Beacon-enabled access point.
And the advisory now states the limit directly:
This variable cannot be used to change the configuration settings of the door readers or locksets and does not affect the ability for authorized users of the mobile application to lock or unlock access points.
So the attack is: stand within Bluetooth range, reconfigure a beacon, and stop the app from telling a resident that they are near a door. That is a real defect. It is not a door opening.
This is the part worth learning, because it generalizes to every advisory you will ever read about your own equipment. The number is a summary. The vector is the actual claim, and it is short enough to read in full.
Take the current one apart. AV:A is attack vector "adjacent", meaning the attacker has to be on the local link, which here means physically within Bluetooth range of the beacon. That is a fundamentally different threat model from AV:N, network, which means anyone on the internet. Then the three impact metrics: C:N no confidentiality impact, I:L low integrity impact, A:N no availability impact.
A vector reading "someone standing outside your building can slightly affect integrity and nothing else" is not a 9.1-shaped problem, and CVSS v4 scores it lower still, at 2.3. Whenever you see a severity number quoted without its vector, you are being handed the conclusion without the premises. The premises are one line long and they are always published.
Three questions get you most of the way on any advisory about your own hardware. Where does the attacker have to be. What can they actually affect. And has this advisory been revised, which you check by looking for the update history rather than assuming the first version is the current one.
Here is where I part company with the second wave of coverage, which broadly treated the revision as an all-clear.
Chirp reported the outcome accurately. Its public statement, issued 25 April 2024, says CISA "formally downgraded its Risk Evaluation related to the Chirp software, concluding there are no vulnerabilities in the Chirp code base that could be used to take control of and gain unrestricted physical access to locks, doors, or gates managed by Chirp Systems." On the technical question, that matches the advisory, and the company adds that it conducts "regular penetration testing and scans of our software."
But go back to the timeline. Brown reported the weakness in March 2021. CISA published in March 2024. Per Krebs's reporting, CISA went public in part because Chirp Systems had not responded to either CISA or the researcher. Three years passed between a disclosure and a public advisory, and what closed that gap was a federal agency publishing, not a vendor answering.
The severity revision addressed the impact estimate. It did not address, and could not address, the response record. Those are two separate findings that arrived in one news cycle, and only one of them got corrected. If you are choosing who to put on your gate, the second finding is arguably the more predictive of the two, because it tells you what happens the next time somebody finds something.
That is the part no CVSS score encodes. There is no field in the vector for "does this vendor answer the phone."
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. Full policy here.
My background before that was electronic warfare and counter-IED, which is a career spent on exactly this question in a harsher setting: given a claimed capability, what does the adversary actually have to do, from what range, to produce what effect. Range and effect were the two things that determined whether a threat mattered, and a report that gave you neither was noise. Advisory vectors are the civilian version of that discipline. AV:A is a standoff distance. The impact triplet is a damage estimate.
An estate with a real integration will accumulate advisories, because a system with cameras, readers, a panel, a network video recorder and a mobile app has many vendors and therefore many disclosures. Reacting to every severity number at face value is exhausting and mostly wrong. Reading the vector takes ten seconds and is usually right.
Chirp Access is a multifamily and rental access product, not an estate system. Chirp Systems was acquired by RealPage, a property-management software firm. The reasoning here transfers to any advisory about connected access control. The product itself is not one I am recommending for or against, and I have no basis for either.
I did not test the app, inspect its source, or independently verify the technical claims of either side. Both the original 9.1 and the revised 4.3 are CISA's assessments, and CISA revised its evaluation, in Krebs's words, "based on feedback from Chirp." I am reporting a documented disagreement and its documented resolution, not adjudicating it.
I did not retrieve the original March 2024 advisory text or its original CVSS vector from a primary archive. The 9.1 figure and the original wording quoted above come from Krebs on Security's contemporaneous reporting, which quotes them directly. The current scores, vector, update history and overview text all come from the live CISA advisory, which I opened. Because I do not have the original vector, I cannot show you exactly which metric changed, only that the score fell from 9.1 to 4.3.
Krebs reported that approximately 50,000 units use Chirp smart locks with August's API. That figure is specific to that integration as reported in April 2024, and I have not verified it or found a current number. I also did not verify whether a fix shipped, what app versions are affected today beyond the advisory's own statement that it covers all versions in non-networked beacon configurations, or the current state of the product. Nothing here is a claim about whether any Chirp deployment is safe now.
This is not my research. My published work is in microwave spectroscopy. The vulnerability was found by Matt Brown, and the assessments are CISA's.
A severity score is a model of impact under assumptions, and assumptions get revised. That is the system working, not the system failing. The failure mode is downstream, where a 9.1 becomes "attackers can unlock your door" and a later 4.3 becomes "never mind", and neither sentence survives contact with the advisory it came from.
The document is short, it is free, it lists its own revision history, and its vector string tells you the two things you actually want to know: how close the attacker has to get, and what they get when they arrive. Read that line and you will be better calibrated than most of the coverage.
Then read the dates, because the timeline is a second finding hiding behind the first. A number that fell from 9.1 to 4.3 is reassuring. Three years of silence between a report and an advisory is not, and no revision changed it.
Scope note: this report describes one published CISA advisory and its documented revision history as a worked example of how to read a vulnerability advisory. It makes no claim about the current security of any Chirp Systems product or deployment, does not independently verify either party's technical assertions, and is not a recommendation for or against any vendor. Severity scores quoted are CISA's assessments as published on the dates given. Disclosure: the author helps design AI security systems for a veteran-owned home-security company, as stated in the body of this report, and does not own that company.
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.