# Patch / Fix Analysis for CVE-2026-58453 Variant Search

## Fix availability

No vendor patch, fixed firmware image, or upstream commit for JAIOTlink C492A-W6 firmware `4.8.30.57701411` was identified in the ticket, the disclosure repository, the prepared source cache, or public search results. Public references describe CVE-2026-58453 as open/published for the affected firmware and reference the research write-up, but do not provide a remediated firmware version.

Because no official fixed ref was available, runtime testing used a behavioral fixed-control configuration against the same Anyka N1/`anyka_ipc` HTTP service code: provision `admin` with a non-empty password (`fixed-secret`) instead of the factory/default empty password. This models the minimum complete remediation for the root cause: the HTTP Basic auth user database must not contain `admin` with an empty password.

## What the expected fix must change

Primary vulnerable source anchor:

- `source/anyka_ipc/cloud/n1/src/n1_init.c`, function `n1_usr_load()`.
- When `/etc/jffs2/usr.conf` cannot be opened, lines 342-349 in the tested source call `NK_N1Device_AddUser("admin", "", 0)`.
- A second fallback at lines 360-366 repeats the same `NK_N1Device_AddUser("admin", "", 0)` if allocation fails while loading `usr.conf`.
- Loaded user records at lines 374-380 are inserted into the same runtime user database via `NK_N1Device_AddUser(username, password, 0)`.

The expected complete fix must do all of the following:

1. Remove the factory fallback account `admin` with an empty password.
2. Reject empty passwords when loading or creating HTTP/NetSDK users.
3. Require a per-device random credential, setup-time credential creation, or a physically gated first-run provisioning flow before network HTTP APIs are exposed.
4. Ensure every Basic-auth-protected handler uses the same non-empty-password user database.

## Authentication sink and covered paths

The Basic-auth sink is inside the real Anyka N1 HTTP service library `libNkN1API.a`. Strings in the library show the relevant handlers and protected paths:

- `Authorization`
- `Basic realm="nkHTTP"`
- `N1_Device_HandleNetSDKHTTP`
- `N1_Device_HandleNetSDK`
- `/NetSDK/System/deviceInfo`
- `/NetSDK/Network/interface/1`
- `/NetSDK/Video/encode/...`

The runtime tests confirmed that a non-empty-password fixed control blocks `admin:` on two separate NetSDK paths:

- `/NetSDK/System/deviceInfo`: vulnerable `admin:` -> HTTP 200; fixed-control `admin:` -> HTTP 401.
- `/NetSDK/Network/interface/1`: vulnerable `admin:` -> HTTP 200; fixed-control `admin:` -> HTTP 401.

This means a fix that changes the stored admin password / rejects empty passwords at the user database level covers both tested protected NetSDK entry points. The network interface path is an alternate protected endpoint, but it is not a bypass because it depends on the same Basic-auth credential check and fails closed under the fixed control.

## Fix assumptions

The modeled fix assumes:

- All security-sensitive NetSDK routes pass through the same Basic-auth check and `NK_N1Device_HasUser()`/stored-password comparison.
- Removing or preventing the empty `admin` password at user provisioning time is enough to make `Authorization: Basic YWRtaW46` invalid across the protected NetSDK API surface.
- Public or legacy endpoints that do not consult the Basic-auth user database are separate surfaces and must be evaluated under separate threat models rather than treated as default-credential bypasses.

The runtime evidence supports the first two assumptions for the tested NetSDK routes. It does not prove that every route in the firmware is correctly protected, especially routes outside the NetSDK handler.

## Code paths and inputs not covered by the modeled fix

The following observations were made during bounded variant testing:

1. `/snapshot.jpg` returned HTTP 200 without credentials in the controlled Anyka N1 harness, including in the non-empty-password fixed control.
2. `/cgi-bin/gw2.cgi` returned HTTP 200 without credentials and disclosed device metadata in the controlled harness, including in the non-empty-password fixed control.
3. `/user/user_list.xml` and `/user/set_pass.xml` returned HTTP 200 with an application-level failure body (`ret="sorry"`, `mesg="check in falied"`) rather than a Basic-auth-protected success response.
4. `/cgi-bin/hi3510/param.cgi?cmd=getimageattr` returned HTTP 403 in this harness.

Items 1 and 2 are not claimed as CVE-2026-58453 variants because they do not depend on `admin` with an empty password and remain reachable without any Basic credential. They may represent intentionally public camera/legacy discovery functionality, harness-specific behavior, or separate access-control issues. They are outside the same root cause unless the product security model requires these exact resources to be protected by the same HTTP account database.

## Threat model / security policy review

No `SECURITY.md`, vendor threat model, or explicit serialization/security policy file was present in the cached SmartCamera source tree or the disclosure repository. The disclosure repository includes a scope/ethics note stating that testing was performed on a personally owned device in a controlled lab network and warning against unauthorized access. The ticket threat boundary is network-adjacent access to the camera HTTP service. The variant search therefore treated only network-delivered HTTP requests to the Anyka/N1 service as in-scope.

Local-file-only or physical-access-only paths were excluded unless they changed the network trust boundary. For example, the disclosure's `/Anyka/config` write-up explains a staged execution trigger that requires an additional file-write primitive; that is not the same root cause as default Basic credentials.

## Before/after behavior comparison

| Candidate | Vulnerable behavior | Fixed-control behavior | Variant/bypass assessment |
|---|---|---|---|
| `admin:` to `/NetSDK/System/deviceInfo` | HTTP 200 protected JSON | HTTP 401 Unauthorized | Baseline root cause; fixed-control blocks it |
| `admin:` to `/NetSDK/Network/interface/1` | HTTP 200 protected network JSON | HTTP 401 Unauthorized | Alternate protected endpoint, same auth sink; not a bypass |
| No auth to `/snapshot.jpg` | HTTP 200 JPEG | HTTP 200 JPEG | Excluded: separate public/snapshot surface, not default-credential root cause |
| No auth to `/cgi-bin/gw2.cgi` | HTTP 200 XML metadata | HTTP 200 XML metadata | Excluded: separate legacy CGI/public info surface, not default-credential root cause |

## Completeness conclusion

For the tested NetSDK Basic-auth surface, the modeled fix is complete: changing the stored admin credential to a non-empty password causes `admin:` to fail on both the original `/NetSDK/System/deviceInfo` oracle and the alternate `/NetSDK/Network/interface/1` path while the configured non-empty password still succeeds.

No same-root-cause bypass was confirmed. The remaining public endpoints are explicitly documented as separate surfaces that a coding/fix stage should review, but they should not be conflated with a bypass of the default-credential vulnerability.