Malware Scan uploads full file contents to the cloud...

ta_ihpoj1jophi_at

...with no opt-in – this needs explicit consent (GDPR)

Hi!

While auditing my server (aaPanel 8.0.4, Ubuntu 24.04) I found that the Malware Scan silently transmits the full contents of scanned website files to an aaPanel cloud endpoint, with no toggle, no prompt, and no way to consent or decline. I'd like to raise this as a serious privacy/compliance issue and request a change.

What the code actually does

In class_v2/projectModelV2/safecloudModel.py, the active scanner (class main) hardcodes a cloud engine into its detector list:

self.__detectors = [
    YaraDetector(),   # local
    CloudDetector()   # cloud scan engine
]

scan_file() then runs every detector over each file, and CloudDetector.detect() reads the whole file and POSTs it out:

file_content = self.ReadFile(file_path)
upload_data = {'inputfile': file_content, 'md5': md5_hash}
response = requests.post(self.check_url, upload_data, timeout=20)

So for every file between 1 KB and 10 MB, the entire content is uploaded to a remote URL (fetched from checkWebShell.php). There is no config flag, no if guard, and no consent step gating this — it is unconditional whenever Malware Scan is enabled. (Note: the local YaraDetector is marked in-code as "rule package deleted, pending fix", so in practice detection relies almost entirely on this cloud upload.)

Why this is a legal problem, not just a preference

On a hosting panel, scanned files routinely contain personal data of third parties — customer records, uploads, form data, application code handling PII. A hosting/multi-tenant operator is the data controller for that data. Silently shipping those file contents to aaPanel's servers is a transfer of personal data to a third party, and under the GDPR (General Data Protection Regulation, EU 2016/679) it requires a lawful basis and transparency (Art. 6, Art. 13, and Art. 28 for processor arrangements).

For this kind of processing there is no legitimate-interest shortcut that a controller can rely on silently: the data subjects and the controller have not agreed to it, and it isn't necessary to run the panel. It needs consent, and GDPR consent must be freely given, specific, informed and unambiguous (Art. 4(11), Art. 7).

This must be opt-in, not opt-out

Crucially, opt-out is not sufficient. The CJEU has held (Planet49, C-673/17) that consent requires a clear affirmative act — pre-enabled/pre-ticked defaults do not constitute valid consent. A feature that is on by default and uploads silently cannot be fixed by merely adding an opt-out; it requires explicit opt-in that defaults to OFF.

What I'm asking for

Cloud-based scanning must be strictly opt-in, disabled by default. No file contents leave the server unless the admin has explicitly enabled cloud analysis.
Clear disclosure at the point of opt-in: exactly what is transmitted (full file contents vs. hashes), to which endpoint/region, retention period, and whether/how it's stored.
A fully local scan mode that works without any upload (please also restore/ship the local YARA rules so local detection is actually functional).
Documentation / a DPA for operators who do enable it, to meet Art. 28 processor obligations.

Sending only a hash for cloud lookup, instead of the full file, would also dramatically reduce the exposure and should be the default even after opt-in where possible.

Could a maintainer confirm the current behavior and whether an opt-in gate is planned? Thanks.

aaPanel_Kern

Hello,

Thank you for your feedback
We have asked the developer to confirm that this is a check and not uploaded to the cloud.
You can check the code in detail

ta_ihpoj1jophi_at

Hi Kern,

thank you for taking the time to pass this on to the developer - I appreciate it.

May I ask for one clarification, because I want to make sure I am not
misreading the code myself.

The developer's answer, as you relayed it, is that this "is a check and not
uploaded to the cloud". I would like to reconcile that with these three lines
in class_v2/projectModelV2/safecloudModel.py (CloudDetector.detect):

file_content = self.ReadFile(file_path)
upload_data = {'inputfile': file_content, 'md5': md5_hash}
response = requests.post(self.check_url, upload_data, timeout=20)

As I read it, the full file content is placed in the request body and sent to
a remote endpoint. If that reading is wrong, I would genuinely like to know
where - I am happy to be corrected.

So, concretely:

Is this code path executed when Malware Scan runs? Yes or no?
If yes: does the request body contain the file content, or only the md5?
If it contains the content, on what basis is it described as "not
uploaded"? A transfer that is discarded after evaluation is still a
transfer - under the GDPR the transmission itself is the processing, not
the storage.

I am not trying to score a point here. I run a multi-tenant server and I am
the data controller for my users' files. I need a factual answer I can put in
my processing records - "we asked the developer and it's fine" is unfortunately
not something I can document.

And regarding the link in your reply: it points back to my own first post in
this thread, so I suspect it was meant to be a different one.

Thanks again,

aaPanel_Kern

Hello,

It is recommended that you check if this code is using
Or just wrote it without using it

ta_ihpoj1jophi_at

aaPanel_Kern Hier der Text zum Kopieren:

Hi Kern,

I followed your suggestion and checked whether the code is actually used. It is. Here is what I verified on my own server, aaPanel 8.0.5, file dated 2026-07-30 - so this is the current shipping version, not an old one.

1. The cloud detector is wired into the active scanner, unconditionally.

safecloudModel.py
  973:  class main
  988:      self.__detectors = [
  991:          YaraDetector(),   # comment in your code: rule package deleted, pending fix
  992:          CloudDetector()   # cloud scan engine
  993:      ]
 1180:  def scan_file(self, file_path)
 1200:      is_suspicious, rule = detector.detect(file_path)   # every detector
 1450:      is_suspicious, rule = self.scan_file(file_path)    # scan loop
 2233:      is_suspicious, rule = self.scan_file(file_path)    # second call site

CloudDetector appears exactly twice in the whole file: the class definition and line 992. There is no config flag, no if, no switch anywhere in that path.

2. It has demonstrably run on my machine, not just been "written but unused".

/www/server/panel/data/safeCloud/cloud_config.json   written 2026-07-14 22:48:07
    {"last_check": 1784062087.55, "check_url": "http://w-check.bt.cn/check.php"}

This file is only created by _save_cache(), which is only called after _update_check_url() successfully contacted checkWebShell.php. Its existence is proof that the cloud path executed.

3. Your node still hands out a valid upload target today.

GET https://webshellcheck.aapanel.com/checkWebShell.php
    → {"url": "http://w-check.bt.cn/check.php", "status": true}
GET https://sg1-webshellcheck.aapanel.com/checkWebShell.php
    → {"url": "http://w-check.bt.cn/check.php", "status": true}

Identical to what was cached three weeks ago. If the feature were inactive, status: false from your own node would have been enough to stop it - no code release needed.

4. What is transmitted is the full file, as form data.

POST http://w-check.bt.cn/check.php
Content-Type: application/x-www-form-urlencoded
inputfile=<entire file content>&md5=<md5>

ReadFile() (line 538) opens in text mode and returns fp.read() - the complete file, no truncation. The md5 is sent in addition to, not instead of, the content. The response is reduced to a single value: result['data']['data']['level'] == 5.

So my three original questions are answered by your own code: yes the path executes, yes the body contains the content, and a transfer that is evaluated and discarded is still a transfer.

My new question is a different one.

The panel uses https:// for all nine nodes in NODES_CONFIG - www, api, download, node, wafapi, wafapi2, w-check, webshellcheck, geterror. The client is clearly capable of TLS. But the upload target your node returns is plain http://.

I checked whether that endpoint could accept TLS at all:

157.255.129.252:80    TCP open
157.255.129.252:443   TCP open, but TLS handshake fails
                      SSL alert 112 "unrecognized name", no peer certificate available

So:

Why is customer file content - application source code, and on a multi-tenant host potentially files containing personal data - transmitted over unencrypted HTTP, when every other panel node uses HTTPS?

This is not a detail. Under GDPR Art. 32 a controller must ensure appropriate security of processing, and transmitting third-party personal data in cleartext across the public internet is difficult to defend as appropriate - independently of the consent question in my first post. Anyone on the path can read the content, and the endpoint resolves to a network in Guangdong (China Unicom), which for EU operators also raises Chapter V transfer questions.

Concretely:

Will the returned URL be switched to HTTPS, and by when?
Until then, will you make status: false the default from checkWebShell.php, so no content leaves servers that never opted in?
Is the content stored or logged at the endpoint, and for how long?

I am happy to be corrected on any of the code readings above - every line number is from the file as shipped in 8.0.5, and I can provide the full context on request.

Thanks!

aaPanel_Kern

Hello,

Thank you for your feedback

It is expected that the next version will be fixed and switched to https.
Will set status: false as the default value
It will not be stored on the endpoint, and log requests will be automatically cleaned every day.

ta_ihpoj1jophi_at

aaPanel_Kern Thank you so much for the clear reply. Happy week!