[Bug]: Federated CloudID leaking on public lookup-server callback

[ichdasich]

Summary

added by @AndyScherzinger 18th March

For the final state, closing-statement, please see #51335 (comment) at the bottom of this issue.

As a summary 7th March 11:36PM CET this issue here has been raised having spotted outside calls by the lookup-server (https://github.com/nextcloud/lookup-server/ centrally run by Nextcloud GmbH) showing federated cloudIDs on the URLs of the inbound http (not https) call after updating the server to the latest maintenance release (February 2025 releases for 29, 30 and 31).

The root cause analysis showed that

• Triggering point: A business logic error introduced by the maintenance releases of February 2025 led to calls to the lookup-server for any user created before Feb 2021 or users created afterwards that at any point in time in the past had a profile field actively set to "published" (which means publish to public address-book)
• Actual issue this ticket is about: A business logic error on the lookup-server led to first doing a identity proof call (see first paragraph of this issue) via http instead of first checking if there has been any record in the database also not doing this via https instead

This matter has been resolved (again, see #51335 (comment) for details) by taking down the lookup-server endpoint to not accept or expose data, ensure the maintenance releases for March were released soon after the root cause got identified blocking the calls to the lookup-server and due to the identification of a deletion-error (not deleting the cloudID) also deleting all data the business logic error failed to delete (empty records just having a cloudID but no other fields fileld)

---

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

After the release of Nextcloud 31.0.0, a user reported suspicious activity on their Nextcloud instance after installing the update: https://bsd.network/@niels/114106538216130985

These request contain the usernames of the instance's users and target:

65.21.231.50 - - [07/Mar/2025:20:20:00 +0000] "GET /ocs/v2.php/identityproof/key/<USERID> HTTP/1.1" 301 169 "-" "GuzzleHttp/7"

All requests originate from 65.21.231.50. This indicates that PII was transmitted to a third party--in this case Nextcloud--without sufficient user consent. Depending on the selected userId, this data included full names and email addresses.

Being pointed to the issue, I was able to identify jobs named OCA\LookupServerConnector\BackgroundJobs\RetryJob as the root cause of these requests.

On all affected nextcloud instances I operate this behavior started exactly after the upgrade to 31.0.0. From the codebase it remains unclear what triggered the behavior. However, several functions around lookupServerUpload handling were refactored or altered in the meantime.

Auditing the configuration did not clarify which user settings may relate to exposure, as affected accounts also included dedicated accounts for, e.g., presentation machines at a conference not used by humans.

By instrumenting related source files, it was established that the configuration setting 'files_sharing', 'lookupServerUploadEnabled' ultimately enabling the datasharing triggering external requests is found under the Path:

Admin Settings -> Sharing -> Federated Cloud Sharing -> Allow people to publish their data to a global and public address book

Given that the implication of this setting is that the data of several users who had certainly not given explicit consent to the data transfer was shared with a third party (Nextcloud), the labeling of this configuration setting is, at best, dangerously misleading and at worst hiding its actual implications.

Steps to reproduce

1. Upgrade from Nextcloud v30.0.6 to v31.0.0
2. Wait for the regular cronjob to run
3. Within seconds of the first OCA\LookupServerConnector\BackgroundJobs\RetryJob job for a user, a request from 65.21.231.50 will be made to /ocs/v2.php/identityproof/key/<USERID>, demonstrating that data was shared with a third party.

Expected behavior

• The global "lookupServerUploadEnabled" setting should remain NO after an upgrade, and NO user data should be shared with third parties without users' or operators' consent.
• The setting for "lookupServerUploadEnabled" should be descriptively labeled, require confirmation, and make the implications of being enabled clear

Nextcloud Server version

31

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Please understand that the turn of events is extremely unfortunate. I will have to evaluate over the next 72h whether this event falls under Art. 33 III DSGVO.

I expect Nextcloud GmbH to perform due diligence in this matter as well. This includes:

• Ensuring that all potentially unintentionally leaked data is deleted
• Ensuring that this data is not re-shared to third parties or made publicly available
• Sharing documentation on the above two steps and a post-mortem with the Nextcloud community and the responsible DPA

Note on HackerOne Submission: On Mattermost and in Nextcloud's security reporting information on GitHub, a submission of security sensitive events is requested via HackerOne. I decided to not follow this recommendation for the following reasons:

• I do not consent to the terms and conditions of HackerOne, but believe that this issue is critically important for the community
• The leak/"vulnerability" (or rather: 'unintentional feature') can be mitigated by operators, if they set the aforementioned config setting to off; Delaying publication would, hence, expose users further.
• Technically, in this case, the not necessarily authorized collector of data is Nextcloud GmbH

[ichdasich]

I just realized that the data shared with the lookup server expands far beyond he userId. It may include: name, email, address, website, twitter, phone, twitter_signature, website_signature, twitter_verification_status, and website_verification status.

This is severe:

server/apps/lookup_server_connector/lib/BackgroundJobs/RetryJob.php

Line 172 in 06119ed

if (!empty($publicData)) {

[dballard]

this may also be problematic where European data privacy law applies, and open the recipient of this data to legal action

https://europa.eu/youreurope/citizens/consumers/internet-telecoms/data-protection-online-privacy/index_en.htm

[ichdasich]

The more I look at this, it indeed seems to be related to a rather old PR (4-years-ish) only merged recently:

#25290

• The default settings were probably in place without causing the observed behavior for a long time
• The patch being merged led to user data actually being publicly exchanged

This means that older versions of Nextcloud will also show this behavior as soon as the backport is in a minor release.

[ichdasich]

Ok, it seems to not be #25290 ; If at all, that PR not having been merged might have prevented some of the worst. Digging a bit deeper, it seems like the data array is full of empty values, at least in the version in v31.0.0 ; This is what #25290 fixes; So, in that regard, bullet dodged, I say.

The impact of this would have been significantly worse if that had already been merged.

[AndyScherzinger]

@ichdasich thanks for all the digging and the detailed findings. With these changes I can say it has currently been shipped with RC1 of 30 and 31, so I can help with reverting this change next week with the help of a developer.

The search endpoint has been deactivated for the lookup server. Before that and also in the past data is only accessible via the lookup endpoint with a direct hit, meaning you would need to know the exact email address in order to get a record as a result, else no / empty search result.

Further changes in the software I will also discuss with devs next week and the DPO h management.

Andy Scherzinger
Director Engineering Nextcloud

[ichdasich]

Thank you for the quick follow up. See also my last comment; It might be that we really got lucky there.

What remains to be figured out is why the overall calling of the lookupServer suddenly sprung into action, even if it 'just' leaked userId without #25290 being merged.

[AndyScherzinger]

Yes, seen your reference and yes, needs to be clarified why this sprung into action and the change will need to get reverted and lead to an RC2 release and to be checked if we need to postpone the final release date to give enough time for testing the new pre-release.

[ichdasich]

Final release date? I mean, this is already out (the userId only leak) with v31.0.0, which--as far as I can see--is already released: https://github.com/nextcloud/server/releases/tag/v31.0.0

If the enabling of the feature is properly consent based, there is no issue with #25290 ; It is the 'unexpected participation' in the feature that came up with the already released v31.0.0 that is the issue. #25290 not being in v31.0.0 might have been the saving grace there.

[AndyScherzinger]

I need to talk to a dev for a release date which I can't on the weekend. Implementing proper consent will be a bit of work the quick solution will be to change it to off-by-default

[ichdasich]

Off by default is always a good idea for anything that sends user data anywhere.

[ichdasich]

I just pulled backups from Feb 28 for an affected instance and could confirm that this was an implicit default value change. Neither does the SQL dump from Mar 7 (after the upgrade and before event detection, i.e., while data was transmitted).

The DB dump from Feb 28 does not contain configuration keys for files_sharing->lookupServerUploadEnabled and files_sharing->lookupServerEnabled.

[AndyScherzinger]

Thanks for digging deeper @ichdasich

If the default is the cause, I would still call that an hypothesis (until we know for sure since this is still an assumption based on the symptoms seen). Another hypothesis would be that the background job never executed 'successfully' (meaning sending the data) and that this is what has been 'fixed' with the release which would mean the default didn't change but the background job has been broken.

I any way I will have developers dig into the root cause analysis and ship a fix. It might be a quick fix blocking the logic preventing the behavior and a more holistic fix afterwards, as you said, no issue if consent is implemented correctly.

For the moment you should be able to hit the kill switch on the behavior via the settings UI

Basically disable the above settings (I am on the phone, so I only have a screenshot with the settings on active)

Edit: Just an info regarding distribution rate, 31.0.0 is currently set at 30%, so only 30% of servers on 30-latest get the 31-update offered plus anybody with a fresh install or manual update would be able to be on 31. As I said, only an info regarding distribution, not a statement regarding instances already on v31.