I can confirm this, but also that we can do very little about this. The content from the custom field is indexed as part of the content item and all content from the content item has the same viewlevel assigned to it. The best that we can do here is to add a warning text to the field that the content is handled with the same viewlevel as the content item it belongs to.

Can't the access level be checked at indexing?

What do you want to check? The currently logged in user when indexing definitely has the permissions and when searching we only have the access level of the original content item. Considering that the content of the custom fields is not displayed when searching, this is not a high risk to me.

Just an idea, can't there be a acl columnn in jos_finder_terms ?
(Maybe now a warning and the xtra column as an upcoming feature? )

Adding that column would pretty likely be the death to any performance the system has right now. As I said previously, I also consider this actually a rather minor issue and would solve it with a warning at most. Again, this would affect you if you deliberately added the custom field to the index, knew a specific value to search for and the only thing you would get out of this is a list of content items containing this. It still would not display the content of the custom field.

I think you are downplaying the potential severity of this information disclosure.

If I have indexed a directory of members with a boolean field "is_a_spy" them I only need to knbow the field exists to enumerate the data

I already installed RC2 to use it in a new project for a catalog. Normal users are only able to search by a unique QR Code like 639ww6934g923zgb##ddhsddd - Registered Users are able to search by serial number of the product but not registered are not allowed to. Thats my "security issue" right now to solve.

If I have indexed a directory of members with a boolean field "is_a_spy" them I only need to knbow the field exists to enumerate the data

No, that actually is not correct. We are not indexing the name of the field, but just the value of the field. So for your scenario to be correct, you would have to have used "is_a_spy" for the field. I'd say it is much more likely, that you would have used a boolean value here. Regardless of that, you would have to explicitely have enabled the field to be indexed. We are not indexing this stuff by default.

That is why your previous suggestion is important otherwise people will be "suprised" just as @coolcat-creations has been

The best that we can do here is to add a warning text to the field that the content is handled with the same viewlevel as the content item it belongs to.

See #42111

I think 42111 is ok as a quick fix, but would like to remain the issue opened to maybe find a solution to solve it in future

When field indexed as taxonomy (option Add as taxonomy) it have an access and language, In theory it already should work for this type of indexing. @Hackwar can you confirm? or maybe I missing something.

And when the field indexed as "metadata" (options Make searchable and Make searchable and add as taxonomy) there no way of doing it.

@Fedik that is correct.

Seems to me sovled for now. Converting it to discussions for more ideas