EUVD-2026-86829
GHSA-vx6h-rcwq-vg89
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as legitimate booked guest
-
DeliveryCapture unlock API request
-
ExploitSubstitute another room/door identifier
-
ExecutionServer skips booking-ownership check
-
ImpactUnauthorized room unlock and physical entry
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires a valid authenticated guest account with an active booking at an affected Akia-managed property; the attacker then manipulates the client-supplied room/door identifier in the unlock request, which the server fails to authorize against that guest's booking. Limiting factors: authentication and a legitimate booking are prerequisites (not truly unauthenticated despite the input vector's PR:N); the impact is confined to physical rooms at a single affected property (remote attack, local effect); and the service was reportedly remediated server-side as of 2026-09-19, so it is no longer exploitable. |
| Impact | This is a genuine, high-impact authorization flaw whose real-world urgency is tempered by two strong mitigating signals. The technical impact is severe: CWE-639 (IDOR / missing object-level authorization) in the Akia keyless-entry cloud means an authenticated guest can unlock rooms other than their own, translating a web flaw directly into unauthorized physical access. However, the provided CVSS 4.0 vector (8.4) contains an internal conflict: it lists PR:N (no privileges) while the description explicitly requires an 'authenticated guest' - the flaw is authorization bypass by an already-authenticated user, so PR:L is correct and PR:N overstates reachability. The vector's UI:A (active user interaction) also appears unjustified since the attacking guest acts alone. Critically, the reporter states the service is no longer vulnerable as of 2026-09-19, so this is a remediated cloud-side issue rather than a live, patch-your-fleet emergency. No EPSS score, no CISA KEV listing, and no public POC are provided, and because it is a single-tenant SaaS fix there is no customer action to take. Net: technically serious (physical safety) but low ongoing operational risk given server-side remediation, single-property blast radius, and required authentication. |
| Exploit ScenarioDerived | An attacker books a room at an Akia-managed property, logs in as a legitimate guest, and intercepts the mobile/app unlock API call. They substitute a different room or door identifier in the client-supplied request; because the server does not verify that identifier against their own booking, the door unlocks, granting physical entry to another guest's room. No public exploit code is identified, and the underlying service has since been remediated (per reporter, 2026-09-19). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
An authenticated guest with an active booking could unlock rooms other than their own in Akia's keyless entry cloud service by tampering with the client-supplied room or door identifier, because the unlock action was not authorized server-side against that guest's booking-resulting in unauthorized physical access to guest rooms at the affected property. The independent assessment rates this as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N and notes the attack is remote but the impact is local to a single property. Akia reportedly remediated the service server-side as of September 19, 2026; no public exploit code or CISA KEV confirmation was identified at time of analysis.
RemediationAI
Akia reports the service is no longer vulnerable as of September 19, 2026, via server-side remediation; no CVE-specific patch version or customer-side update is provided in the available data, so property operators should confirm with Akia that their deployment uses the remediated backend and that unlock requests are validated server-side against the authenticated guest's active booking. If that confirmation is unavailable, reduce exposure by temporarily disabling keyless mobile unlock for guest rooms and relying on front-desk-issued credentials, or require staff-assisted verification for any unlock that falls outside the guest's booking-accepting the operational overhead and potential guest-experience impact. Monitor access-control logs for unlock events not tied to a valid booking, and review the vendor's product page at https://www.akia.com/platform/keyless-entry for any advisory updates. Any integration or property still running a legacy client should be updated or removed from service until the server-side authorization check is verified.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key), a form of insecure direct object reference in which the server trusts a client-provided object identifier-here the room or door ID used by the Akia keyless entry cloud service-without checking whether the authenticated guest is authorized to unlock that specific door. The attack path requires a legitimate guest account with an active booking at an affected property; the guest then alters the unlock request's room/door identifier, and the missing server-side object-level authorization permits the unlock. The independent assessment assigns CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, reflecting remote exploitation, low complexity, authenticated privileges, no user interaction, scope change, and high confidentiality/integrity impact with no availability impact. The provided input vector lists PR:N, but the authoritative assessment indicates a valid authenticated guest account is required. No CPE strings were provided; the only reference is Akia's keyless entry product page, and the service is cloud-hosted, so traditional version-based patching is not applicable.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:L/VA:N/SC:H/SI:H/SA:N
Authenticated guest so PR:L (not PR:N); attacker acts alone so UI:N; cloud auth flaw yields physical room access so S:C with C:H/I:H, A:N.
Primary rating from Vendor (5a6e4751-2f3f-4070-9419-94fb35b644e8).
CVSS VectorVendor: 5a6e4751-2f3f-4070-9419-94fb35b644e8
Lifecycle Timeline
2DescriptionCVE.org
Insecure Direct Object Reference / missing object-level authorization in the Akia keyless entry cloud service. The unlock action is relying on a client-supplied room/door identifier that is not properly authorized server-side against the authenticated guest's booking. An authenticated guest could unlock rooms other than their own, resulting in unauthorized physical access to guest rooms at an affected property.
As of 19th September 2026 the service is no more vulnerable to this attack (feedback received by the reporter).
The attack is remote but the effect is local to an affected property.
Technical POC Analysis
Bug class: CWE-639, Authorization Bypass Through User-Controlled Key - an IDOR / missing object-level authorization (BOLA) flaw.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
1 PoC candidate from github (unverified)
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
Akia's keyless entry cloud service is affected by an authenticated guest authorization flaw that can permit access to rooms other than the guest's booked room, creating unauthorized physical access at affected properties. Hotel operators and their guests face immediate safety, privacy, and liability exposure, and Akia customers should verify that the reported server-side remediation is complete before relying on the platform. Leadership should treat this as a physical-security incident with reputational and legal consequences, not just an IT vulnerability.
No vendor-released patch identified at time of analysis; Akia reportedly remediated server-side as of September 19, 2026. Until verified, enforce server-side booking-to-room authorization, restrict guest unlock privileges to the guest's active booking, monitor and audit unlock events for cross-room access, and provide front-desk physical key or staff-escort fallback for affected properties.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB