The vulnerability in CVE-2026-44102 is being framed as an improper locking issue during firmware cleanup, but that description obscures the actual architectural flaw. The real problem is that the OCPP implementation delegates firmware integrity validation entirely to the backend—the charger receives a URI and initiates a download without any local validation of what it's fetching or where it's coming from. This creates a gap where neither the OCPP interface nor the local system validates the firmware before initiating what can become an insecure file operation.
When the backend provides a URI and the device fetches the file, that fetch occurs over a channel that may have different security properties than the OCPP message channel itself. If the firmware download uses plaintext HTTP rather than authenticated TLS, an attacker positioned on the network can inject arbitrary content into the download stream. The 'invalid firmware' detail is critical: the system doesn't validate the file before downloading, and it doesn't validate it during the brief window before cleanup. The improper locking during cleanup is a symptom of this deeper failure—the system was never designed with a coherent model for when and where firmware validation should occur.
For defenders, the priority questions are: (1) What is the actual time window between download completion and cleanup deletion? If it's measurable, this becomes a reliable staging point for exploitation. (2) Does the firmware download occur over plaintext HTTP or authenticated TLS? OCPP supports both, and the transport security of the firmware fetch is separate from OCPP message security. (3) Is the firmware file world-readable during the cleanup window, or is filesystem-level isolation in place?
The CVSS 5.3 score undersells the risk. An attacker who can stage arbitrary content in a world-readable location on a device controlling high-current charging infrastructure has a staging ground for further exploitation that may not be captured in the CVSS calculation. If the unpatched firmware lacks rollback protection or secure boot chain integrity, poisoning the download location before the device boots from it may not require exploiting locking at all—the attacker needs only to ensure their payload is in place when the device next accesses it.
The patch likely addresses locking mechanics rather than changing the validation model. This hardens the specific exploit path but may not close the underlying architectural gap. If the firmware fetch still occurs over an unprotected channel and local validation still doesn't occur before download, the system has been hardened without addressing the root design assumption that validation is a backend concern. Evaluate whether your deployment uses authenticated TLS for firmware fetches, and whether the patched version implements local validation or merely improved synchronization around cleanup.