Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| n/a | n/a | affected |
|
No data.
| Vendor | Product | Versions |
|---|---|---|
| Reolink | Reolink | — |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.254% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| CPEs | cpe:2.3:a:reolink:reolink:8.18.12:*:*:*:desktop:*:*:* |
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Reolink
Reolink reolink |
|
| Vendors & Products |
Reolink
Reolink reolink |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Reolink desktop application 8.18.12 contains a vulnerability in its local authentication mechanism. The application implements lock screen password logic entirely on the client side using JavaScript within an Electron resource file. Because the password is stored and returned via a modifiable JavaScript property(a.settingsManager.lockScreenPassword), an attacker can patch the return value to bypass authentication. | Reolink desktop application 8.18.12 contains a vulnerability in its local authentication mechanism. The application implements lock screen password logic entirely on the client side using JavaScript within an Electron resource file. Because the password is stored and returned via a modifiable JavaScript property(a.settingsManager.lockScreenPassword), an attacker can patch the return value to bypass authentication. NOTE: this is disputed by the Supplier because the lock-screen bypass would only occur if the local user modified his own instance of the application. |
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-290 | |
| Metrics |
cvssV3_1
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Reolink desktop application 8.18.12 contains a vulnerability in its local authentication mechanism. The application implements lock screen password logic entirely on the client side using JavaScript within an Electron resource file. Because the password is stored and returned via a modifiable JavaScript property(a.settingsManager.lockScreenPassword), an attacker can patch the return value to bypass authentication. | |
| References |
|