According to the details he submitted via the HackerOne bug report, the Elasticsearch API results continued to show code of projects in private groups after moving the group from public. It means that despite turning the information private, it was still accessible to everyone via search results.
However, this flaw didn’t affect individual projects being transferred from private to public group. Rather the glitch appeared only upon transferring the entire group.
He further elaborated on the glitch with the following example situation.
Alice creates the public group "Example", and a public project named "Example-project" inside the group. In the readme of the project, Alice writes "Example". Now, Alice creates a private group called "private", and transfer all the "Example" group to the "private" group. If Bob (totally unrelated to Alice), search for "Example" instance-wide, will not find anything on the interface, but the count of the results will be "1". If he uses the APIs (e.g. http://localhost/api/v4/search?search=password&scope=blobs), he will receive the results back with the information that should be private.The bug also affected wiki_blobs.
Eventually, the succeeded in addressing the bug and closing the report until December 2019. They rolled-out the patch with the release of GitLab version 12.5.4. It means the flaw no more affects any private groups.
The researcher marked this flaw as a medium severity bug considering its not so serious impact.
I set the severity as "medium" and not "high", because any new action over the project issues a re-indexing (or some actions, not sure), so if the transfer is for "archiving" purposes it is a problem, but if after the transfer other activities happen, then it is not a problem, cause the project will be removed from the index.The researcher won a $3000 bounty for it.
