CVE-2024-2007 is a medium severity (CVSS 5.3) sandbox escape in privileged mode flaw in OpenBMB XAgent 1.0.0. The weakness sits in the Privileged Mode component. The record lists no fixed version, so check with the vendor, restrict access to the product and plan a replacement if no patch ships.
What's affected
NVD lists OpenBMB XAgent 1.0.0 as affected. The record names no fixed version, and the references are third party write ups rather than a vendor advisory. If you run this product, contact the vendor or check its project page for a patched release before relying on any version number you read here.
NVD scores this 5.3 (Medium) with vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L. The linked GitHub issue is titled "Docker Enabling Privileged Mode Causes Container Escapes". VulDB calls it critical, while NVD scores it 5.3 (Medium) with a local attack vector. The description says the exploit has been disclosed to the public, so assume that details are available to anyone who looks.
How to check if you're exposed
OpenBMB XAgent is a stand-alone application, so there is no registry package to query. Look in your asset inventory, deployment records or hosting panel for it, and read the installed version from the application itself or its install directory. Anything at the version named above is in scope.
The affected code is reached through the Privileged Mode component. If that path is reachable from the internet or from a wide internal network, treat the exposure as higher. Your web server and application logs for requests to that path are a reasonable place to look for unusual activity, though a clean log does not prove the path was never used.
What to do now
- Find every instance of OpenBMB XAgent you operate, including test and forgotten copies.
- Ask the vendor or check the project page for a fixed release, and apply it as soon as one exists.
- Review the related application logs, and the database or upload directory contents if relevant, for signs that the weak path was used before you changed anything.
- If no fix exists and you cannot retire the product, restrict network access to it with a firewall or reverse proxy allow list and monitor it closely.
- Add the product to your vulnerability tracking so a later fix or advisory is not missed.
Why it matters
NVD tags this as CWE-265. Running a container in privileged mode removes most of the isolation that makes a container a useful boundary. Code inside it can reach host devices and, in many setups, break out to the host itself.
The usual advice is to avoid privileged mode, drop capabilities you do not need and run untrusted code in a separate unprivileged environment.
Products in this category tend to be small, single maintainer or niche vendor applications. Many never receive a patch, and the NVD note on several of these records says the vendor did not respond to disclosure. That does not make the finding less real. It means the practical controls are network restriction, a web application firewall rule, monitoring and, over time, replacement. The record's KEV flag is false and no source here reports exploitation in the wild beyond the public disclosure. You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected component. Safeguard reachability analysis can then help you separate code paths that actually call the weak component from those that only list it.
Quick check
Is there a fixed version of OpenBMB XAgent?
Not in the NVD record. Check the vendor or project page, and treat the product as unpatched until you confirm otherwise.
Why does this matter if the score is medium?
The score reflects the technical impact and conditions in the NVD vector. Public disclosure and low attack complexity raise the chance that someone tries it against an exposed instance.
Sources
Last reviewed: 19 October 2026.
