Under high concurrent load (with the same userid) HippoAccessManager may incorrectly cache item readAccess state

HippAccessManager maintains a readAccessCache on ItemId per userId.
But because the determining the readAccess might need a recursive lookup, an initial (true) value is preliminary stored in the cache, which at the end of the check will be updated to the actual value.
Under high concurrent access, determining the readAcces for the same ItemId for the same userId these checks might overlap, potentially causing a preliminary (true) value to overwrite the result of another concurrent check.

This then can lead to incorrectly provided readAccess to a specific JCR Item (e.g. a document variant).

In practice this will still lead to an AccessDeniedException on subsequent access, so this isn't a security issue itself, but can result in unexpected error reports and stacktraces, and even (site) content failing to render.

See for example GOGREEN-1325, which was very helpful in finding the root cause of this problem.