I've stumbled upon a slight security issue in the calendar widget, which might leak a user's private events.
In order to reproduce:
Ensure you have the calendar widget somewhere on your site.
Create a new user (say test) without the read_private_events capacity.
Create a new private event and assign it to this user.
Log out and log in as this user.
Consult the calendar widget on your site and ensure you can see this user's private event. (Otherwise, clear the caches so that EO refreshes the widget contents.)
Log out.
Consult the calendar widget on your site: the new user's private event should still show up.
The expected behavior is that the private event shouldn't be displayed here: only test and users with the read_private_events should be able to see it.
It seems to me that this is because the caching mechanism for the calendar widget is a bit too lax: even when read_private_events isn't set for the current user, the calendar widget will still show their private events (which is expected), but they will then be cached for any user who doesn't have the read_private_events capacity.
This tiny PR intends to fix this by using the current user's ID in the caching key instead of the read_private_events capacity. (Also, since the _priv key in the $args array then becomes useless, it is removed.)
From the tests I could run, this was enough to fix the issue.
Hello,
Thank you for the work on developing this plugin!
I've stumbled upon a slight security issue in the calendar widget, which might leak a user's private events.
In order to reproduce:
test
) without theread_private_events
capacity.The expected behavior is that the private event shouldn't be displayed here: only
test
and users with theread_private_events
should be able to see it.It seems to me that this is because the caching mechanism for the calendar widget is a bit too lax: even when
read_private_events
isn't set for the current user, the calendar widget will still show their private events (which is expected), but they will then be cached for any user who doesn't have theread_private_events
capacity.This tiny PR intends to fix this by using the current user's ID in the caching key instead of the
read_private_events
capacity. (Also, since the_priv
key in the$args
array then becomes useless, it is removed.)From the tests I could run, this was enough to fix the issue.
Thanks!
Zosterops