If an attacker invokes an error like #8268 (he doesn't need to be authenticated for that) , a notification will be saved in the data field of his session. As those notifications are stored until they are displayed (but aren't), the data field grows over time. This can be used to fill hdd space or database space (if database session handling is active).
If database replication (mysql) is activated binlog grows very quick too, and uses a lot of hdd space (all of it).
A solution could be a limitation of notifications based on loginstatus.
Limiting the number of notifications sounds like a good idea in general :+1:
For security reasons it sounds like a very good idea to limit number of notifications. @tsteur do you have any suggestion how this could work?
Also for performance reasons this issue is important, see #8308
I'm not sure how notifications are implemented right now (especially re logging). At least initially they were stored in an array in the session so we could simply limit the number of notifications by using
array_splice or so.
especially re logging
FYI logging simply uses the notification system, so it works like the rest of the notifications (which I don't know how it works :p that was only my 2c).