3,394 titles for a CRM that has no fingerprint: counting erxes, and the 9.8 that outlived its patch
erxes is an open-source experience operating system — a CRM with a plugin architecture — and it returns 3,394 title matches against 52 application fingerprints on 27 October 2026. That ratio of roughly sixty-five to one puts it in the same family as other white-labelled business applications in this collection, and the reason to care about the population is a set of 2024 records that include a 9.8 authentication bypass.
The measurement
ZoomEye, sub_type=all, one page per query, totals only, no host records retrieved:
| Query | Total |
|---|---|
| title:"erxes" | 3,394 |
| app:"erxes" | 52 |
The word itself is a lower-case brand term rather than an English word, which suppresses false positives in the title query without eliminating them: mirrors of the project README, agency portfolio pages and comparison articles all use it.
What the records say, and why the age matters
Three records from the SonarSource audit of the project were published in June 2025 against erxes versions below 1.6.2, and they describe a consistent problem in a microservice architecture.
-
CVE-2024-57190 (9.8) — incorrect access control; an attacker can bypass authentication by sending a
UserHTTP header containing any user identity and then talk to any GraphQL endpoint. -
CVE-2024-57186 (5.4) — an unauthenticated path traversal in the
/read-fileendpoint handler, allowing arbitrary file reads. -
CVE-2024-57189 (5.4) — an authenticated path traversal in the
importHistoriesCreateGraphQL mutation, allowing arbitrary file writes. Read together they describe the failure mode of a service mesh built from separately deployed components: each service trusts a header because a gateway was supposed to set it, and a service that is reachable directly believes whatever the header says. The 9.8 is the direct consequence; the two traversal records are what an attacker does once they are inside. The dates are the part that matters for an exposure count. These were published in mid-2025 and they describe fixes in 1.6.1 and 1.6.2. An erxes deployment discovered on the internet in late 2026 is only interesting if its version is on the wrong side of that boundary, which means the exposure number needs a version dimension it does not have.
What an exposed CRM holds
A CRM is a record of relationships: contact details, communication history, deal values, sometimes contracts and identity documents attached to a customer record. In erxes the plugin model adds a second layer, because each plugin has its own data and its own routes.
Three consequences for anyone with an instance on a public address.
The header-trust failure is architectural, not a single route. If the fix for CVE-2024-57190 was applied service by service, an internal component that was missed is still trusting a caller-supplied identity. Version numbers on the front end do not answer this.
File read and file write are different severities in a CRM. A read traversal exposes attachments and configuration. A write traversal, which CVE-2024-57189 describes, allows planting content that another service will later execute or serve.
Plugin surfaces age independently. A CRM whose core is patched can still run a plugin built against an older core, and the plugin's routes may not have received the same authorization review.
Checks the numbers support
- Enumerate your own instances by route, not by title. Probe for the GraphQL endpoint and the plugin routes you know are enabled. A deployment behind a vanity domain will never appear in a title count.
-
Test the header-trust assumption directly. From a host inside the network but outside the gateway, call a GraphQL endpoint with a forged
Userheader. A response that reflects the forged identity is the finding, and it is exactly the CVE-2024-57190 pattern. - Version every service, not just the front end. The fixed versions are 1.6.1 and 1.6.2. A gateway on 1.6.2 fronting a service on 1.5 is not patched.
- Audit file endpoints for path handling. Both traversal records live in file handling. A review of every route that takes a path or writes an import is proportionate.
- Inventory plugins separately. Each plugin is a deployment with its own release cycle, and it belongs in the asset register as its own entry.
Reporting the count
The sentence that survives review: 3,394 indexed pages carry the erxes name in their title, 52 hosts are positively identified by fingerprint, and the number of running instances lies between those observations. What that number cannot tell you is the version, which is the only variable that decides whether the mid-2025 records apply. Exposure counting for a business application is a discovery step; the version check is the decision.
Limits
Both totals are single-day index observations from one provider. The composition of the 3,394 is inferred rather than sampled. No erxes host was inspected, no GraphQL endpoint was tested for this article, and no exploitation in the wild is asserted. CVE identifiers, scores and version boundaries are quoted from their NVD records; the architectural explanation of the header-trust issue follows the audit description and is presented as an interpretation, not a reproduction.
References
- erxes repository: https://github.com/erxes/erxes
- NVD record for CVE-2024-57190: https://nvd.nist.gov/vuln/detail/CVE-2024-57190
- NVD record for CVE-2024-57186: https://nvd.nist.gov/vuln/detail/CVE-2024-57186
- NVD record for CVE-2024-57189: https://nvd.nist.gov/vuln/detail/CVE-2024-57189
- SonarSource audit write-up referenced by the records: https://www.sonarsource.com/blog/micro-services-major-headaches-detecting-vulnerabilities-in-erxes-microservices/
- ZoomEye search syntax reference: https://www.zoomeye.org/doc
Top comments (0)