Trust and security question: Why can a third-party Nextcloud app with deep file access be installed without me being aware of it?

Discuss
1

I have searched the forum for similar discussions

on

I understand this category is for discussions, not support requests, and not for app requests.

on

This form is written in English but feel free to write in French if you’re more comfortable!

on

Discuss

TrusTitel: Nextcloud-34-Upgrade wird angeboten, obwohl installierte Drittanbieter-App es sicher blockiert – woher kommt Certificate24? t and security question: Why can a third-party Nextcloud app with deep file access be installed without me being aware of it?

Hello,

first of all: my English is not very good. I originally wrote this in German and had it translated into English, so please excuse any unusual wording.

I have searched the forum for similar discussions. I am aware that this category is intended for general discussion and not for a normal support request or an app request.

What started as a failed Nextcloud upgrade has turned into a much more fundamental security and trust question for me.

My system currently runs:

YunoHost 12.1.41.2
Nextcloud 33.0.4~ynh1
YunoHost offers an upgrade to Nextcloud 34.0.4~ynh1
PHP 8.4 is configured for Nextcloud

Every attempt to upgrade Nextcloud is aborted by YunoHost. The log clearly says:

The following apps are not (yet?) compatible with Nextcloud 34 … certificate24

I then investigated this application.

The installed app is:

Certificate24 0.4.0

Its own info.xml contains:

So the reason for the failed upgrade is clear.

What concerns me much more is this:

I do not remember installing Certificate24 at all.

I normally rely on YunoHost and deliberately try to avoid installing random third-party software. I therefore want to understand exactly how this app ended up inside my Nextcloud installation, when it was installed, and through which administrative action.

I then looked at what this application is technically able to do.

Certificate24 is not just a small visual plugin. Its source code uses Nextcloud interfaces such as IRootFolder, IUserManager and IDBConnection. It can access user folders, work with file IDs and run background jobs. The published source code also contains code that reads file contents and sends files via HTTP requests to an external Certificate24 API server as part of its signing and verification functionality. The default API server in the code is https://api.certificate24.com/.

I want to be very clear here:

I am not claiming that Certificate24 is malicious software.

What shocks me is the level of trust that such an application receives once it is installed inside Nextcloud.

A server-side Nextcloud app can potentially have access to extremely sensitive data. That makes the question of origin, installation, auditing and trust very important.

This is where I become very strict.

I do not want “strangers in my bed”, so to speak.

I chose YunoHost because I know YunoHost, I trust the project, and I understand who is responsible for the software stack I am using. With third-party applications it is different. I can look somebody in the face, but I cannot look inside their head — and the same applies to software developers.

With software that has access to personal files, private cloud data, documents or potentially sensitive information, the fun stops for me.

The general security question goes far beyond Certificate24 itself.

Imagine a hypothetical case:

A harmless-looking open-source application is published and becomes trusted over time. Later, the developer account, build infrastructure or update mechanism is compromised — or a malicious maintainer introduces hostile code.

If such an application already has access to user files, database interfaces, background jobs and outbound network connections, the possible consequences could be serious.

This would not only damage an individual administrator or project. A serious supply-chain incident could also damage the reputation of Nextcloud and YunoHost.

Again: I am not saying that this happened here.

I am saying that this is a trust model that deserves very careful discussion.

I therefore have several questions:

How can a YunoHost administrator reliably determine when and how a third-party Nextcloud app was installed or enabled?
Does the YunoHost Nextcloud package ever install or enable additional Nextcloud apps automatically during installation or upgrades?
Is there an audit trail showing which Nextcloud administrator or process installed an app?
Would it make sense for YunoHost to clearly distinguish between:
components maintained or packaged by YunoHost,
official Nextcloud components,
and third-party Nextcloud apps?
Could YunoHost warn administrators more prominently when third-party apps have access to files, external APIs, background jobs or other sensitive interfaces?
Why is the Nextcloud 34 upgrade still offered to me when the YunoHost upgrade script already knows that an enabled app explicitly supports only up to Nextcloud 33?

In my case the upgrade process itself behaves safely: YunoHost detects the incompatibility, aborts the upgrade and restores the previous Nextcloud installation.

That part is good.

But from a user perspective, it is confusing that the same impossible upgrade continues to be offered again.

Most importantly, I would like to understand where certificate24 came from on my system.

If I installed it myself years ago and simply forgot about it, then that is my responsibility.

But if it was introduced automatically by an installation, upgrade, dependency or some other mechanism, then I think administrators should be made very clearly aware of that.

I am raising this as a security and trust discussion, not as an accusation against Certificate24, Struktur AG, Nextcloud or YunoHost.

But I am genuinely shocked that I only discovered the existence and technical reach of this third-party app because a major Nextcloud upgrade failed.

For software handling private cloud data, I believe transparency about such components should be much stronger.

Update / additional finding

I have now found a second third-party app on the same Nextcloud installation that I also do not remember installing: gdatavaas / G DATA Antivirus.

After removing Certificate24, I tried the Nextcloud 34 upgrade again.

This time the upgrade proceeded further, but then failed at:

occ app:update --all

with:

Error: App "G DATA Antivirus" cannot be installed because the following dependencies are not fulfilled: Server version 33 or lower is required.

What makes this particularly interesting is that gdatavaas was already disabled:

gdatavaas: 33.1.0 (installed 33.1.0)

under the Disabled: section of occ app:list.

Nevertheless, the YunoHost upgrade process tried to update it as part of app:update --all, and the entire Nextcloud 34 upgrade was rolled back.

I also do not remember installing G DATA Antivirus myself.

According to the application’s own documentation, it integrates G DATA Verdict-as-a-Service into Nextcloud and can scan user files automatically or manually, including background scanning. This again raises the same question for me:

How can I reliably determine when, by whom and through which mechanism these third-party apps were installed?

It also raises a second technical issue:

Should a disabled third-party app that is incompatible with the target Nextcloud version be able to make the entire YunoHost major upgrade fail?

So far I have found two unrelated third-party apps on the same installation:

  • Certificate24
  • G DATA Antivirus (gdatavaas)

Both support only Nextcloud 33 and both interfered with the upgrade to Nextcloud 34.

I am not claiming malicious behaviour by either vendor. I am trying to understand the installation history and the trust model, because I do not remember deliberately installing either application.

I also found the disabled testing / QA testing app in /var/www/nextcloud/apps/.
The app itself states that it is only for testing and dangerous to enable on a live instance.
More interestingly, Nextcloud’s own stable33 .nextcloudignore explicitly excludes /apps/testing from production builds.
Therefore I would also like to understand why this directory exists in my production YunoHost Nextcloud installation.

I did a first source-level inspection of the testing application as well.

So far I found no evidence of outbound data transmission. A search for HTTP clients, curl/Guzzle and similar network functionality did not show such code.

However, this is clearly not an ordinary production application either.

The QA application has access to Nextcloud’s IRootFolder and contains lock-provisioning functionality for user file paths. It also provides OCS endpoints capable of setting and deleting application configuration values.

This gives some technical context to its own warning:

This app is only for testing! It is dangerous to have it enabled in a live instance

The app is disabled on my installation, and I currently have no evidence that it was ever enabled or that it transmitted any data.

My question therefore remains one of provenance and packaging, not an accusation of malware:

Why is /apps/testing present in this production installation when Nextcloud’s own stable33 build configuration explicitly excludes /apps/testing from production builds?

Is this expected in the YunoHost Nextcloud package, could it have been introduced during an earlier upgrade/restore, or should this directory normally never be present?

2

I don’t know, but I don’t have this app installed. Are you sure you didn’t install it yourself (you could have installed it a while ago and forget about it)?

3

Thanks for your reply.

That is exactly the point I am currently trying to clarify.

As far as I remember, I have only installed applications through the YunoHost application catalog. I have not manually installed Nextcloud apps from GitHub, cloned repositories, copied third-party code into Nextcloud, or installed anything manually from source.

I normally rely on the software offered through YunoHost because that is precisely one of the reasons why I use YunoHost.

Of course, I cannot completely rule out that I may have clicked on something inside Nextcloud a long time ago and simply forgotten about it. That is why I do not want to accuse anybody.

But I genuinely do not remember installing Certificate24, and until this failed upgrade I did not even know that it was present on my system.

This is also why I would like to find out whether there is any log or audit trail showing when Certificate24 was installed, who installed it, and by which mechanism.

If it turns out that I installed it myself years ago, then the matter is clear and that is my responsibility.

But at the moment I simply do not know where it came from.

What surprised me most is not only that the app is installed, but how much access a server-side Nextcloud app can potentially have. That is why I would really like to understand its origin before simply disabling or removing it.

4 
sudo grep -i certificate24 /var/log/nextcloud/nextcloud.log | jq .
sudo stat /var/www/nextcloud/apps/certificate24

may help.

Most of the time, nextcloud apps/plugins are installed by clicking them in Nextcloud admin > Applications. Maybe part of a pack ?

5

Thanks, that is helpful.

Yes, I understand what you mean. It is certainly possible that the app was installed through Nextcloud Admin → Apps rather than through YunoHost itself.

What I am trying to establish is exactly when and how that happened, because I genuinely do not remember installing Certificate24.

For server applications I normally install only what is offered through the YunoHost catalog. I have not manually cloned Git repositories, copied third-party application code into Nextcloud, or installed software manually from source.

Before removing Certificate24 I checked the installation:

  • Certificate24 version 0.4.0 was enabled.
  • Its path was /var/www/nextcloud/apps/certificate24.
  • Its info.xml stated support for Nextcloud 28–33 only.
  • The YunoHost Nextcloud 34 upgrade was explicitly aborted because of this app.
  • I also checked the Certificate24 account configuration, and no Certificate24 account was configured.

Because I did not knowingly use this application and did not want to keep software with this level of access on my cloud, I backed up the complete app directory, created a SHA256 hash for evidence, and then removed the app using Nextcloud’s occ app:remove.

Therefore stat /var/www/nextcloud/apps/certificate24 will no longer work now, because the directory has been removed.

Your suggestion regarding the Nextcloud log is very useful, though. I will search the current and older Nextcloud logs for certificate24. Hopefully this may show when it was installed, enabled, or first used.

Regarding a possible app pack: that is also something I would like to understand. If Certificate24 was installed as part of a bundle, recommended-app mechanism, migration, or some other Nextcloud process, that would explain how it arrived without me consciously selecting it.

I am not claiming that YunoHost installed it. I am trying to reconstruct its origin before drawing conclusions.

6

See here for the Certificate24 application:

And possibly, “Report a problem”

They may be more able to provide the answers.

7

The thing about Nextcloud is that it has an app-store on itself, which is NOT related to Yunohost.
As otm33 mentioned, you might have installed those nextcloud-apps yourself, or they might have been installed automatically because another nextcloud-app depends on them.
I’m not a user of Nextcloud (precisely because of this big-tree-structure I don’t like) but you should be able to find when it was installed in the log, if the log is old enough, I guess.

8

These two applications have not yet been updated for Nextcloud 34.
You must either wait until these applications are updated or disable them in Nextcloud so that you can update to NC34.

This is done directly in Nextcloud /settings/apps or SSH:

yunohost app shell nextcloud
php occ app:disable certificate24
php occ app:disable gdatavaas

Then exit

exit

Then you can update to NC 34

yunohost app upgrade nextcloud
9

Thanks, this helps clarify the separation between YunoHost and the Nextcloud App Store.

I now understand that Nextcloud has its own independent app ecosystem and that an app may also have been installed as a dependency of another Nextcloud app.

However, there is one important detail in my case:

gdatavaas was already disabled before the failed upgrade.

My occ app:list showed:

Disabled:

- gdatavaas: 33.1.0 (installed 33.1.0)

Nevertheless, during the YunoHost upgrade to Nextcloud 34, the upgrade script executed:

occ app:update --all

and then failed with:

Error: App "G DATA Antivirus" cannot be installed because the following dependencies are not fulfilled: Server version 33 or lower is required.

So in this case, simply disabling gdatavaas was apparently not sufficient. The disabled but still installed app was still considered by app:update --all, and the complete Nextcloud upgrade was rolled back.

Certificate24 was enabled, so disabling it may indeed have been sufficient for that first blocker. But gdatavaas demonstrates a different problem.

I have now archived both application directories with SHA256 hashes for possible analysis and removed both applications from the productive Nextcloud installation.

I also checked Certificate24 before removal: no Certificate24 account was configured.

The remaining question for me is still the origin of both applications. I genuinely do not remember installing either Certificate24 or G DATA Antivirus.

The dependency explanation is therefore interesting. Is there a reliable way to determine whether either of these apps was installed automatically as a dependency of another Nextcloud app, and ideally which app triggered the installation?

I would also be interested in whether YunoHost’s Nextcloud upgrade script should ignore disabled apps during app:update --all, or pre-check incompatible installed apps before replacing the Nextcloud version.

10

Why use occ app:update --all?

11

Nextcloud has its own independent app ecosystem
The Yunohost update script does not interact with Nextcloud applications, it is up to you to check if updates to Nextcloud applications are required before you update Nextcloud.

Disable or remove gdatavaas

php occ app:remove gdatavaas

Leave the shell environment and then you can do the Nextcloud update.

yunohost app upgrade nextcloud
12

Thanks, but I think there is an important misunderstanding here.

I am not manually running occ app:update --all during the YunoHost upgrade.

The current YunoHost Nextcloud upgrade script itself contains:

# Update all installed apps
exec_occ app:update --all

I checked the exact package revision used for my upgrade:

fe69350cb8e03a1c7d8de75a8938598077024d1a

There seems to be another interesting detail in the upgrade script:

The compatibility pre-check builds its list from:

app:list --output json → .enabled | keys[]

So it appears to check enabled applications before the major upgrade.

However, later the script preserves third-party application directories and finally executes:

app:update --all

This matches exactly what happened on my system:

gdatavaas was already disabled, so it did not prevent the initial compatibility check. But it was still installed. Later, during app:update --all, G DATA reported that server version 33 or lower was required, and the complete YunoHost upgrade was rolled back.

I also tried:

php occ app:remove gdatavaas

but Nextcloud answered:

gdatavaas is not enabled

So this may be an edge case in the YunoHost Nextcloud upgrade procedure:

Can a disabled but installed incompatible app bypass the pre-upgrade compatibility check and then abort the upgrade later when app:update --all is executed?

If so, perhaps the pre-flight check should also inspect disabled installed applications, or app:update --all should be handled differently.

I am not making a security accusation here. I am trying to understand and document the actual upgrade behaviour.

13

Try to force NC update:

yunohost app upgrade -F nextcloud

This can help you:

yunohost app upgrade --help
usage: yunohost app upgrade [app ...] [-h] [-u URL] [-f FILE] [-F] [-b] [-c] [-i]

Upgrade app

positional arguments:
  app                   App(s) to upgrade (default all)

options:
  -h, --help            show this help message and exit
  -u URL, --url URL     Git url to fetch for upgrade
  -f FILE, --file FILE  Folder or tarball for upgrade
  -F, --force           Force the update, even though the app is up to date
  -b, --no-safety-backup
                        Disable the safety backup during upgrade
  -c, --continue-on-failure
                        Continue to upgrade apps even if one or more upgrade failed
  -i, --ignore-yunohost-version
                        Attempt to upgrade the app even if your YunoHost version is below the required one
14

Thanks, but I think we are talking about two different issues now.

My goal is not to force the Nextcloud upgrade at any cost.

I know that yunohost app upgrade -F nextcloud can force the upgrade procedure to run again. But this does not answer the actual question I am investigating.

I deliberately use YunoHost because I want a curated, understandable and reasonably minimal production system. I do not want unnecessary or unexplained software components accumulating on a server that contains private data.

During this investigation I found:

certificate24 — unexpected
gdatavaas — unexpected and already disabled, but still able to abort the YunoHost upgrade later during app:update --all
office_switcher — old and incompatible
testing — Nextcloud QA application, explicitly described as dangerous to enable on a live instance

The last one is particularly interesting because Nextcloud’s own stable33 build configuration excludes /apps/testing from production builds.

So the main question is not:

“How can I force NC34 to install?”

The question is:

“Why were these application directories present on my production installation, and through which installation, dependency, packaging, restore or upgrade path did they arrive there?”

I have now archived and hashed the questionable application directories before removing them from the active Nextcloud application tree.

The current state is:

  • no disabled non-shipped apps remain
  • all remaining apps are up to date
  • Nextcloud 33.0.4 is healthy
  • maintenance mode is off
  • no database upgrade is pending

I will retry the normal YunoHost upgrade after making a fresh backup.

But forcing an upgrade does not solve the provenance and trust question, which is the main reason I opened this thread.

I value YunoHost precisely because it gives me a trusted packaging and administration layer, and I am happy to support the project financially for that reason. That is why I want to understand how unexplained application components can end up inside a production Nextcloud installation.

15

That is exactly why I am asking these questions.

A large amount of private and sensitive data is stored in my Nextcloud and on the server behind it. I deliberately keep this system conservative: I do not install arbitrary software, I do not want unnecessary bloat, and I do not want to force upgrades just to make them pass.

I use YunoHost precisely because I consider it a very strong and security-conscious platform. In fact, the current situation was only discovered because the upgrade process stopped instead of silently continuing with incompatible applications. I see that as a strength, not as a weakness.

My concern is therefore not “YunoHost is insecure”.

My concern is:

How can application components appear in a production Nextcloud installation when I do not remember knowingly installing them, and when at least one of them (testing) is explicitly excluded from normal production builds by Nextcloud itself?

For a server holding sensitive personal data, provenance matters to me:

  • Was the application installed manually?
  • Was it pulled in as a dependency?
  • Was it included by an older package?
  • Was it restored from an older backup?
  • Was it copied forward during an upgrade?
  • Was it introduced by another Nextcloud app or packaging step?

I would like to understand that chain, because I want the system to remain minimal, auditable and predictable.

I am happy to support YunoHost financially exactly because I value its security model and curated administration. That is why I am interested in understanding this behaviour rather than simply forcing the upgrade and ignoring it.

16

Hope the logs might be useful.

So far, I’ve never heard of a case where certificate24 was installed without the user knowing about it and I had never heard of this app either.

17

Danke, das hilft mir bei der Einordnung.

Ich möchte dabei noch einmal klarstellen: Ich behaupte nicht, dass YunoHost certificate24 heimlich installiert hat oder dass dahinter etwas Böswilliges steckt. Genau das möchte ich gerade nicht unterstellen.

Meine Frage ist vielmehr die Provenienz: Wann wurde diese App installiert, durch welchen Installationsweg, von welchem Prozess oder Benutzer und warum befand sie sich zum Zeitpunkt des Nextcloud-Upgrades in meiner Installation?

Dass Ihnen bisher kein vergleichbarer Fall bekannt ist und Sie die App selbst noch nicht kannten, ist für die Untersuchung durchaus interessant. Es beantwortet meinen konkreten Fall aber noch nicht. Deshalb versuche ich, das anhand der Logs, Backups und Dateistände sauber nachzuvollziehen.

Wenn sich am Ende herausstellt, dass ich sie irgendwann selbst oder indirekt installiert habe, ist das für mich genauso ein valides Ergebnis. Mir geht es um eine nachvollziehbare technische Erklärung, nicht um Schuldzuweisung.

18

I think you should post this on the nextcloud-forums instead of here, they can probably help you better. Especially to your many questions regarding auditing, installation and so forth.

That said, I do not think this is a problem with yunohost.

In the installation script, two apps are installed: user_ldap (nextcloud_ynh/scripts/install at fe69350cb8e03a1c7d8de75a8938598077024d1a · YunoHost-Apps/nextcloud_ynh · GitHub) and files_external ( nextcloud_ynh/scripts/install at fe69350cb8e03a1c7d8de75a8938598077024d1a · YunoHost-Apps/nextcloud_ynh · GitHub ) (and notify_push and mail).

I also further looked at the source code to see if it installed gdata or certificate24 at some time in the past, but did not find anything.

So my best guess: you installed it sometime in the past.