ASTPP 6.0 sends data about all your customers to the vendor every day (dcoll.inextrix.com)

Feature Idea Discussion
1

While reviewing ASTPP 6.0 Community Edition before putting it into production, we found code that collects personal data of all active accounts plus details about the server, and sends them once a day to a server of the vendor. We found no mention of this in the repository’s documentation or in the installation guide, and the admin interface has no setting for it.

Everything below refers to the official repository, branch V6.0, commit d5108ec (26 June 2026), which is still the latest commit of that branch. All links point to that exact commit, so you can check every statement yourself.

What is collected

get_dashboard_details() in common_model.php builds the payload:

  • For every active account (customers, resellers, providers and the admin account): account number, account type, first and last name, e-mail address (or notification e-mail), company, phone number, country and currency.
  • Business figures: number of active accounts, DIDs and packages, number of calls and billed seconds of the previous day, names of installed add-ons.
  • Operator contact: the e-mail address from the company profile.
  • Server: the public IP address, queried with curl ``ifconfig.me, and the output of free -m, nproc, hostnamectl (host name, machine ID, operating system, kernel, hardware) and lsblk.
  • FreeSWITCH: the output of fs_cli -x status. The event socket password is passed on the command line with -p (L236), so it shows up in the process list while the command runs.

Because the loop variable is reused, the top-level fields of the payload also repeat the data of the last account in the list.

How and when it is sent

  1. common_model is autoloaded, so its constructor runs on every request to the web interface: every page and every AJAX call, including the login page, with or without login.
  2. The constructor (common_model.php L35) calls $this->uri->uri(...) with the result of get_dashboard_details(). The shell commands above, including the request to ifconfig.me, therefore run on every single request.
  3. uri() is not ASTPP application code. It sits in the CodeIgniter framework core class CI_URI (system/core/URI.php L315-L336). If the stored date datacoll is older than today and enable_data is 0, it sends the payload as an HTTP POST to the URL from config.php.
  4. That URL is stored base64-encoded in config.php L242 and decodes to https://dcoll.inextrix.com. enable_data = 0 on the next line means sending is on.
  5. Right after that, get_currencylist() sets datacoll to today’s date (common_model.php L85-L87). The result is one transmission per day, triggered by the first request of the day (UTC).
  6. The datacoll setting is created with is_display = 1 (astpp-6.0.sql L2134), while the configuration pages only list settings with is_display = 0 (system_model.php L329-L333). It never appears in the admin interface.
  7. The setting is added by upgrade_v4_to_v5_community.sql L1130, which suggests that the mechanism goes back to version 5. We only reviewed 6.0.

Two more places that send data to the vendor

  • Feedback endpoint without login: /feedback/customer_feedback_result/TRUE (feedback.php L33-L127) sends the operator’s company profile (company name, address, phone, fax, e-mail, website, server name) to http://feedback.astppbilling.org/feedback.php, unencrypted over plain HTTP. The controller has no login check, so anyone on the internet can trigger it. It is also listed as cron task “FeedBack” in config/cron.php L23, but not scheduled by default. The regular feedback form sends the admin’s contact details together with the feedback text the same way, also unencrypted.
  • Installer: install.sh from ASTPP_Community_edition_v6.zip (lines 388-399) asks “Enter your email address” without saying what it is used for. It then fetches the server’s location data from ip-api.com (public IP, city, provider) and sends both to https://astppbilling.org/lib/.

Why this matters

As an ASTPP operator you are responsible for your customers’ personal data. This transfer to a third party happens without notice, consent or a data processing agreement. For operators in the EU or Switzerland that is hard to reconcile with the GDPR or the Swiss FADP. Please check with your data protection officer whether you need to act, for example because data of your customers may already have been transferred. We are not lawyers, and this is not legal advice.

It also costs performance: six or more extra processes and an outgoing HTTP request to ifconfig.me on every page view and every AJAX call.

How to switch it off

  1. Stop the daily upload: in web_interface/astpp/application/config/config.php set $config['enable_data'] = 1;. The collection itself, including the shell commands and the request to ifconfig.me, keeps running on every request.
  2. Stop the collection completely: remove the line that calls $this->uri->uri(...) from the constructor in web_interface/astpp/application/models/common_model.php (line 35). get_dashboard_details() is not used anywhere else.
  3. Close the feedback endpoint: block /feedback/ in your web server, or remove the controller.
  4. Block the destinations: additionally block outgoing connections to dcoll.inextrix.com and feedback.astppbilling.org in your firewall or DNS.

Setting datacoll to a date in the future does not help: ASTPP overwrites it with today’s date on every request.

You cannot find out afterwards whether or when data was sent. There is no log, and datacoll is rewritten on every request. If your web interface was used on a given day, assume that the data was transmitted that day. Outbound firewall logs, if you have them, are the only reliable source.

Vendor

We tried to report this to iNextrix on 09.10.2026. The security address named in the installation guide, security@astppbilling.org, does not accept mail, so we have contacted them via contact@inextrix.com instead. It would be good to hear from them what the data is used for, where and for how long it is stored, and how operators can have it deleted.

2

You may want to post this elsewhere. They tend to delete posts such as this

@sman123 You see this?

3

Well thats not good. :upside_down_face:

4

Let’s see how they handle this. A clear and transparent statement would definitely be appreciated. Simply deleting the data without addressing the issue probably isn’t the best approach…

5

Posted here for discussion and mitigation if the post disappears. Beware of ASTPP 6.0 Community Edition (Inextrix). | FusionPBX Forums

6

Dear ScITGmbH, and everyone following this,

Thank you for the detailed and responsible write-up. You put real work into this, and we are taking it seriously.

First, an apology. ASTPP 6.0 includes a data-collection mechanism, introduced around version 5, that was meant to help us understand how the platform and its modules are used across deployments so we could prioritise development. That intent does not excuse how it was implemented.

Having reviewed the code, we agree with the core of your findings:

  • It collected more than it ever should have for that purpose, including personal data fields that were not necessary.
  • It was not surfaced in the admin interface, so operators had no visibility or control over it. That was wrong.
  • The security contact address in our documentation was not functioning. We are fixing that now so disclosures reach us properly.

Here is what we are doing:

  • Removing the unnecessary data collection entirely, including the personal-data fields, from the codebase.
  • Bringing the remaining, non-personal usage analytics to the front of the admin interface.
  • Pushing these changes to the public GitHub repository next week so anyone can verify exactly what was removed and what remains.

We are treating the security items raised in the related thread with the same priority and will report back there as well.

Thank you again for raising it properly.

Samir Doshi

7

Thanks for the detailed statement, I received your e-mail aswell and will reply, as soon as I’m back in office.

8

security@astppbilling.org email issue has been resolved now.

9

Update: data collection removed from the code

Following up on my earlier post. The change is now in the public repository.

We have removed the usage data collection and the feedback module from ASTPP 6.0 Community Edition. Specifically:

  • The daily transfer of account and server data to our endpoint is gone.
  • The data collection code itself (get_dashboard_details) has been removed, not just disabled.
  • The datacoll setting and the enable_data option are removed.
  • The feedback module and its endpoint are removed.

After this change, the application does not collect or transmit account or personal data.

The commit is here: [IMP] Remove dcoll usage data collection and feedback module · inextrix/ASTPP@9479778 · GitHub

One related part is handled separately. The installation script also asked for an email address and collected server information. We are adding an explicit consent step to the installer and removing the silent transfer. The updated installer will be available tomorrow.

Thank you to infrahost and Raphael Schneeberger @ScITGmbH for raising this clearly and responsibly. We are continuing to work through the rest of the items and will keep the community updated.

10

Update: installer now asks for consent

The updated installation script is now available.

It no longer sends any information without your explicit consent. During installation it asks first, the default is no, and if you decline, nothing is sent.

Together with the earlier code change, the data collection is fully removed from the application and the installer.

Thanks again to infrahost and Raphael Schneeberger @ScITGmbH. We are continuing to work through the remaining items.

11

We have published a full advisory on this, including what was involved, what we changed, and how to verify it in the source: https://astppbilling.org/security/community-edition-data-collection