Vulnerability research / CVE

Unauthenticated factory reset in Kiloview E3 video encoders

While doing passive reconnaissance, I found a publicly exposed Kiloview E3 encoder and started looking through how its web interface worked. That led me to an administrative API endpoint that could trigger a factory reset without authentication.

Summary

The affected Kiloview E3 was running software version 1.20.0006. The web application exposed a factory-reset API action that I could call directly without logging in first.

Impact: an unauthenticated remote user could factory reset the device. In the most common case I observed, the device became unreachable afterward. In some cases it remained reachable and accepted the factory-default credentials, which gave administrative access.

How I found it

I started by looking at the login page and the JavaScript loaded by the web interface. The JavaScript showed how the front end was building calls to the device's API under /api/.

Kiloview E3 login interface
The exposed Kiloview E3 login interface that started the investigation.
Retrieving Kiloview E3 application source with curl
Reviewing the page source exposed the JavaScript used by the web application.

From there I went through the API functions and tested how the device handled direct requests outside the normal login flow. One of the functions pointed to systemctrl/system/reFactory, which was the factory-reset action.

Kiloview JavaScript API base path
The front-end code defining the API path.
Kiloview JavaScript factory reset API function
The factory-reset function exposed in the application JavaScript.

Validation

I sent a direct request to the endpoint without an authenticated session. The device returned result: ok and performed the reset, confirming that the action itself was not enforcing authentication.

Successful unauthenticated factory reset API response
The direct API request returned result: ok without an authenticated session.

The important part of the finding was not that the route was undocumented. It was that a destructive administrative function could be executed by an unauthenticated remote user.

What happened after reset

I observed two different outcomes while validating the issue. Most often, the device was no longer reachable after the factory reset, which made the immediate impact a remote denial of service.

On other devices, the encoder remained reachable after the reset and could be accessed with the default credentials. Because that behavior depended on the device's deployment and network state, I treat administrative access as a conditional outcome rather than something that happens every time.

Kiloview E3 administrative interface after factory reset
One observed post-reset state where the device remained reachable and the administrative interface could be accessed with factory-default credentials.

Disclosure timeline

April 6, 2025Vulnerability discovered and validated.
April 7, 2025Reported to the vendor and CVE request submitted.
April 8, 2025Vendor acknowledged the report and began triage.
July 21, 2025Vendor completed a patch.
July 25, 2025I publicly disclosed the technical details after remediation.
November 6, 2025CVE assigned.

What I took from the research

This was the first vulnerability I carried all the way from discovery through vendor disclosure and public CVE publication. The technical part came from slowing down and reading how the application actually worked instead of relying on a scanner to tell me what to test.

It also gave me practical experience with the less technical side of vulnerability research: writing a clear report, staying in contact with a vendor over several months, separating confirmed impact from assumptions, and waiting to publish until the issue was patched.