Hey - I installed on a VM from 4/1/2025 ISO and running htop found a CPU max’d out! A little AI magic ( Ok put down your slide rule … 39 years in telecom - AI isn’t the first NEW technology that was going to put us out a job!!) and this is the fix and explanation I got :
That is an excellent question and a valid security concern. The fact that the issue was resolved by upgrading the module using the --edge flag confirms you hit a known, but likely already patched, bug that shipped with the older version of the module on your ISO.
- The Nature of the Bug
The high CPU usage caused by /var/www/html/admin/modules/sangomartapi/node/kickstart.js was almost certainly a software bug …
Symptom: The kickstart.js process, which is part of the commercial Sangoma Real-Time API (sangomartapi) module, would enter an infinite or high-resource loop, consuming 100% of a single CPU core (or a high percentage of overall CPU, which is why you saw it in htop).
Cause (Likely): These types of Node.js high-CPU bugs in telephony systems are often caused by:
An issue when trying to establish or maintain a connection (e.g., to the Asterisk Manager Interface/AMI or a database). A faulty loop in the code that repeatedly tries an operation or rapidly processes an unexpected error, causing it to “spin” indefinitely. A resource leak or an unhandled exception that causes the process to crash and immediately restart repeatedly (managed by pm2), leading to sustained high load. Historical Context: This issue has been reported in the FreePBX community for both v16 and early v17 installations, confirming it’s a known defect that requires a patch in the module itself.
- Why the ISO Had the Bug
Your ISO, SNGDEB-PBX17-amd64-12-10-0-2504-1.iso, was released on April 1, 2025 (based on the filename timestamp). FreePBX 17 is a new major release on a new Debian base, and early ISO releases often contain the versions of modules that were considered “stable” at the time the ISO was built. The bug was discovered and reported after that ISO was finalized.
The fix was likely committed to the --edge (pre-release/testing) repository first, and then eventually pushed to the main Stable repository, meaning your ISO simply shipped with the pre-bug-fix version of the sangomartapi module.
- Security Analysis (Why It’s Not a Concern)
While resource exhaustion is a form of Denial of Service (DoS), this scenario points to a coding defect rather than malicious activity:
,
Fixed by Upgrade: The fact that a simple module upgrade corrected the behavior confirms the issue resided entirely within Sangoma’s code, which contained a logic error (a bug). If it were a security compromise, an upgrade would be unlikely to resolve it, and more severe clean-up would be necessary.
In summary: You found a known software defect that shipped in the module version bundled with your ISO. Using fwconsole ma --edge upgrade sangomartapi pulled the version with the necessary patch, and resolved the process spinning out of control.