Improper access control in OpenBMB Internet of Agents Message Handler enables unauthorized chat-record access

A vulnerability was found in OpenBMB Internet of Agents up to 9d78e88e47160eb42ee1ee8538c05e1c2c47877a. This issue affects the function fetch_chat_record of the file im_server/app.py of the component Message Handler. The manipulation of the argument comm_id results in improper access controls. The attack may be performed from remote. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.

• The CNA identifies OpenBMB Internet of Agents, component Message Handler, as affected at the specific revision named in the record; the public issue identifies the same revision on the main branch as vulnerable.
• No fixed release, fixed commit, or unaffected parallel branch is confirmed in the record or the reviewed sources.
• Do not treat later revisions as safe without separate verification, because the available evidence does not establish unaffected boundaries for those revisions.

The flaw is in the Message Handler component, in the fetch_chat_record function of im_server/app.py, and is covered by CWE-284 and CWE-266. The user-controlled comm_id argument is used to select chat records without adequately binding the requested data to the caller's authorization. The project's public issue reports that POST /fetch_chat_record accepts comm_id=None and can return the entire chat database without authentication or pagination; a specific session identifier can also be queried without credentials. A remote unauthenticated client may therefore read data outside its authorized scope when the service is network reachable and no additional external access-control layer is present. The authentication mechanism used by each deployment, the storage backend, and whether every deployment exposes the route in the same way remain unconfirmed.

• The flaw is remotely reachable over the network.
• The record and public issue indicate that authentication or privileges are not required, no user interaction is needed, and the described attack has low complexity.
• A public exploit is confirmed; VulDB describes it as proof-of-concept material and provides a download reference.
• The reviewed evidence does not name a specific campaign, victim, or confirmed real-world exploitation activity.

The direct technical outcome is that a remote unauthenticated client may read chat records outside its authorized scope, potentially including another session's data or the entire chat database. This creates confidentiality impact and may break data boundaries between teams or tenants. The record also describes low impact to integrity and availability, but the strongest technical evidence for this CVE concerns unauthorized reading. The evidence does not establish that every deployment is exposed in the same way, because external authentication and deployment-specific exposure have not been confirmed.

The flaw can expose chat records between sessions without authorization, including team discussions, goals, plans, task conclusions, and tool output when those data are stored in chat records. Returning the entire chat database can expand the disclosure beyond one session and affect multiple teams or tenants sharing the service. The directly established consequence is unauthorized data access; the actual data scope depends on stored content and how the deployment exposes the endpoint. The public issue also describes message injection and broadcast amplification in the websocket handler, but this record identifies fetch_chat_record as the affected function, so those related behaviors should not automatically be assigned to the same CVE scope.

1. Apply a vendor or CNA-confirmed fixed revision when one is published. No fixed release or confirmed patch is currently identified.
2. Until a fix is available, enforce authentication and authorization before reading chat records, and bind the caller to the relevant session membership.
3. Reject requests without comm_id, prevent null values from returning all stored data, and paginate chat-record reads. These measures are suggested in the public issue and are not a vendor-confirmed fixed release.
4. If code changes cannot be made immediately, restrict network access to the endpoint to trusted clients and networks as a temporary precaution. This does not replace application-level authorization.
5. Review every parallel branch and deployment before declaring remediation complete, because the status of revisions not covered by the sources remains unknown.

1. Inventory OpenBMB Internet of Agents deployments and identify the running revision for the Message Handler component. Compare that revision with the affected revision identified by the CNA record.
2. Review access logs, reverse-proxy logs, and application telemetry for POST /fetch_chat_record requests with a missing comm_id, a null value, or a session identifier unrelated to the caller.
3. Inspect responses and audit trails for evidence that one request returned the entire chat database or records belonging to another session.
4. Review network configuration to determine whether the endpoint is reachable from the Internet or other untrusted networks.
5. The absence of matching log entries does not prove that the deployment is safe, especially where rejected or unauthenticated requests are not fully logged.