Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessDownload public Viidure APK
-
DeliveryDecompile and extract hardcoded credentials
-
ExploitAuthenticate to cloud storage bucket
-
ExecutionOverwrite firmware/app binaries
-
ImpactCompromise downstream dashcam devices
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Credential externalization
MITRE ATT&CK
2 techniques across 2 tactics: Persistence, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | No special server-side conditions - the credentials are permanently and plaintext-embedded in the shipped compiled Android binary, so any party who obtains the publicly distributed APK (which is inherent to app distribution) can extract them and reach the cloud storage over the network without authentication or user interaction. The only practical prerequisites are possession of the app package and routine decompilation tooling; there is no non-default configuration or victim interaction gating exploitation. The main limiting factor is the product's small deployment base (a niche consumer dashcam companion app) rather than any technical barrier, and full impact against firmware/binaries assumes the recovered credentials retain write/delete scope on the storage backend. |
| Impact | This is a genuine high-priority finding, not merely a high-CVSS artifact. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC/VI/VA:H and all subsequent-system metrics SC/SI/SA:H, scoring 10.0) is somewhat inflated by the all-High subsequent-system rating, which appears to credit the theoretical downstream compromise of devices that later download tampered firmware. The core defect is real and low-friction, however: hardcoded CWE-798 credentials are static and shared across every installation, so anyone who obtains the freely-distributed APK can decompile it and recover full read/write/delete access to the backend cloud storage - no authentication, no user interaction, no special timing. The integrity impact is the standout concern: because the exposed storage holds firmware and application binaries, an attacker can modify or replace them, creating a supply-chain vector to end-user dashcams. Signal alignment: no EPSS score, no CISA KEV listing, and no public exploit are provided, so there is no evidence of active exploitation - but hardcoded-credential extraction from a public Android package is trivially automatable and requires no vulnerability research, so the low observed exploitation signal reflects the product's niche footprint rather than any technical barrier. Reported by ICS-CERT (ICSA-26-272-07), the same advisory family as the companion Viidure public-read-bucket issue, indicating a broader platform-wide storage misconfiguration pattern. |
| Exploit ScenarioDerived | An attacker downloads the public Viidure Android APK, decompiles it with standard tooling (e.g. jadx/apktool), and extracts the embedded plaintext cloud storage credentials. Using those static credentials over the network, the attacker authenticates directly to the backend object storage and reads, alters, or deletes firmware images and app binaries - enabling data destruction or planting of malicious firmware that devices subsequently pull. No public exploit is identified at time of analysis, but no exploit code is needed beyond routine APK reverse-engineering. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 29, 2026
Unauthenticated extraction of permanent, plaintext cloud storage credentials from the Viidure Android dashcam companion application (CVE-2026-96587) gives any party who obtains the publicly distributed APK full read, write, and delete access to backend object storage holding operational files such as firmware and application binaries. Because the credentials are hardcoded in the shipped artifact and the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, exploitation requires only network reachability to the storage endpoint plus routine decompilation of the app package - no victim interaction, authentication, or non-default configuration is needed. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the practical limiter is the niche install base of this consumer dashcam app rather than any technical barrier; the independent assessment nevertheless flags this as a genuine high-priority finding because the exposure is architectural (server-side credential revocation is the only real containment) and write/delete scope against firmware could enable tampering with the update channel if the recovered keys retain that privilege.
RemediationAI
No vendor-released patch is identified in the available intelligence at time of analysis; the only complete fix is a vendor-side rebuild of the Android application that removes the embedded static credentials and replaces them with per-user, short-lived, least-privilege tokens (for example, scoped STS-style credentials bound to an authenticated user session), distributed as a new APK version in the same channel. Because the secrets are permanent and baked into every shipped copy, the immediate containment is entirely server-side: rotate the exposed cloud storage access keys and revoke the old ones in the storage provider's console, then confirm that firmware and application-binary buckets grant read/write/delete only to signed CI/CD publishing identities and never to client-embedded keys. The trade-off is explicit - rotating or revoking the keys will break cloud connectivity for all existing installs of the app until users update, so the vendor must coordinate key rotation with an app release rather than revoking silently. As interim compensating controls, enable object-storage access logging (for example, S3 server access logs or CloudTrail data events) and alert on unexpected GET/PUT/DELETE of firmware or binary objects from unfamiliar source addresses, and enable object versioning plus delete protection or object lock on the firmware bucket to blunt destructive tampering - noting that versioning costs storage and object lock prevents legitimate overwrite workflows. Separate the storage principals so the credentials recoverable from the app can no longer reach the firmware/application-binary bucket at all, effectively splitting the blast radius even before a rebuilt app ships. End users of the Viidure dashcam app have no practical local workaround since the trust boundary is the vendor's backend; they should monitor viidure.app and the CISA advisory ICSA-26-272-07 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-272-07) for the fixed release and update promptly once it is published.
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-798 (Use of Hard-coded Credentials): the Viidure dashcam Android application ships static, plaintext cloud storage secrets inside the compiled APK, which is itself a public, inspectable artifact. APK files are ZIP archives containing DEX bytecode and resource files, so strings, jadx, dex2jar, apktool, or similar tooling can recover plaintext keys without any special capability or privilege. The CPE cpe:2.3:a:viidure:dashcam_android_application:*:*:*:*:*:*:*:* identifies all versions of the Viidure Android application as affected, meaning the exposure is version-independent and is fixed only by a rebuild that removes or re-scopes the embedded secrets. The reported tags (Authentication Bypass, Google, Dashcam Android Application) are consistent with an app distributed through a mainstream mobile storefront where the APK is inherently downloadable by anyone. Functionally, the credentials open a network-reachable cloud storage backend that hosts operational content - firmware images and application binaries - so the vulnerability is not merely data disclosure but potential integrity compromise of the software supply path feeding deployed dashcams, provided the credentials carry write or delete scope on that bucket (which the advisory's description asserts and the independent assessment accepts as an assumption rather than a measured fact).
Know when Android gets its next vulnerability
- 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:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Static credentials extracted from a public APK give unauthenticated network access (PR:N/AC:L) with full read/modify/delete of stored firmware and binaries (C/I/A:H); scope kept U as the direct target is the storage system itself.
Primary rating from Vendor (icscert).
CVSS VectorVendor: icscert
DescriptionCVE.org
The Viidure Android application embeds permanent, plaintext cloud storage credentials within its compiled code. These credentials provide full access to critical platform storage, including the ability to read, modify, or delete operational files such as firmware and application binaries.
Articles & Coverage 2
Executive ViewAI
CVE-2026-96587 exposes the Viidure Android dashcam companion app through hardcoded cloud storage credentials, allowing an unauthenticated party with the public APK to read, modify, or delete backend files including firmware and application binaries. This creates supply-chain integrity and operational risk for Viidure and its customers, even though the install base is niche. No public exploit identified at time of analysis and No vendor-released patch identified at time of analysis; leadership should prioritize credential containment, storage monitoring, and remediation to prevent tampering or data loss.
No vendor-released patch identified at time of analysis. Interim mitigations include rotating and revoking the hardcoded cloud storage credentials, enforcing least-privilege and authenticated access to the backend object storage, blocking public access, restricting write/delete permissions, enabling access logging and alerting, monitoring for unauthorized changes to firmware and application binaries, and removing affected APK builds from distribution until a fixed version is available.
Threat Intelligence Overview
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.
Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows and OS X and before 11.2.202.466
Integer underflow in the MPEG4Extractor::parseChunk function in MPEG4Extractor.cpp in libstagefright in mediaserver in A
Android 3.0 through 4.1.x on Disney Mobile, eAccess, KDDI, NTT DOCOMO, SoftBank, and other devices does not properly imp
Integer overflow in the SampleTable::setSampleToChunkParams function in SampleTable.cpp in libstagefright in Android bef
Apktool versions 2.9.1 and prior contain a path traversal vulnerability when processing Android APK files. Malicious APK
An elevation of privilege vulnerability in the Android system (art). Rated high severity (CVSS 7.8), this vulnerability
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
Use-after-free vulnerability in Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows
Use-after-free vulnerability in Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows
Android 1.6 Donut through 4.2 Jelly Bean does not properly check cryptographic signatures for applications, which allows
luni/src/main/java/java/io/ObjectInputStream.java in the java.io.ObjectInputStream implementation in Android before 5.0.
The Broadcom Wi-Fi driver in the kernel in Android 4.x before 4.4.4, 5.x before 5.1.1 LMY49G, and 6.x before 2016-02-01
EUVD-2026-89458
GHSA-9g3c-5v4g-qqw9
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB