Intelbras Camera Flaw Enables Unauthenticated Denial of Service

Security cameras are often treated as low-maintenance appliances, but their availability can be as important as the confidentiality of the video they capture. A camera that silently drops offline can create a gap in physical-security monitoring, disrupt remote verification, and leave administrators uncertain about whether a device is malfunctioning or under attack.

Research from Securelist, Kaspersky’s security research publication, identified a denial-of-service vulnerability in an update endpoint used by certain Intelbras IP cameras. The issue did not require a valid account or a valid firmware image. A request to the endpoint could cause an affected camera to begin its reboot process and become unavailable. Repeated requests could keep the device offline, according to the researchers.

Intelbras addressed the problem after responsible disclosure. The company released firmware version R.260804, together with update instructions, and Securelist reported that the corrected firmware requires authentication before an update can be initiated. Organizations operating affected cameras should treat firmware verification as a priority, particularly where devices are used for access control, production monitoring, retail operations, or other time-sensitive surveillance.

What Securelist confirmed

Securelist’s analysis focused on an Intelbras iM3B-C camera, also identified in the research as the IM3 C. Intelbras told the researchers that the same firmware was compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. The researchers examined firmware version v240927, which was the latest available to them at the time of their work.

The vulnerable component was the firmware-update route:

http://<ip_address>/firmwareUpgrade_service/Demo

The route was accessible without authentication. Securelist also found that it did not verify whether the submitted firmware was valid before starting the update routine. Because the routine caused the camera to reboot, an attacker able to reach the device could trigger a service interruption without completing a legitimate firmware installation.

The source describes the prerequisite as access to the camera’s local Wi-Fi network. That means the research demonstrates a local-network attack condition rather than an unrestricted internet attack against every camera. However, the practical exposure depends on how each device is deployed. A camera reachable from an untrusted wireless segment, a poorly isolated office network, or an externally exposed management path would face greater risk than one restricted to a dedicated, access-controlled network.

How the failure produces an outage

The camera’s firmware contains an ARM binary named sonia, which Securelist described as handling functions including hardware-related kernel drivers, authentication, livestream recording, and other device operations. The researchers traced the firmware-update endpoint to the update process managed by this component.

Under normal operation, the camera supports firmware updates through its web interface and mobile application, as well as manual installation from an SD card. The affected network endpoint was intended to support the update workflow, but its implementation omitted a required authorization check. The result was a mismatch between the sensitivity of the operation and the controls protecting it.

Securelist’s demonstration showed that an HTTP POST request directed to the endpoint was enough to initiate the reboot process. The submitted image did not need to be an authentic firmware package. Once the request was accepted, the camera restarted and disappeared from the Intelbras application and from the perspective of users attempting to view the feed.

A single request interrupted availability for approximately one minute, according to the research. Periodic requests could extend the disruption indefinitely. This is a denial-of-service condition: the flaw does not, based on the supplied research, provide evidence of video theft, privilege escalation, persistent malware installation, or arbitrary code execution. Its direct security consequence is loss of camera availability.

Why the authentication design matters

Securelist included a review of the camera’s login process to explain how other protected endpoints are intended to work. The global.login RPC method at /RPC2_Login uses a challenge-and-response sequence. The client first supplies a username with an empty password, receives challenge values and a temporary session, and then calculates a response based on the username, realm, random value, and password-derived hashes. A successful second request produces an authenticated session for later RPC calls.

The researchers’ key finding was that the firmware-update route did not enforce the same session validation. In the remediated firmware, Securelist observed checks for cookies and session data before the update operation proceeds. The comparison illustrates the central defect: authentication existed elsewhere in the platform, but the endpoint capable of rebooting the camera failed to require it.

This is an important operational lesson for administrators and device manufacturers alike. Protecting a login page is not enough if sensitive functions remain reachable through separate routes without equivalent authorization controls. Update, reboot, reset, diagnostic, and configuration interfaces should be treated as privileged management operations.

Scope, exposure, and attribution

Securelist assessed that the potential user impact could be substantial. The Intelbras Mibo Smart application had more than four million downloads at the time described in the report, and Brazil was identified as the largest user base, followed by several other Latin American countries. Those figures indicate the scale of the product ecosystem, not a confirmed count of vulnerable cameras or confirmed victims.

The research does not identify a threat group, campaign, victim organization, or confirmed exploitation in the wild. It also does not establish that all cameras associated with the application were affected. The confirmed scope is tied to the models and firmware relationships described above, with the precise deployment population dependent on device model, installed firmware, and network reachability.

MITRE assigned the candidate identifier CAN-2026-2035970, pending final CVE assignment. Securelist reported that Intelbras informed the researchers of a Medium classification with a CVSS 4.0 score of 5.1. The identifier should not be treated as a finalized CVE unless and until the record is updated.

Detection and threat hunting

Organizations should begin with asset inventory rather than assume that every Intelbras camera is affected. Record the model, installed firmware version, network segment, management interfaces, and business purpose for each device. Compare those records with Intelbras’ current firmware guidance and the update instructions associated with release R.260804.

Network defenders can also review telemetry for unexpected requests to the firmware-update path, especially HTTP POST activity targeting /firmwareUpgrade_service/Demo. A request alone does not prove exploitation, and the supplied research does not provide a complete set of logging indicators or detection rules. Nevertheless, such activity merits investigation when it originates from an untrusted host or appears repeatedly in close proximity to camera reboots.

Correlate camera availability alerts with wireless-controller, switch, firewall, and application logs. Repeated transitions from online to offline status, unexplained reboots, and simultaneous interruptions across multiple cameras may help distinguish an isolated hardware problem from deliberate service disruption. Preserve relevant logs before reboot cycles or retention limits remove useful context.

Because the vulnerability is an availability issue, monitoring should include operational status rather than only authentication events. Confirm that cameras expected to be online remain reachable and that their feeds are available to authorized operators. For important sites, establish an escalation process for unplanned camera outages and document how guards or facilities teams should respond when video coverage is interrupted.

What organizations should do now

• Identify affected equipment. Check whether deployments include the iM3B-C, iMX C, iM4 C, iM5 SC, iME 360 C, or iM7+ FC models referenced by Securelist, and verify the firmware installed on each unit.
• Apply the vendor’s corrected firmware. Update to R.260804 or a later Intelbras release that addresses the issue, following Intelbras’ published instructions. Confirm the resulting version after installation.
• Restrict management access. Place cameras on dedicated network segments and limit access to trusted administration systems. Do not expose camera management services directly to the public internet unless a documented business requirement and strong compensating controls exist.
• Review wireless design. Ensure untrusted, guest, and general-purpose wireless users cannot reach camera management interfaces. Segmentation should reduce the number of systems capable of contacting device administration endpoints.
• Monitor availability and update activity. Alert on unexpected camera reboots, repeated offline events, and requests to the affected update route. Treat unexplained interruptions as potential security incidents as well as maintenance issues.
• Coordinate with the vendor or reseller. If a model or firmware version is unclear, obtain confirmation from Intelbras or the authorized supplier before assuming that a device is outside the affected scope.
• Maintain operational fallback procedures. For sites that depend on continuous surveillance, define temporary coverage and incident-response steps for camera outages while remediation is underway.

These measures are general defensive recommendations derived from the confirmed behavior and from standard IoT security practice. They do not replace Intelbras’ firmware guidance, and the supplied research does not establish that segmentation or monitoring alone eliminates the vulnerability.

Conclusion

The Intelbras issue shows how a narrowly scoped implementation error can have a direct physical-security impact. An unauthenticated firmware-update endpoint allowed reachable cameras to be forced into a reboot cycle without a valid firmware image, creating a practical denial-of-service condition. Securelist reported that Intelbras corrected the flaw by requiring authentication in firmware R.260804.

There is no confirmed victim list, threat-actor attribution, or evidence in the supplied research of exploitation outside the researchers’ demonstration. The most defensible response is therefore straightforward: inventory the affected camera models, verify firmware, install the vendor’s fix, limit network reachability, and monitor camera availability as a security-relevant service.

Sources

Securelist: “Millions of security cameras at risk: DoS vulnerability in Intelbras devices”