1/ bloglevelupgrade.php must not modify $USER->id like this, it can not work because it breaks all caching and assumptions in accesslib.php, you might also end up logged in as somebody else [CRITICAL]
2/ cron.php - it might be better to use record sets in oder limit memory use [MINOR]
3/ block_blog_menu.php - I do not like the use of $PAGE->url->param('modid') at all, passing params around using page object looks like a sloppy hack; there is another use of this hack in adminlib for section parameter, this looks wrong too, I really hope this will not spread all over moodle codebase, please use something else [MAJOR]
4/ admin/settings/top.php - please do not pollute top with one time upgrade hacks [MAJOR]
5/ blog/lib.php - why discard coding exceptions in blog_get_headers()? this looks like a wrong coding style [CRITICAL]
6/ block_blog_recent.php can be used on any page, right? (missing applicable_formats()?) If yes it does not make much sense to use blog_get_headers() which is designed to work on blog/index.php [MAJOR]
7/ 'moodle/blog:search' is not personal risk, if yes it should not be default for guest role [MINOR]
8/ lang/en_utf8/admin.php bloglevelupgradebody has some funny Windows line endings [MINOR]
9/ string['modulename'] = 'Blog'; in blog.php looks strange
10/ external_blogs.php looks like a joke - XSRF and missing access control, once you have 'moodle/blog:manageexternal' you can delete ANY external blog (given to all students by default), with XSRF you can trick any student to delta any external blog
11/ when deleting entry only 'blog_attachment' area is purged, but not 'blog_post', this applies
12/ I personally do not like the blog_entry class because it is mixing all levels of code (db access, accesscontrol, forms processing, html printing, etc.) - I do not think that any functions there are usable in external API, we need to separate low level code
Task
Closed
Critical
First patch attached