...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 ] if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 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) if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 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.

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

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

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!

ta_ihpoj1jophi_at

aaPanel_Kern Hi Kern,

8.0.6 is out and I upgraded this morning, so here is the follow-up on the two
commitments from your last reply. I checked both on my own server. Neither has
landed yet, and I want to document that accurately rather than assume.

Panel: aaPanel 8.0.6, Ubuntu 24.04.
File checked: /www/server/panel/class_v2/projectModelV2/safecloudModel.py,
mtime 2026-08-26 10:46:33, 198782 bytes, 4622 lines — i.e. the copy that
8.0.6 just installed, not a leftover from 8.0.5.

1. "It is expected that the next version will be fixed and switched to https."

Not done. Both nodes still hand out a plain-HTTP 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}

Byte-identical to what I reported three weeks ago on 8.0.5.

2. "Will set status: false as the default value."

Not done either — both nodes above still return status: true. This one does
not even need a code release; it is a value your own node returns. As long as
it is true, _update_check_url() (line 418) accepts the URL, caches it for
cache_ttl = 86400 (line 380) and the upload path proceeds.

3. The code path itself is unchanged in 8.0.6.

 991:            YaraDetector(),  # comment unchanged: rule package deleted, pending fix
 992:            CloudDetector()  # cloud scan engine

CloudDetector is still wired into the active scanner unconditionally — no
config flag, no if, no consent gate anywhere in that path. And the request
body is still the whole file, not a hash:

 504:                    'inputfile': file_content,
 505:                    'md5': md5_hash
 507:                response = requests.post(self.check_url, upload_data, timeout=20)

4. There is still no way for an admin to turn this off in the UI.

Security -> Overview -> Malware Detection -> Advanced Settings offers exactly
four things: Monitor Directory, Exclude Directory, Ignore File, and a
"Quarantine Files" toggle. There is no on/off switch for the scan, and none for
cloud analysis. The panel states in that same dialog: "Malicious file detection
runs automatically every 6 hours [...] without any manual operation!"

The only lever an operator has is to delete the monitored directories (/www,
/web/wwwroot) so the scanner has nothing left to read. That is a workaround,
not a consent mechanism.

Where that leaves operators

For an EU operator this is unchanged from my first post: third-party personal
data leaves the server in cleartext, over plain HTTP, to an endpoint in a third
country, with no lawful basis obtained from anyone and no way to decline
without disabling monitoring entirely. GDPR Art. 6, Art. 13, Art. 32 and
Chapter V all still apply.

I am not posting this to press the point. You gave me three clear answers and I
asked for them precisely so I could put them in my processing records — which
means when the state on disk does not match them, I have to record that too.

So, concretely:

Is the HTTPS switch scheduled for a specific release, or is it still open?
status: false requires no release at all. Can it be set now?
Is an explicit opt-in gate (default OFF) planned, or is the directory-
deletion workaround the intended answer for operators who cannot consent on
their users' behalf?

Every line number above is from the file as shipped in 8.0.6 and I am happy to
provide full context or be corrected on any reading.

Thanks,
Jo

aaP_aapanel277

ta_ihpoj1jophi_at,

I wanted to reply the 1st post you made but i've waited to see where this is going. I started doing the exact same thing, looking trough the files and analyzing the code but you were a step ahead. Since i saw your 1st post i turned the server off. I went ahead to change all passwords, settings etc. just to make sure since files are uploaded on a 3rd party without consent. In my opinion this is malicious behaviour (Spyware) Also i saw a bunch of encrypted files which now even more makes me wonder what exactly is in that code. So thanks for the good work! You can also send me a DM to talk if you like...

As for aapanel,
I demand a full explanation on how exactly (technically) the files are processed and what exactly happens to them on the 3rd party server, whos has access to these files etc. Yes you mentioned a few things in the converstion above but i want an official statement. I never gave any explicit consent nor i could find any paper stating this behaviour.

Since you are in breach of GDPR:

Immediatly push and update and fix the code. Add option to implicit consent not default implicit accept and the options to turn on/off this behaviour where is clearly stated what exactly happends when enableling that option.
Accept point 1 or refund my payment. I'm not interested to continue further using aapanel.
I'll be forced to take this to my layers and process this to court since this is a GDPR breach.

Now of course am not interested in courts, layers and all that time spending.
So option 1/2 will do.

Depending on your answer the next steps will be decided.
If anyone else feels the same contact me.

ta_ihpoj1jophi_at

One more finding from 8.0.6, and this one is about the opt-out rather than the
upload. I am reporting it as a defect, not as an accusation - from the code it
looks like something that was left half-finished.

There is a switch, it is stored, and it has no effect.

safecloudModel.py reads dynamic_detection in seven places. Six of them
store it, validate it, or report it back to the UI:

 768   'dynamic_detection': True,                                    # default
1852   'dynamic_detection': self.__config.config.get('dynamic_detection', True)
1885   'dynamic_detection': { …                                      # validator
1888   'error_msg': "dynamic_detection parameter must 'true' or 'false'"
1972   if key not in ['quarantine', 'dynamic_detection', 'scan_oss']:
3053   status['file_detection'] = bool(config.get('dynamic_detection'))

The seventh is the only one that would act on it — and it is commented out, in
webshell_detection(), the scan entry point:

# todo  去掉开关 改为手动扫描
# if not self.__config.config.get('dynamic_detection', True):
#     return public.returnMsg(True, 'The dynamic killing function has been turned off, skipping detection')

So the setting is accepted, persisted and displayed, but nothing reads it where
it would stop a scan.

This is the shipped state, not a local problem. I compared the file on my
server with the one in your public repository:

3dabfd1b2e602691bdc9998c203b065c  /www/server/panel/class_v2/projectModelV2/safecloudModel.py
3dabfd1b2e602691bdc9998c203b065c  class_v2/projectModelV2/safecloudModel.py  (github.com/aapanel/aapanel)

Identical. Line 1480 is commented out in the repository too.

What that meant in practice on my server, from your own request log
(/www/server/panel/logs/request/):

2026-07-15 00:32:18  POST /v2/safecloud?action=set_config  {'dynamic_detection': 'false'}  → 200

I turned it off on 15 July. data/safeCloud/config.json still records
"dynamic_detection": false today. And the panel reports:

Last scan time: 2026-08-07 21:29:45   —   34,940 files scanned

A scan ran three weeks after the feature was switched off. I am not claiming
anyone intended that; the todo comment right above the disabled line
("remove the switch, change to manual scan") reads like work that was started
and not finished. But the effect is that a refusal recorded in the panel does
not reach the code that would honour it.

A second, smaller thing in the same function. The task-frequency guard
carries four different numbers:

if (current_time - last_detection_time) < 50:   # 5小时60*60*5
    return public.return_message(0, 0, 'Less than 12 hours have passed since the last scan, skip this scan')

The code compares 50 seconds, the comment says 5 hours, the message says 12
hours, and the UI text says "runs automatically every 6 hours". Whichever was
meant, three of the four are wrong, and the one that executes is the shortest.

My questions:

Is the commented-out check at line 1480 intended to return, or is the switch
meant to disappear from the UI? Right now it is neither — it is visible in
the config API and inert in the scanner.
Until it is decided: is there any supported way for an administrator to stop
the cloud submission, other than deleting /www and /web/wwwroot from the
monitored directories?
Should the < 50 be < 50 * 60 * 60 * 5 or similar? At 50 seconds the
guard effectively does not limit anything.

As before, every line number is from 8.0.6 as shipped, and I am happy to be
corrected on any reading.

aaPanel_Kern

Thanks for your feedback, we have optimized it, please fix the panel

ta_ihpoj1jophi_at

aaPanel_Kern

Thank you — I clicked "fix" in the panel and can confirm what arrived. Since I
had documented the old state file by file, here is the same measurement on the
new one, so the record in this thread is complete.

Confirmed fixed

class_v2/projectModelV2/safecloudModel.py on my server is now byte-identical
to the version in your repository (fbc9dfdb7ba532ec05f84deec1d2e091, 190,584
bytes, down from 198,782). Compared to what I reported for 8.0.6:

CloudDetector is gone entirely — zero occurrences in the file. The
scanner's detector list now holds only YaraDetector. The automatic upload of
file contents during a malware scan no longer exists on my machine. That was
the core of my first post, and it is resolved.
The commented-out dynamic_detection check is no longer a loose end: the
setting was removed rather than reconnected. The switch no longer appears in
the config API, so an administrator is no longer told something is off while
nothing reads it. Not the outcome I asked for, but a consistent one.
The task-frequency guard now reads < 60 instead of < 50. The four
conflicting numbers around it (comment: 5 hours, message: 12 hours, UI: 6
hours) are still there, so this one is cosmetic rather than fixed.

Still open

The endpoint still hands out plain HTTP and still says yes. Checked a few
minutes ago, from the same server as before:

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

Both of your commitments from 20 days ago concerned exactly this line: switch
it to HTTPS, and make status: false the default. Neither has happened, and
the second one needs no code release at all — it is a value your own node
returns.

One upload path remains in the file. test_file() still reads a whole
file and posts it to the same endpoint:
```
   2192   'inputfile': self.ReadFile(filepath),
   2197   upload_res = requests.post(url, upload_data, timeout=20).json()
```
This one is not automatic — it needs an explicit filepath and is capped at
1 MB — so it is a different matter from the scanner. But it is still a full
file leaving the server in cleartext to a third-country endpoint, and the
consent question from my first post applies to it unchanged. If it is meant
to stay, it should say so at the point where an administrator triggers it.

One request for the record

Would you consider noting the change in the release notes for v8.22.0? Anyone
running an earlier version has no way to learn that the behaviour changed, and
operators who acted on my first post — by disabling monitoring or removing
directories — would want to know they can undo that.

Thanks again for the quick turnaround on the main point.

aaPanel_Kern

Where is this file, if it is a configuration file suggest you delete it will not affect the use
Very old configuration files

ta_ihpoj1jophi_at

aaPanel_Kern

Happy to be specific - but two different things got mixed up, so let me separate
them. I have changed nothing on my server; this is purely a report of what is
there.

1. It is not a configuration file — it is a function in your code

The upload path I asked about is test_file() in
class_v2/projectModelV2/safecloudModel.py, at line 2162 in the v8.22.0 file
now on my server:

2162   def test_file(self, get):
…
2184       url = self.GetCheckUrl()
2191       upload_data = {
2192           'inputfile': self.ReadFile(filepath),
2193           'md5': self.FileMd5(filepath)
2194       }
2197       upload_res = requests.post(url, upload_data, timeout=20).json()

GetCheckUrl() (line 2120) fetches the target from
{OfficialWebShellCheckBase()}/checkWebShell.php, and ReadFile() (2137)
returns fp.read() — the whole file, capped at 1 MB by the check at line 2180.

So this is not something an administrator can delete. My question was simply
whether it is meant to stay, and if so, whether the administrator who triggers
it is told that the file leaves the server. I am not asking for its removal —
an explicit, per-file action is a different matter from an automatic scan, and
you have already fixed the automatic one.

2. The configuration files — here is exactly what is on disk

/www/server/panel/data/safeCloud/, measured today, with age:

alarm_trend.json        1,098 B   2026-08-27 09:07    0 days
cloud_config.json          80 B   2026-08-07 21:29   20 days
config.json             1,166 B   2026-07-15 00:32   43 days
dir_record.db         143,360 B   2026-08-07 21:29   20 days
install_time.pl            17 B   2026-07-09 17:13   49 days
last_scan.json            201 B   2026-08-07 21:29   20 days
security_trend.json       474 B   2026-08-27 09:25   20 days
log/                    (empty)   2026-07-09 15:48
risk_files/             (empty)   2026-07-09 15:48

I then checked which of these names still appear anywhere in the v8.22.0
safecloudModel.py:

alarm_trend.json      1 reference
cloud_config.json     none
config.json           2 references
dir_record.db         1 reference
install_time.pl       1 reference
last_scan.json        1 reference
security_trend.json   1 reference

cloud_config.json is the only one your new code no longer reads. Its
content is the cached upload target from the old CloudDetector:

{"last_check": 1786130985.748439, "check_url": "http://w-check.bt.cn/check.php"}

That fits your description — an old configuration file, safe to delete. I will
leave it in place for now, in case you want a report from an untouched system.

The others are still referenced, so I am not touching them either. config.json
in particular holds the monitored directories, so deleting it would change scan
behaviour, not just clean up.

3. One number for context

last_scan.json still records 2026-08-07 21:29:45 — no scan has run since,
which is why the panel says "19 days ago". So on this machine the old detector
had not been active recently anyway; the fix removes the possibility rather than
an ongoing transfer. I mention it so the record is accurate rather than
dramatic.

4. An unrelated observation, offered as a question

While verifying the above I had a packet capture running on this server — full
payload, outbound web connections only, started 2026-08-26 21:47. It shows
something I cannot explain from the configuration, so I would rather ask than
speculate.

After the panel repair finished, the panel opened 18 connections to
wafapi2.aapanel.com, at an almost exact 26.5-second interval:

09:15:19  09:15:46  09:16:12  09:16:39  09:17:05  09:17:32
09:17:58  09:18:25  09:18:51  09:19:17  09:19:44  09:20:10
09:20:37  09:21:04  09:21:30  09:21:57  09:22:23  09:22:54

Then it stopped, and there has been none since (checked 09:44).

What puzzles me is that no WAF is installed here. The plugin directory holds
only fail2ban, jumpserver, mail_sys and redis, and the panel itself
reports "Nginx WAF — Not installed". There were also no wafapi2 connections at
all in the 11.5 hours of capture before the repair.

During those same seven minutes my panel request log shows exactly one kind of
activity: 91 calls to /v2/system?action=GetNetWork — a dashboard tab left
open, nothing else.

I cannot see inside the TLS session, only where it goes, so I am not claiming
anything about the content. My question is simply: what is that endpoint for
when the WAF product is not installed, and what does the panel send there? If it
is a licence or availability check, saying so plainly would settle it.

5. What should be removed?

Since you suggested deleting old configuration files, could you name them
concretely for the state after v8.22.0? Specifically:

Is cloud_config.json the only leftover of the removed CloudDetector, or
are there others outside data/safeCloud/ - cached values in the panel
database, for instance?
Does anything need to be removed for the fix to take full effect, or is the
code change sufficient on its own?

I would rather ask than guess: deleting the wrong file here changes scan
behaviour instead of cleaning up, and a short list from you would let every
operator reading this thread do it correctly the first time.

ta_ihpoj1jophi_at

aaPanel_Kern Following up on my own question 4 from the last post - the wafapi2 traffic.

I found the answer in your code, so this one is closed and needs no reply from
you. Posting it because I raised it publicly and the record should be complete.

It is check_vlun() in BTTask/task_script.py, line 561:

if (int(time.time()) - share_ip_info["time"]) < 86400:
    return public.returnMsg(False, "未达到时间")
...
url = f"{public.OfficialWaf2Base()}/api/bt_waf/get_wordpress_scan?size=100&p={page}"
...
for i in range(1, 20):
    time.sleep(26)

Everything I measured falls out of those lines:

The exact 26.5 s spacing between connections is the time.sleep(26).
The cap of 18-21 connections is range(1, 20).
The same start time on two different days (09:15:19 both times, with the
panel process running continuously in between) is the 86400-second gate in
data/wordpress_check_vlun.pl.

And the endpoint itself is unobjectionable. I fetched it by hand:

GET /api/bt_waf/get_wordpress_scan?size=100&p=1
-> {"success":true,"res":[{"plugin":"…","cve":"CVE-2025-1491",
    "vlun_version":"1.3.7","types":"plugin", …}]}   26 KB, 100 entries

No payload, no identifier, no key — nothing leaves the server, a list comes in
and is compared locally. That is exactly how it should work, and it is the
opposite of what my first post was about.

It fires here even though no WordPress is installed, which is why I noticed it
at all. That is a minor inefficiency, not a concern.

I should have read the code before asking. Sorry for the noise.

Still open from my last post, though:

The endpoint still returns plain HTTP and status: true — both commitments
from 21 days ago.
test_file() still uploads whole files to it. My question was only whether
the administrator who triggers it is told that the file leaves the server.
Which files are safe to delete after v8.22.0 — I asked for a short list so
every operator reading this thread gets it right the first time.

Thank you,
Jo

ta_ihpoj1jophi_at

aaPanel_Kern We need some answers.

aaPanel_Kern

Hello.
Thank you for your feedback. We will optimize it.

ta_ihpoj1jophi_at

@aaPanel_Kern Thank you. "We will optimize it" does not tell me what will change or when, so let me restate the three open points and ask for one date.

The check endpoint. Measured today, 2026-09-07:

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

On 2026-08-07 you committed to HTTPS and to status: false. That is 31 days ago; both nodes still return the plain-HTTP address and true. By which date will this change?
test_file() in class_v2/projectModelV2/safecloudModel.py (line 2162 in v8.22.0) still uploads the whole file, up to 1 MB. I am not asking for its removal. I am asking whether the administrator who triggers it is told that the file leaves the server. Yes or no is enough.
Which files are safe to delete after v8.22.0? From my measurement, data/safeCloud/cloud_config.json is the only file the new code no longer references. Please confirm that, and say whether anything outside data/safeCloud/ (panel database, cached values) needs removing for the fix to take full effect.

A short answer to each point would close this thread.

aaPanel_Kern

Hello.
Thank you for your feedback.
All the files in this "safeCloud" directory can be deleted.
We will provide an explanation for this function in the future.