SURIQ
The dangerous line in this advisory is not the one about the camera. It is the one about your Wi-Fi. A flaw disclosed on August 30 in the firmware behind a large family of consumer and small-business internet-protocol cameras lets an unauthenticated attacker read the camera's stored files, and those files include the network's Wi-Fi name and password in the clear. A camera bug that hands over the wireless key stops being a camera bug. It becomes a way onto the network the camera sits on.
The vulnerability is CVE-2026-56718, assigned and published by the research firm VulnCheck. It affects AJCloud AJY internet-protocol camera (IPC) firmware, the software that runs inside cameras built on AJCloud's white-label platform. VulnCheck rates it 8.7 on the version 4.0 CVSS severity scale (7.5 on version 3.1), and credits researcher Alessandro Ciotti with the discovery.
What an attacker can read, and why it matters
The camera runs a small built-in web server called jdbhttpd on port 80. According to VulnCheck's advisory, that service does not properly check the file path in a request, a class of bug tracked as path traversal (CWE-22). By sending a crafted web request with directory-climbing sequences, an attacker who has network access to the camera, with no login and no credentials, can make the server return files from anywhere on the device. The service runs as root, so nothing on the file system is off limits.
VulnCheck lists what those files hold: the camera's streaming credentials (the Real Time Streaming Protocol, or RTSP, username and password) in the clear, the Wi-Fi network name and its pre-shared key, the device serial number, and the parameters that bind the camera to its cloud account. Read together, that is a full set of keys. The RTSP credentials let an attacker pull the live and recorded video. The serial number and cloud binding parameters are the identifiers the platform itself uses to associate a device with an owner's account. And the Wi-Fi pre-shared key is the password to the wireless network the camera is joined to.
Affected firmware is any version before 01.10715.11.37. That build and later contain the fix. VulnCheck's advisory does not report a public exploit or in-the-wild exploitation at the time of writing. Treat that as a snapshot, not reassurance: earlier research on this same web server showed the jdbhttpd version banner is returned in a standard response header, which makes vulnerable devices trivial to find with internet-wide scanning tools once someone decides to look.
This is a pattern, not a one-off
The reason to take a niche-sounding camera firmware seriously is that the same underlying platform keeps surfacing the same kind of problem. AJCloud is a shared white-label base that many camera brands resell under their own names, so one firmware defect can span a long list of products that look unrelated on a store shelf. We saw the same dynamic in a full camera takeover across Dahua-branded devices and in embedded devices left to run without a patch.
In September 2024, Elastic Security Labs published a study of the AJCloud platform that documented unauthenticated device lookups by serial number, peer-to-peer weaknesses, a configuration overwrite that could permanently disable a camera, and a buffer overflow. In July 2026, researchers at Finite State reported, per eSecurity Planet, that a Wansview camera built on the same platform ran the same jdbhttpd server as root and exposed credentials through a directory-traversal flaw catalogued more than twenty years ago as CVE-2002-1819. CVE-2026-56718 is the newest entry in that run: the same web server, the same root privilege, the same file read, now with its own modern identifier and a vendor fix version to track.
The fix exists. Reaching your camera is the hard part.
A patched firmware version being published is not the same as your specific device receiving it. Because AJCloud sits underneath many rebranded products, the update has to travel through whichever brand sold the camera, and past research on this platform noted that attempts to reach the vendor were unsuccessful. Some resellers push firmware promptly. Others are slow, and some cameras are effectively abandoned. The control you actually own is not the vendor's patch pipeline. It is the network the camera lives on and the credentials it holds.
What to do this week
Treat any AJCloud-based camera as a device that may leak its host network's secrets to anyone who can reach its port 80. The priorities, in order:
-
Take the camera off any internet-facing path. It should not be reachable from the public internet on port 80, directly or through a port-forward on the router. If you need remote viewing, do it through the vendor's cloud app or a virtual private network, not an exposed port.
-
Put cameras on an isolated network segment. A separate wireless network or virtual LAN for cameras and other embedded devices means a leaked pre-shared key does not hand over the same network your laptops and servers use. This is the single control that turns a credential leak into a contained event.
-
Update firmware to 01.10715.11.37 or later if your brand offers it. Check the app or vendor support page for the exact model. If no update is available, weight the network controls above more heavily.
-
Rotate the exposed secrets after you contain the device. Change the streaming (RTSP) password, and if the camera has been reachable from untrusted networks, change the Wi-Fi pre-shared key too. The leaked values do not un-leak when you patch.
-
Watch for the tell. On the segment where these cameras live, unauthenticated requests to port 80 that contain directory-climbing sequences in the path are the signature of this read. A camera that suddenly answers web requests from an unexpected source is worth a look.
The broader lesson is the one every operator of cheap connected hardware keeps relearning. A camera is a computer on your network with credentials to your network, and its security is only as good as the least-maintained brand in a white-label supply chain. Assume the firmware will lag, and design the network so a single leaky device cannot become the way in. A leaked credential is how a quiet camera ends up feeding a botnet, and it is the same story as exposed management interfaces handing out password hashes: the device you forgot about is the one that gives an attacker the keys.