TWCERT/CC disclosed an IDOR in Family Treasure Cloud 4.5.9 and earlier, CVE-2026-19424. The cloud-side fix is complete, and users do not need to act.
On 2026-08-10, TWCERT/CC publicly disclosed TVN-202607008, indicating that the Family Treasure Cloud developed by Innolux contains CVE-2026-19424, with the vulnerability type being Insecure Direct Object Reference (IDOR). The announcement states that the affected range is versions of Family Treasure Cloud 4.5.9 and earlier, with a risk rating of CVSS 7.5 (High) and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. The announcement also notes that the vendor has completed the vulnerability fix on the cloud service side, and users do not need to take any action.
The core significance of this incident is that it is not merely a configuration oversight, but a typical access control issue: when processing specific parameters, the system failed to properly verify whether the requester had the corresponding access rights to the resource, allowing unauthenticated remote attackers to potentially read other users' sensitive data.
The danger of IDOR usually does not lie in a complex exploitation chain, but in the fact that it often requires only modifying an identifier parameter in the request, such as a resource number, record ID, or another predictable object reference, to cause the system to incorrectly return data that does not belong to that user. The announcement clearly states that attackers can read other users' sensitive data by modifying specific parameters, showing that the problem is centered on insufficient server-side authorization checks rather than the front-end display layer.
From CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, this vulnerability is directly exploitable over the network, has low attack complexity, requires no privileges, and requires no user interaction, with the main impact being on confidentiality. This means attackers do not need to obtain an account first or trick users into clicking anything; as long as they can send crafted requests to the exposed service, they may be able to attempt access to data that should not be visible.
Because the announcement does not disclose further exploitation details, the affected API name, parameter format, or the code root cause, it is not appropriate to infer the specific implementation flaw. From a technical defense perspective, this type of issue usually reflects a failure to enforce object-level authorization, meaning the system does not re-verify whether the object can be accessed based on the current identity, tenant, or authorization scope each time a resource request is processed.
According to the announcement, the affected product is Family Treasure Cloud versions 4.5.9 and earlier. Since the vulnerability is remote and can be triggered without authentication, there is theoretically a risk of probing and abuse as long as the related cloud service still exposes the same interface to the public.
The announcement assigns a High confidentiality score, indicating that successful exploitation may expose other users' sensitive data. Although the announcement does not specify the data type, the description of "sensitive data" is already sufficient to indicate potential impact on personal data, billing information, device information, or other service data.
It is worth noting that the announcement also explicitly states that the patch has been completed on the cloud service side and that users do not need to take any action. This means that the primary responsibility for risk control lies with the service provider rather than with end users updating the software themselves; however, organizations using the service should still confirm whether the service endpoint they actually connect to has switched to the patched version or patched processing logic.
Although the announcement states that the cloud side has already been patched, security management should not stop at the words "fixed." For platforms with external access that involve personal or sensitive data, there should still be a verifiable patch confirmation process, including checks on service-side status, actual access behavior, and authorization logic.
At the same time, IDOR is a common and highly recurrent defect type, and the key defense is backend authorization rather than merely hiding parameters or imposing front-end restrictions. If the service expands with new APIs, new query parameters, or new device integration flows in the future, object-level authorization checks and the principle of least privilege should be incorporated during the design stage.